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

Brought to you by: njn, sewardj, wielaard

valgrind-users

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

From: Matthias A. <gu...@un...> - 2019-03-21 19:00:36

Hello,

Why are only the '???' marks printed for the localtion of the stack
allocation? This is with 3.18.0 on Linux x64:

==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 ...'

Thanks

	matthias
-- 
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

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

From: Philippe W. <phi...@sk...> - 2019-03-21 21:45:03

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.

> 
> ==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) ?

Thanks

Philippe

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

From: Matthias A. <gu...@un...> - 2019-03-22 09:21:35

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:

(gdb) info line *0x8B43AF0
No line number information available for address 0x8b43af0 <CatTmFilterExclude@plt>

I will copy the sources over to the server.

Looks like this is near to 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215), may be in
the same source file.

	matthias
-- 
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba
instead of Nazis, to live instead of to survive.

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

From: John R. <jr...@bi...> - 2019-03-22 13:21:27

>>> ==24390==  Uninitialised value was created by a stack allocation
>>> ==24390==    at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so)
>>> ==24390==

>> Can you check what file/line nr corresponds to 0x8B43AF0,
>> using another tool (gdb, or whatever) ?

> Looks like this is near to 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215), may be in
> the same source file.

0x8B43AF0 (identified by valgrind) is somewhat far from
0x8B5DC3A (identified by the poster)
=========
   0x1a14a  d9fference

Use:
    (gdb) info shared
Example:
    $ gdb /bin/date
    (gdb) b main
    (gdb) run
    Breakpoint 1, main (argc=0x1, argv=0x7fffffffd4b8) at ../src/date.c:348
    (gdb) info shared
 From                To                  Syms Read   Shared Object Library
0x00007ffff7dd6f60  0x00007ffff7df5080  Yes         /lib64/ld-linux-x86-64.so.2
0x00007ffff7a383a0  0x00007ffff7b7f11f  Yes         /lib64/libc.so.6
    (gdb) quit

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

From: Philippe W. <phi...@sk...> - 2019-03-23 10:27:51

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

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

From: Matthias A. <gu...@un...> - 2019-03-25 08:35:01

I was lucky and catched the situation again and could attach a GDB to the
running process. It's a bit complicated because the software is a
running server with ~10 children which server altogether a web application via tomcat
and you do not know when you fire up a search in the browser, which
process will serve this. Anyway, here it is:


==17753== Conditional jump or move depends on uninitialised value(s)
==17753==    at 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215)
==17753==    by 0x8B8069C: SRVCatSearchMedia (SRVCatSearchMedia.c:579)
==17753==    by 0x74D3683: SlnpRunModule (SLNPInterpreter.c:567)
==17753==    by 0x74D31C7: SlnpInterpreter (SLNPInterpreter.c:287)
==17753==    by 0x414543: SlnpMainLoop (OPServer.c:874)
==17753==    by 0x413ED3: OPServer (OPServer.c:258)
==17753==    by 0x413792: main (OPDaemon.c:407)
==17753==  Uninitialised value was created by a stack allocation
==17753==    at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so)
==17753==
srap22dxr1:/home/sisis/guru # gdb /opt/lib/sisis/opserver/bin/OPServer 17753
...
(gdb) info line *0x8B43AF0
No line number information available for address 0x8b43af0 <CatTmFilterExclude@plt>

I did an 'objdump -S /home/sisis/guru/libcopz39.so > libcopz39.so' of the shared lib and the first
function in this is CatAdmCatClass(); setting a bt there shows:

(gdb) br CatAdmCatClass
Breakpoint 8 at 0x8b44ea9: file CATAdmCat.c, line 133.
(gdb) list CatAdmCatClass
127     static int   AdmCatSetBool(CatAdmCatValue, CatJaNein);
128     static int   AdmCatSetString(CatAdmCatValue, char *);
129     static int   AdmCatSetInt(CatAdmCatValue, int);
130
131     t_adm_cat *CatAdmCatClass()
132     {
133      return &s_adm_cat;
134     }
135
136     void CatAdmCatInitFlag(CatBool is_set)
(gdb) info line *0x8b44ea9
Line 133 of "CATAdmCat.c" starts at address 0x8b44ea9 <CatAdmCatClass+4> and ends at 0x8b44eb0 <CatAdmCatClass+11>.

i.e. the addr shown by valgrind 0x8B43AF0 has really no code in /home/sisis/guru/libcopz39.so.

Also a hex dump underpins this:

(gdb) x/2000x 0x8B43AF0
0x8b43af0 <CatTmFilterExclude@plt>:     0x6c7225ff      0xea680025      0xe9000000      0xfffff140
0x8b43b00 <g_utf8_find_prev_char@plt>:  0x6c6a25ff      0xeb680025      0xe9000000      0xfffff130
0x8b43b10 <CatClearSisError@plt>:       0x6c6225ff      0xec680025      0xe9000000      0xfffff120
0x8b43b20 <FensterZuString@plt>:        0x6c5a25ff      0xed680025      0xe9000000      0xfffff110
0x8b43b30 <FstabLoeschen@plt>:  0x6c5225ff      0xee680025      0xe9000000      0xfffff100
0x8b43b40 <Fstab_IsNormalFeld@plt>:     0x6c4a25ff      0xef680025      0xe9000000      0xfffff0f0
0x8b43b50 <RechScanFenster@plt>:        0x6c4225ff      0xf0680025      0xe9000000      0xfffff0e0
0x8b43b60 <CatZ39ExplainFree@plt>:      0x6c3a25ff      0xf1680025      0xe9000000      0xfffff0d0
0x8b43b70 <SlnpErrIsSet@plt>:   0x6c3225ff      0xf2680025      0xe9000000      0xfffff0c0
0x8b43b80 <CatAdmUserGetUsernumber@plt>:        0x6c2a25ff      0xf3680025      0xe9000000      0xfffff0b0
0x8b43b90 <CatSearchInterprete@plt>:    0x6c2225ff      0xf4680025      0xe9000000      0xfffff0a0
0x8b43ba0 <fprintf@plt>:        0x6c1a25ff      0xf5680025      0xe9000000      0xfffff090
0x8b43bb0 <BKAllgFeldNrToFstabFeldNr@plt>:      0x6c1225ff      0xf6680025      0xe9000000      0xfffff080
0x8b43bc0 <FstabHoleTabElementByOPACKurzname@plt>:      0x6c0a25ff      0xf7680025      0xe9000000      0xfffff070
0x8b43bd0 <DB_insr@plt>:        0x6c0225ff      0xf8680025      0xe9000000      0xfffff060
0x8b43be0 <RechDBEnde@plt>:     0x6bfa25ff      0xf9680025      0xe9000000      0xfffff050
0x8b43bf0 <basename@plt>:       0x6bf225ff      0xfa680025      0xe9000000      0xfffff040
0x8b43c00 <RechAnzahlNotaId@plt>:       0x6bea25ff      0xfb680025      0xe9000000      0xfffff030
0x8b43c10 <SlnpFreeRspStatus@plt>:      0x6be225ff      0xfc680025      0xe9000000      0xfffff020
0x8b43c20 <fopen64@plt>:        0x6bda25ff      0xfd680025      0xe9000000      0xfffff010
0x8b43c30 <BAZ820@plt>: 0x6bd225ff      0xfe680025      0xe9000000      0xfffff000
0x8b43c40 <CatGenListRegisterData@plt>: 0x6bca25ff      0xff680025      0xe9000000      0xffffeff0
0x8b43c50 <CatSearchCollMainTitles@plt>:        0x6bc225ff      0x00680025      0xe9000001      0xffffefe0
0x8b43c60 <RechInitAnfrageDesc@plt>:    0x6bba25ff      0x01680025      0xe9000001      0xffffefd0
0x8b43c70 <BAZ042@plt>: 0x6bb225ff      0x02680025      0xe9000001      0xffffefc0

...
0x8b44d60 <Optab_Bez@plt>:      0x633a25ff      0x11680025      0xe9000002      0xffffded0
0x8b44d70 <g_unichar_isspace@plt>:      0x633225ff      0x12680025      0xe9000002      0xffffdec0
0x8b44d80 <CatReallocList@plt>: 0x632a25ff      0x13680025      0xe9000002      0xffffdeb0
0x8b44d90 <CatSearchDuplicate@plt>:     0x632225ff      0x14680025      0xe9000002      0xffffdea0
0x8b44da0 <RSetzeFehlerText@plt>:       0x631a25ff      0x15680025      0xe9000002      0xffffde90
0x8b44db0 <__gmon_start__@plt>: 0x512225ff      0x90660025      0x521225ff      0x90660025
0x8b44dc0 <deregister_tm_clones>:       0x60058d48      0x480025a6      0xa6523d8d      0x48550025
0x8b44dd0 <deregister_tm_clones+16>:    0x8948f829      0xf88348e5      0x5d02770e      0x058b48c3
0x8b44de0 <deregister_tm_clones+32>:    0x0025503c      0x74c08548      0xe0ff5df2      0x00401f0f
0x8b44df0 <register_tm_clones>: 0x29058d48      0x480025a6      0xa6223d8d      0x48550025
0x8b44e00 <register_tm_clones+16>:      0x8948f829      0xf8c148e5      0xc2894803      0x3feac148
0x8b44e10 <register_tm_clones+32>:      0x48d00148      0x0275f8d1      0x8b48c35d      0x25517f15
0x8b44e20 <register_tm_clones+48>:      0xd2854800      0x485df274      0xe2ffc689      0x00401f0f
0x8b44e30 <__do_global_dtors_aux>:      0xa5e93d80      0x75000025      0x3d834827      0x0025518f
0x8b44e40 <__do_global_dtors_aux+16>:   0x89485500      0x480c74e5      0x62923d8b      0x65e80025
0x8b44e50 <__do_global_dtors_aux+32>:   0xe8ffffff      0xffffff68      0xc005c65d      0x010025a5
0x8b44e60 <__do_global_dtors_aux+48>:   0x1f0fc3f3      0x2e660040      0x00841f0f      0x00000000
0x8b44e70 <frame_dummy>:        0xc03d8348      0x0000254c      0x8b482674      0x2550ff05
0x8b44e80 <frame_dummy+16>:     0xc0854800      0x48551a74      0x4caa3d8d      0x89480025
0x8b44e90 <frame_dummy+32>:     0x5dd0ffe5      0xffff57e9      0x801f0fff      0x00000000
0x8b44ea0 <frame_dummy+48>:     0xffff4be9      0x894855ff      0x058d48e5      0x0025a590
0x8b44eb0 <CatAdmCatClass+11>:  0x4855c35d      0x7d89e589      0xfc458bfc      0xa9360589
0x8b44ec0 <CatAdmCatInitFlag+14>:       0x5d900025      0x894855c3      0xec8348e5      0xfc7d8910
0x8b44ed0 <CatAdmCatSetUserNumber+11>:  0x89fc458b      0x0000bfc6      0xf8e80000      0xc9000010
0x8b44ee0 <CatAdmCatSetUserNumber+27>:  0x894855c3      0xec8348e5      0xfc7d8910      0x89fc458b
0x8b44ef0 <CatAdmCatSetSortMax+15>:     0x0001bfc6      0xdce80000      0xc9000010      0x894855c3
0x8b44f00 <CatAdmCatSetDelListPath+3>:  0xec8348e5      0x7d894810      0x458b48f8      0xc68948f8

I'd say, valgrind gives a wrong address as hint about the stack allocation, or?
I don't have any clue how to nail this down further.

	matthias

-- 
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub