[ https://issues.apache.org/jira/browse/ARROW-14219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Keane resolved ARROW-14219. ------------------------------------ Fix Version/s: 6.0.0 Resolution: Fixed Issue resolved by pull request 11321 [https://github.com/apache/arrow/pull/11321] > [R] [CI] DuckDB valgrind failure > -------------------------------- > > Key: ARROW-14219 > URL: https://issues.apache.org/jira/browse/ARROW-14219 > Project: Apache Arrow > Issue Type: Bug > Components: Continuous Integration, R > Reporter: Jonathan Keane > Assignee: Jonathan Keane > Priority: Blocker > Labels: pull-request-available > Fix For: 6.0.0 > > Time Spent: 40m > Remaining Estimate: 0h > > We're getting an error now that we are testing DuckDB: > https://dev.azure.com/ursacomputing/crossbow/_build/results?buildId=12649&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb&t=d9b15392-e4ce-5e4c-0c8c-b69645229181 > {code} > ==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 > {code} > We should report these to the DuckDB folks + ensure that we are not running > these tests on cran. -- This message was sent by Atlassian Jira (v8.3.4#803005)