[ 
https://issues.apache.org/jira/browse/ARROW-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588313#comment-16588313
 ] 

Lukasz Bartnik edited comment on ARROW-1380 at 8/22/18 3:01 AM:
----------------------------------------------------------------

The first of these warnings could be probably addressed by not calling exit(0) 
from the signal handler. My impression is that after a signal is caught and 
exit() is called, main() never returns, and thus destructors for its local 
objects are not called. Below is the valgrind warning in question.

{code}
==1990== 33 bytes in 1 blocks are still reachable in loss record 1 of 2
==1990== at 0x4C3017F: operator new(unsigned long) (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1990== by 0x513088C: std::string::_Rep::_S_create(unsigned long, unsigned 
long, std::allocator<char> const&) (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==1990== by 0x5130C55: std::string::_M_mutate(unsigned long, unsigned long, 
unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==1990== by 0x5131321: std::string::_M_replace_safe(unsigned long, unsigned 
long, char const*, unsigned long) (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==1990== by 0x198A23: main (store.cc:937)
{code}
 

I tried simply commenting exit() out but that leads to other errors and I 
assume is not intended. I don't see much other signal handling in plasma and my 
current guess is that it is ae that gets interrupted and then drops the event 
loop.

I'd be grateful for comments and/or pointers to relevant areas in the code.


was (Author: lbartnik):
The first of these warnings could be probably addressed by not calling exit(0) 
from the signal handler. My impression is that after a signal is caught and 
exit() is called, main() never returns, and thus destructors for its local 
objects are not called. Below is the valgrind warning in question.

==1990== 33 bytes in 1 blocks are still reachable in loss record 1 of 2
==1990== at 0x4C3017F: operator new(unsigned long) (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1990== by 0x513088C: std::string::_Rep::_S_create(unsigned long, unsigned 
long, std::allocator<char> const&) (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==1990== by 0x5130C55: std::string::_M_mutate(unsigned long, unsigned long, 
unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==1990== by 0x5131321: std::string::_M_replace_safe(unsigned long, unsigned 
long, char const*, unsigned long) (in 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==1990== by 0x198A23: main (store.cc:937)

 

I tried simply commenting exit() out but that leads to other errors and I 
assume is not intended. I don't see much other signal handling in plasma and my 
current guess is that it is ae that gets interrupted and then drops the event 
loop.

I'd be grateful for comments and/or pointers to relevant areas in the code.

> [C++] Fix "still reachable" valgrind warnings when PLASMA_VALGRIND=1
> --------------------------------------------------------------------
>
>                 Key: ARROW-1380
>                 URL: https://issues.apache.org/jira/browse/ARROW-1380
>             Project: Apache Arrow
>          Issue Type: Bug
>          Components: Plasma (C++)
>            Reporter: Wes McKinney
>            Priority: Major
>             Fix For: 0.11.0
>
>         Attachments: LastTest.log, valgrind.supp_
>
>
> I thought I fixed this, but they seem to have recurred:
> https://travis-ci.org/apache/arrow/jobs/266421430#L5220



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to