Re: [Valgrind-users] Spurious errors during an abrupt program termination

[John R. <jr...@bi...>]

On 5/14/20, Dalon Work wrote:

> I have an application with two threads on linux which I was testing
> under valgrind. We have a strange memory behavior that is leading to
> an internal assert terminating the application, hence the
> investigation. After running the application, I have many, many
> errors, (invalid reads and writes), which all follow a similar
> pattern:
> 
> Invalid read/write of size 4:
>      at thread1_func()
>      at thread1_func1()
>      ...

The rule for dealing with output from memcheck is:
    Fix the first complaint.  Do not ignore it; FIX IT.
Many times the command-line option --track-origins=yes provides helpful clues.

> Address 0x##### is ##### bytes inside a block of size #### free'd
>      free()
>      myAllocator::~myAllocator()
>      __run_exit_handlers
>      exit
>      terminate_handler_sp
>      thread2_func()
>      thread2_func1()
>      ...
> 
> The call stack from the free() stack is obviously from the second
> thread (NOT the one that started the error, oddly enough), while the
> invalid read is from the first thread.

Based on this evidence, the most likely scenario is thread2 decided to
(or was forced to) terminate, and started running exit handlers
for the whole process.  Meanwhile, thread1 continues running (thread1
has received no news that it should stop) and references blocks that
have been free()d by the termination handlers invoked by thread2.
So the termination handler should first rendezvous with all threads
before beginning to shutdown the process.