I have a quick question that hopefully those more knowledgeable in
linux can help me with.
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()
...
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.
Anyway, the way I'm interpreting this is that the first thread starts
the abort process. The second thread catches the signal and starts
destroying the static objects, which frees memory, and somehow the
first thread keeps going and causes all sorts of spurious memory
errors?
I guess another possibility is that at some point the second thread
really did tear everything down at some point and the first thread
really did just charge ahead not knowing about it. My linux-fu is not
at expert-level yet (Just a yellow-belt, really), so I'd appreciate
any thoughts on what could be going on and how to continue with the
debugging process.
Dalon
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
