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.
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
