Details
-
Bug
-
Status: Resolved
-
Blocker
-
Resolution: Fixed
-
None
Description
We're getting an error now that we are testing DuckDB:
==3189== by 0x31023018: duckdb_moodycamel::ProducerToken::ProducerToken<std::unique_ptr<duckdb::Task, std::default_delete<duckdb::Task> >, duckdb_moodycamel::ConcurrentQueueDefaultTraits>(duckdb_moodycamel::ConcurrentQueue<std::unique_ptr<duckdb::Task, std::default_delete<duckdb::Task> >, duckdb_moodycamel::ConcurrentQueueDefaultTraits>&) (concurrentqueue.h:3612) ==3189== by 0x3101A3A4: duckdb::QueueProducerToken::QueueProducerToken(duckdb::ConcurrentQueue&) (task_scheduler.cpp:39) ==3189== by 0x31023552: std::unique_ptr<duckdb::QueueProducerToken, std::default_delete<duckdb::QueueProducerToken> > duckdb::make_unique<duckdb::QueueProducerToken, duckdb::ConcurrentQueue&>(duckdb::ConcurrentQueue&) (helper.hpp:22) ==3189== by 0x30FFA807: duckdb::TaskScheduler::CreateProducer() (task_scheduler.cpp:110) ==3189== by 0x30FF6FC8: duckdb::Executor::Initialize(duckdb::PhysicalOperator*) (executor.cpp:34) ==3189== ==3189== 984 (448 direct, 536 indirect) bytes in 4 blocks are definitely lost in loss record 1,191 of 4,641 ==3189== at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==3189== by 0x30F288C6: std::unique_ptr<duckdb::PreparedStatement, std::default_delete<duckdb::PreparedStatement> > duckdb::make_unique<duckdb::PreparedStatement, char const*>(char const*&&) (helper.hpp:22) ==3189== by 0x30E7FDF9: duckdb::ClientContext::Prepare(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (client_context.cpp:376) ==3189== by 0x30E85BC8: duckdb::Connection::Prepare(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (connection.cpp:78) ==3189== by 0x302BF4E4: duckdb::RApi::Prepare(SEXPREC*, SEXPREC*) (statement.cpp:61) ==3189== by 0x4942217: R_doDotCall (dotcode.c:604) ==3189== by 0x494D3C9: do_dotcall (dotcode.c:1284) ==3189== by 0x498CA4E: Rf_eval (eval.c:843) ==3189== by 0x4992DB8: do_set (eval.c:2982) ==3189== by 0x498C7F5: Rf_eval (eval.c:815) ==3189== by 0x499183B: do_begin (eval.c:2530) ==3189== by 0x498C7F5: Rf_eval (eval.c:815) ==3189== ==3189== LEAK SUMMARY: ==3189== definitely lost: 448 bytes in 4 blocks ==3189== indirectly lost: 536 bytes in 4 blocks ==3189== possibly lost: 1,055 bytes in 3 blocks ==3189== still reachable: 334,880,826 bytes in 71,040 blocks ==3189== of which reachable via heuristic: ==3189== newarray : 4,264 bytes in 1 blocks ==3189== suppressed: 0 bytes in 0 blocks ==3189== Reachable blocks (those to which a pointer was found) are not shown. ==3189== To see them, rerun with: --leak-check=full --show-leak-kinds=all
We should report these to the DuckDB folks + ensure that we are not running these tests on cran.
Attachments
Issue Links
- links to