|
From: Holger K. <hka...@ma...> - 2008-04-22 10:54:10
|
Hi, I've got a problem of a invalid reads from a valid address area, reported by memcheck: ==16933== Thread 3: ==16933== Invalid read of size 8 ==16933== at 0x41177D: _talloc_free (talloc.c:388) ==16933== by 0x4117B4: _talloc_free (talloc.c:392) ==16933== by 0x411EA0: talloc_free (talloc.c:738) ==16933== by 0x405138: stat_thread (radstatd.c:937) ==16933== by 0x38D1D06136: start_thread (in /lib64/tls/libpthread-2.3.4.so) ==16933== by 0x38D12C7532: clone (in /lib64/tls/libc-2.3.4.so) ==16933== Address 0xaf00cf8 is 32 bytes inside a block of size 96 alloc'd ==16933== at 0x4904E27: malloc (vg_replace_malloc.c:207) ==16933== by 0x410F38: __talloc (talloc.c:197) ==16933== by 0x410E97: _talloc_named_const (talloc.c:279) ==16933== by 0x412610: _talloc_zero (talloc.c:1068) ==16933== by 0x407C1E: avpair_assign_tag (funcs.c:757) ==16933== by 0x40A769: generate26 (funcs.c:2063) ==16933== by 0x40A127: gen_valpairs (funcs.c:1887) ==16933== by 0x4061AB: listen_cb (radstatd.c:1425) ==16933== by 0x4A1F587: event_base_loop (event.c:309) ==16933== by 0x4063DA: listen_thread (radstatd.c:1480) ==16933== by 0x38D1D06136: start_thread (in /lib64/tls/libpthread-2.3.4.so) ==16933== by 0x38D12C7532: clone (in /lib64/tls/libc-2.3.4.so) ... ==16933== Thread 2: ==16933== Invalid read of size 8 ==16933== at 0x405892: cleanup_thread (radstatd.c:1153) ==16933== by 0x38D1D06136: start_thread (in /lib64/tls/libpthread-2.3.4.so) ==16933== by 0x38D12C7532: clone (in /lib64/tls/libc-2.3.4.so) ==16933== Address 0xaf00c58 is 80 bytes inside a block of size 160 alloc'd ==16933== at 0x4904E27: malloc (vg_replace_malloc.c:207) ==16933== by 0x410F38: __talloc (talloc.c:197) ==16933== by 0x410E97: _talloc_named_const (talloc.c:279) ==16933== by 0x412610: _talloc_zero (talloc.c:1068) ==16933== by 0x4041EA: create_session (radstatd.c:528) ==16933== by 0x4046D7: update_session (radstatd.c:649) ==16933== by 0x404CB6: update_stats (radstatd.c:802) ==16933== by 0x405102: stat_thread (radstatd.c:935) ==16933== by 0x38D1D06136: start_thread (in /lib64/tls/libpthread-2.3.4.so) ==16933== by 0x38D12C7532: clone (in /lib64/tls/libc-2.3.4.so) I don't know how to further trace this problem as I don't understand why this error is reported. In which circumstances are such errors reported? I found several threads on this list, addressing this kind of problem, but could not get any hints for my case. I'm using valgrind version 3.3.0, gcc version 3.4.6 (and the talloc-layer from the samba-project). Thanks, Holger |
|
From: Christoph B. <bar...@or...> - 2008-04-22 11:27:47
|
Hi, check whether the pointer you free in the second line is valid: > ==16933== by 0x411EA0: talloc_free (talloc.c:738) > ==16933== by 0x405138: stat_thread (radstatd.c:937 Show the source code of the stat_thread() function. Greetings Christoph |
|
From: Julian S. <js...@ac...> - 2008-04-22 11:37:35
|
> I don't know how to further trace this problem as I don't understand why > this error is reported. > In which circumstances are such errors reported? > I'm using valgrind version 3.3.0, gcc version 3.4.6 (and the > talloc-layer from the samba-project). Yes, that is a bit strange. My first question is: do the Samba people have any hints/advice/ special guidance, for using Memcheck on code that uses their talloc layer? I believe Samba use Memcheck quite a bit, so I assume they have figured out how to make Memcheck+talloc work well together. (Maybe nothing needs to be done, but generally one has to be careful about these custom allocators.) J |
|
From: Tom H. <to...@co...> - 2008-04-22 12:37:37
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> I don't know how to further trace this problem as I don't understand why
>> this error is reported.
>> In which circumstances are such errors reported?
>
>> I'm using valgrind version 3.3.0, gcc version 3.4.6 (and the
>> talloc-layer from the samba-project).
>
> Yes, that is a bit strange.
>
> My first question is: do the Samba people have any hints/advice/
> special guidance, for using Memcheck on code that uses their
> talloc layer? I believe Samba use Memcheck quite a bit, so
> I assume they have figured out how to make Memcheck+talloc
> work well together. (Maybe nothing needs to be done, but
> generally one has to be careful about these custom allocators.)
I suspect that talloc must have valgrind client requests in - it's
the only way I can think of to get the reported error.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2008-04-22 12:41:16
|
> I suspect that talloc must have valgrind client requests in - it's > the only way I can think of to get the reported error. Yes, I agree. In which case, if the Samba people put magic hacks in talloc to make it work with Memcheck, maybe they have some instructions on how to use the two of them together. J |
|
From: Holger K. <hka...@ma...> - 2008-04-22 12:47:50
|
Hi Julian Seward wrote: > Yes, that is a bit strange. > > My first question is: do the Samba people have any hints/advice/ > special guidance, for using Memcheck on code that uses their > talloc layer? I believe Samba use Memcheck quite a bit, so > I assume they have figured out how to make Memcheck+talloc > work well together. (Maybe nothing needs to be done, but > generally one has to be careful about these custom allocators.) > I did not find anything about using valgrind + talloc on a first look. But I don't supect talloc to be the problem because I'm using it in another productive application for months without problems, and have been tracing this appliication using valgrind many times without running into any particular problems like this. Maybe my second example is better because it does not contain any talloc-call in the stack-trace that leads to the Invalid Read. Holger |
|
From: Holger K. <hka...@ma...> - 2008-04-22 12:46:55
|
Hi. Christoph Bartoschek wrote: > Hi, > > check whether the pointer you free in the second line is valid: > > >> ==16933== by 0x411EA0: talloc_free (talloc.c:738) >> ==16933== by 0x405138: stat_thread (radstatd.c:937 >> > > Show the source code of the stat_thread() function. > I'm pretty sure the pointer is valid, because I have still a lot of debug-printf-s in my code tracking this pointer, without getting any mem-violations; in the mentioned case: /---- stat_thread() ... /* process the request */ update_stats(authreq); fprintf(stderr, "%s: ill: trying to free %p (%s@%s; %p)\n", __func__, authreq, authreq->uid, authreq->realm, authreq->request); talloc_free(authreq); ---/ BTW: I am getting this error message very rarely (avg. every 7 mins, reaching the point above several 100 times a second) |
|
From: Christoph B. <bar...@or...> - 2008-04-22 12:54:47
|
Am Dienstag, 22. April 2008 schrieb Holger Kaelberer: > /---- stat_thread() > ... > /* process the request */ > update_stats(authreq); > fprintf(stderr, "%s: ill: trying to free %p (%s@%s; %p)\n", __func__, > authreq, authreq->uid, authreq->realm, authreq->request); > talloc_free(authreq); > ---/ Can you run it with standard malloc instead of talloc? |
|
From: Holger K. <hka...@ma...> - 2008-04-23 09:39:25
|
Christoph Bartoschek wrote: > Am Dienstag, 22. April 2008 schrieb Holger Kaelberer: > > >> /---- stat_thread() >> ... >> /* process the request */ >> update_stats(authreq); >> fprintf(stderr, "%s: ill: trying to free %p (%s@%s; %p)\n", __func__, >> authreq, authreq->uid, authreq->realm, authreq->request); >> talloc_free(authreq); >> ---/ >> > > Can you run it with standard malloc instead of talloc? > Ufff, that would mean rewriting a lot of code, I wouldn't like to do that before other possible solutions are evaluated. |
|
From: Holger K. <hka...@ma...> - 2008-04-23 09:46:38
|
Julian Seward wrote: >> I suspect that talloc must have valgrind client requests in - it's >> the only way I can think of to get the reported error. >> > > Yes, I agree. > > In which case, if the Samba people put magic hacks in talloc to make > it work with Memcheck, maybe they have some instructions on how to > use the two of them together. > J > > I did not find any valgrind-calls/-macros in the code (cf. *talloc*.samba.org). Anyway, I will post at samba-technical. Could a hardware problem be the cause? One more thing: I recently switched to glib2 hash-tables that use internally the glib slice-allocator, as far as I know. Any interference possible here? Do you have experiences / know about problems when using valgrind+glib2? Thanks, Holger |
|
From: Holger K. <hka...@ma...> - 2008-04-26 09:21:56
|
Holger Kaelberer wrote on Wed Apr 23, 2008 um 11:46:34AM: > > I did not find any valgrind-calls/-macros in the code (cf. > *talloc*.samba.org). Anyway, I will post at samba-technical. FYI: No particular problems have been reported by the people @samba-technical when using valgrind on talloc. Still I don't understand the sense of the error-message, any further suggestions are welcome. Thanks, Holger |
|
From: Christoph B. <bar...@or...> - 2008-04-26 09:31:16
|
Am Samstag, 26. April 2008 schrieb Holger Kaelberer: > Holger Kaelberer wrote on Wed Apr 23, 2008 um 11:46:34AM: > > I did not find any valgrind-calls/-macros in the code (cf. > > *talloc*.samba.org). Anyway, I will post at samba-technical. > > FYI: No particular problems have been reported by the people > @samba-technical when using valgrind on talloc. > > Still I don't understand the sense of the error-message, any further > suggestions are welcome. 1. Show more code and a way to reproduce it 2. Slim it down to a small testcase 3. Use VALGRIND_CHECK_VALUE_IS_DEFINED to track the specific byte that is causing the error and trace its origin. 4. Check the code with helgrind for race conditions. |