|
From: Roberto D. <rd...@ti...> - 2007-10-09 10:56:05
|
Hi everybody.. I dont fully understand the meaning of the stack-traces presented by valgrind after an invalid read/write. For example here: Invalid read of size 4 ==21380== at 0xCA30E6: pthread_mutex_unlock (in /lib/tls/libpthread-2.3.4.so) ==21380== by 0x7FF7063: qStreamGroupClose (in /usr/dialogic/lib/libqhost.so) ==21380== by 0x7EEE945: Dm3::StreamGroupManager::ReleaseGroup(unsigned, unsigned char, unsigned) (in /usr/dialogic/lib/libc heetah.so) ==21380== by 0x7EEEBF0: Dm3::Stream::Close() (in /usr/dialogic/lib/libcheetah.so) ==21380== by 0x7EF9386: Dm3Stream::Close() (in /usr/dialogic/lib/libcheetah.so) ==21380== by 0x7F93322: VoiceChannel::InitiateShutdown() (in /usr/dialogic/lib/libdxxdm3.so) ==21380== by 0x7FA78C5: VoiceChannel::Shutdown() (in /usr/dialogic/lib/libdxxdm3.so) ==21380== by 0x7EA8B89: AsyncObjectManagerImpl::ReleaseObject(AsyncObject&) (in /usr/dialogic/lib/libcheetah.so) ==21380== by 0x7FB126D: VoiceDevice::Shutdown() (in /usr/dialogic/lib/libdxxdm3.so) ==21380== by 0x7FB4E29: dx_close (in /usr/dialogic/lib/libdxxdm3.so) ==21380== by 0x4420356: MiniProxyDlgc::Finalizar() (MiniProxyDlgc.cpp:731) ==21380== by 0x441DA18: ControladorHardware::Finalizar() (ControladorAudio.cpp:471) ==21380== Address 0xB3275CC is 44 bytes inside a block of size 92 free'd ==21380== at 0x4004EFA: free (vg_replace_malloc.c:235) ==21380== by 0x7FF645C: deleteGroup (in /usr/dialogic/lib/libqhost.so) ==21380== by 0x7FF6FC1: qStreamGroupClose (in /usr/dialogic/lib/libqhost.so) ==21380== by 0x7EEE945: Dm3::StreamGroupManager::ReleaseGroup(unsigned, unsigned char, unsigned) (in /usr/dialogic/lib/libc heetah.so) ==21380== by 0x7EEEBF0: Dm3::Stream::Close() (in /usr/dialogic/lib/libcheetah.so) ==21380== by 0x7EF9386: Dm3Stream::Close() (in /usr/dialogic/lib/libcheetah.so) ==21380== by 0x7F93322: VoiceChannel::InitiateShutdown() (in /usr/dialogic/lib/libdxxdm3.so) ==21380== by 0x7FA78C5: VoiceChannel::Shutdown() (in /usr/dialogic/lib/libdxxdm3.so) ==21380== by 0x7EA8B89: AsyncObjectManagerImpl::ReleaseObject(AsyncObject&) (in /usr/dialogic/lib/libcheetah.so) ==21380== by 0x7FB126D: VoiceDevice::Shutdown() (in /usr/dialogic/lib/libdxxdm3.so) ==21380== by 0x7FB4E29: dx_close (in /usr/dialogic/lib/libdxxdm3.so) ==21380== by 0x4420356: MiniProxyDlgc::Finalizar() (MiniProxyDlgc.cpp:731) ==21380== I understand the first stack-trace prints where the invalid read has been done and the second where the memory was free.. what I am not quite sure about what is happening here.. maybe is that MiniProxyDlgc::Finalizar () has been called twice? or the problem is inside qStreamGroupClose (which could be freeying the memory and later using it)?? Please any help would be quite appreciated.. Regards Roberto |
|
From: Christoph B. <bar...@or...> - 2007-10-09 12:17:32
|
Am Dienstag, 9. Oktober 2007 schrieb Roberto Diaz: > I understand the first stack-trace prints where the invalid read has > been done and the second where the memory was free.. what I am not quite > sure about what is happening here.. maybe is that > MiniProxyDlgc::Finalizar () has been called twice? or the problem is > inside qStreamGroupClose (which could be freeying the memory and later > using it)?? > > Please any help would be quite appreciated.. 1. I would increase the stack length such that the whole one is visible. --num-callers=250 might be a useful value. 2. You should be able to use std::cout or printf to verify one of your hypotheses. Maybe you have to compile the libs you are using with debug information to be able to locate the lines in the source code. Christoph |
|
From: John R.
|
> Invalid read of size 4
>
> ==21380== at 0xCA30E6: pthread_mutex_unlock (in
> /lib/tls/libpthread-2.3.4.so)
> ==21380== by 0x7FF7063: qStreamGroupClose (in
> /usr/dialogic/lib/libqhost.so)
The content of the message "Invalid read of size 4" is a bug in memcheck
because it does not give the numerical memory address that was read.
This is the second most important piece of information, and it is missing
from the error report! The most important piece is given: "a bad read
was done". (But *why* is the fetch invalid?)
>
> ==21380== Address 0xB3275CC is 44 bytes inside a block of size 92
> free'd
>
> ==21380== at 0x4004EFA: free (vg_replace_malloc.c:235)
> ==21380== by 0x7FF645C: deleteGroup (in
> /usr/dialogic/lib/libqhost.so)
> ==21380== by 0x7FF6FC1: qStreamGroupClose (in
> /usr/dialogic/lib/libqhost.so)
The pointer argument to free() did not point to the beginning of
an active block. In practice a likely underlying cause
is using a block after it has been free()d and the space re-allocated
and overwritten, such as free(ptr->next) when free(ptr) has been done
already. After free(ptr) then one might hope to receive a complaint
about the subsequent fetch of ptr->next, but perhaps memcheck's
suppressed notification principle applies ("no harm, no foul".)
--
|
|
From: Julian S. <js...@ac...> - 2007-10-09 15:37:23
|
> The content of the message "Invalid read of size 4" is a bug in memcheck > because it does not give the numerical memory address that was read. Memcheck does show the address that was read: > > ==21380== Address 0xB3275CC is 44 bytes inside a block of size 92 > > free'd Not that knowing that address, 0xB3275CC, is much use in practice. The useful part is the fact that it is 44 bytes inside a block of size 92 which has already been freed at the specific stack trace. The most likely reason for Memcheck to report this is that the memory has been used after it has been freed. That might also happen if you free the memory twice, and the second freeing activity has to read the memory before really doing the free. J |
|
From: Dirk M. <dm...@gm...> - 2007-10-09 16:03:39
|
On Tuesday 09 October 2007, John Reiser wrote:
> The pointer argument to free() did not point to the beginning of
> an active block. In practice a likely underlying cause
> is using a block after it has been free()d and the space re-allocated
> and overwritten
This can only be incorrect, and the only possibility for this happening is
when valgrind is not able to track all allocations and deallocations, which
happens if you use a custon arena allocator or a pooling garbage collector
that does really funky things.
it does help a lot in such a case to recompile your application to not use
those optimisations (often there is a debugging #define for that), set an
appropriate environment variable or similiar. it can make a undebuggable
problem trivially to spot with valgrind, so this is something important to
keep in mind.
but in this particular case there is no indication whatsoever for this being
the case, given that the two backtraces are almost identical, it looks like
real, and I can even imagine how the source code looks like where this trace
was produced.
> , such as free(ptr->next) when free(ptr) has been done
> already. After free(ptr) then one might hope to receive a complaint
> about the subsequent fetch of ptr->next, but perhaps memcheck's
> suppressed notification principle applies ("no harm, no foul".)
not true if free was recognized as such by valgrind.
Greetings,
Dirk
|
|
From: John R.
|
>> Invalid read of size 4 >> >>==21380== at 0xCA30E6: pthread_mutex_unlock (in >>/lib/tls/libpthread-2.3.4.so) >>==21380== Address 0xB3275CC is 44 bytes inside a block of size 92 >>free'd >> >>==21380== at 0x4004EFA: free (vg_replace_malloc.c:235) It is obvious that the lines belong to the same process pid 21380, but it is not obvious that the two sections belong to the same error (therefore the invalid read was at address 0xB3275CC, and the read was invalid because it was from a previously-freed block.) -- |
|
From: Dirk M. <dm...@gm...> - 2007-10-09 15:59:40
|
On Tuesday 09 October 2007, John Reiser wrote: > It is obvious that the lines belong to the same process pid 21380, > but it is not obvious that the two sections belong to the same error while your interpretation of the original question was most likely incorrect (see my other mail), I think this is a valid point that I also observe in valgrind sessions with collegues: they don't understand that they both belong together. I guess this is a point where valgrind could improve. Dirk |
|
From: Dirk M. <dm...@gm...> - 2007-10-09 16:13:11
|
On Tuesday 09 October 2007, Roberto Diaz wrote: > I dont fully understand the meaning of the stack-traces presented by > valgrind after an invalid read/write. > Invalid read of size 4 > ==21380== Address 0xB3275CC is 44 bytes inside a block of size 92 > free'd if the mutex it tries to lock is with in a structure, and this structure offset is 44 bytes (and the structure is 92 bytes in total), then it sounds likely as if it is accessing deleted memory. from the backtrace it looks like a very local problem, e.g. QStreamGroupClose calls deleteGroup (which free's some memory) and then something local in QStreamGroupClose tries to unlock a mutex that was already freed. depending on the purpose of the code, it should either unlock and then free or not unlock after free. There are bigger bugs in the code because if some other thread was waiting for the lock, it will acquire the lock after unlock and then operate on deleted memory, which will likely cause it to crash. Greetings, Dirk |