Re: [Valgrind-users] location of stack allocation printed a at 0x8B43AF0: ??? ...

[Philippe W. <phi...@sk...>]

On Fri, 2019-03-22 at 10:21 +0100, Matthias Apitz wrote:
> El día Thursday, March 21, 2019 a las 10:44:54PM +0100, Philippe Waroquiers escribió:
> 
> > On Thu, 2019-03-21 at 20:00 +0100, Matthias Apitz wrote:
> > > Hello,
> > > 
> > > Why are only the '???' marks printed for the localtion of the stack
> > > allocation? This is with 3.18.0 on Linux x64:
> > 
> > 3.18.0 ?
> > Last release is 3.14.
> 
> Yep. Sorry, this was a typo. I have 3.14.0, compiled by my own on SuSE
> Linux SLES 12.
> 
> > > ==24390== Conditional jump or move depends on uninitialised value(s)
> > > ==24390==    at 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215)
> > > ==24390==    by 0x8B8069C: SRVCatSearchMedia (SRVCatSearchMedia.c:579)
> > > ==24390==    by 0x74D3683: SlnpRunModule (SLNPInterpreter.c:567)
> > > ==24390==    by 0x74D31C7: SlnpInterpreter (SLNPInterpreter.c:287)
> > > ==24390==    by 0x414543: SlnpMainLoop (OPServer.c:874)
> > > ==24390==    by 0x413ED3: OPServer (OPServer.c:258)
> > > ==24390==    by 0x413792: main (OPDaemon.c:407)
> > > ==24390==  Uninitialised value was created by a stack allocation
> > > ==24390==    at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so)
> > > ==24390==
> > > 
> > > /home/sisis/guru # file libcopz39.so
> > > libcopz39.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=eb1d460ebb565dedfe48bf5f534d2c097d9ca59c, with debug_info, not stripped
> > > 
> > > The *.o files in the shared lib have been compiled with 'gcc -m64 -g ...'
> > 
> > Can you check what file/line nr corresponds to 0x8B43AF0,
> > using another tool (gdb, or whatever) ?
> 
> I have to check how to convert he addr 0x8B43AF0 into a line:

What I am typically doing is the following:
   valgrind --vgdb-error=1 <your_program>

(assuming that is the first reported error).
Then valgrind will stop and wait for GDB to connect.
Then do the following:
gdb
target remote | vgdb  
info line *0x8B43AF0

When you do that when attached to the running executable, that will
guarantee that the shared lib address translation is done using
the address at which it is currently loaded.

If GDB equally tells that there is no source/line nr, then I guess
that is the best valgrind can do.

Philippe