|
From: Jonathan A. Z. <jon...@nu...> - 2004-10-27 15:54:26
|
Hi there! I'm using valgrind to try and debug a server application. The server application has a set of plugins that it uses dlopen to call, so they're not linked directly with the application. Valgrind's (understandably) having trouble reporting where in these plug-in libs there are problems (as shown below). I was wondering if there's any way I can use valgrind to get this information. In the example below, I'd be looking for a line number in libscsp.c somewhere. Thanks! ==26459== Use of uninitialised value of size 4 ==26459== at 0x1BA24D52: __GI_____strtol_l_internal (in /lib/tls/libc-2.3.3.so) ==26459== by 0x1BA24ADE: __GI___strtol_internal (in /lib/tls/libc-2.3.3.so) ==26459== by 0x1B9BB9CB: NDWBlh_scsp (stdlib.h:333) ==26459== by 0x804AAFF: process_connection (messaged.c:1359) ==26459== ==26459== Conditional jump or move depends on uninitialised value(s) ==26459== at 0x1BA24D73: __GI_____strtol_l_internal (in /lib/tls/libc-2.3.3.so) ==26459== by 0x1BA24ADE: __GI___strtol_internal (in /lib/tls/libc-2.3.3.so) ==26459== by 0x1B9BB9CB: NDWBlh_scsp (stdlib.h:333) ==26459== by 0x804AAFF: process_connection (messaged.c:1359) ==26459== |
|
From: Paul P. <ppl...@gm...> - 2004-10-27 18:15:36
|
On Wed, 27 Oct 2004 11:53:06 -0400, Jonathan A. Zdziarski <jon...@nu...> wrote: > Valgrind's (understandably) > having trouble reporting where in these plug-in libs there are problems > (as shown below). Your output does not show any problems (with VG) that I can see, nor should you expect VG to have any trouble under the conditions you described. I think you just need to RTFM, paying particular attention to the --num-callers= flag. Cheers, |
|
From: Jonathan A. Z. <jon...@nu...> - 2004-10-27 18:22:51
|
==26459== Use of uninitialised value of size 4 is a problem, clearly Paul Pluzhnikov wrote: > On Wed, 27 Oct 2004 11:53:06 -0400, Jonathan A. Zdziarski > <jon...@nu...> wrote: > > >>Valgrind's (understandably) >>having trouble reporting where in these plug-in libs there are problems >>(as shown below). > > > Your output does not show any problems (with VG) that I can see, nor should you > expect VG to have any trouble under the conditions you described. > > I think you just need to RTFM, paying particular attention to the > --num-callers= flag. > > Cheers, > > !DSPAM:417fe59b69842714714304! > > > |
|
From: Tom H. <th...@cy...> - 2004-10-27 18:29:28
|
In message <417...@nu...>
"Jonathan A. Zdziarski" <jon...@nu...> wrote:
> I'm using valgrind to try and debug a server application. The server
> application has a set of plugins that it uses dlopen to call, so they're
> not linked directly with the application. Valgrind's (understandably)
> having trouble reporting where in these plug-in libs there are problems
> (as shown below). I was wondering if there's any way I can use valgrind
> to get this information. In the example below, I'd be looking for a line
> number in libscsp.c somewhere.
The problem is that you are inside an inlined call to strtol in
NDWBlh_scsp so the current source line is actually in stdlib.h
and not in libscsp.c at all.
Because no stack frame is created for an inline function there
is nothing for valgrind to show you - you may be able to recompile
with options that prevent inlining though.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Igmar P. <mai...@jd...> - 2004-10-27 19:58:50
|
> Because no stack frame is created for an inline function there > is nothing for valgrind to show you - you may be able to recompile > with options that prevent inlining though. Depending on whether the function is considered internal, -fno-inline or -fno-builtin if it is considered. Most string and malloc functions are considered internal. If I read the manual correctly, -fno-inline disables all inlining, also for internal functions. Igmar |