Need help with stack smash

[Orion Poplawski]

I'm trying to debug a stack smash in of the hdf test programs but am 
having a hard time tracking down exactly where the smash happens.  Is 
there any way to watch the guard variable with gdb to find exactly when 
it happens?  Something similar?

Thanks!

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  orion(a)cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

[Adam Jackson]

On Thu, 2009-08-27 at 12:36 -0600, Orion Poplawski wrote:
>  I'm trying to debug a stack smash in of the hdf test programs but
> am 
>  having a hard time tracking down exactly where the smash happens.  Is 
>  there any way to watch the guard variable with gdb to find exactly when 
>  it happens?  Something similar? 
(gdb) help watch
Set a watchpoint for an expression.
A watchpoint stops execution of your program whenever the value of
an expression changes.

Note that this means what it says: if your expression contains a symbol
that goes out of scope before the change happens, then the watchpoint
will be forgotten, because the value of the expression will change from
being a value to being not-a-thing.  So you would need to set the watch
on the address in memory of what you're trying to watch, and not
necessarily on its symbolic name.

- ajax

[Roland McGrath]

>  Note that this means what it says: if your expression contains a
> symbol
>  that goes out of scope before the change happens, then the watchpoint
>  will be forgotten, because the value of the expression will change from
>  being a value to being not-a-thing.  So you would need to set the watch
>  on the address in memory of what you're trying to watch, and not
>  necessarily on its symbolic name. 
Indeed.  Usually the convenient thing to do is:

(gdb) p &foo->bar
$22 = (int *) 0x12345
(gdb) watch *$22

[Orion Poplawski]

On 08/27/2009 01:42 PM, Roland McGrath wrote:
> > Note that this means what it says: if your expression contains a
> symbol
> > that goes out of scope before the change happens, then the watchpoint
> > will be forgotten, because the value of the expression will change from
> > being a value to being not-a-thing.  So you would need to set the watch
> > on the address in memory of what you're trying to watch, and not
> > necessarily on its symbolic name.
>
>  Indeed.  Usually the convenient thing to do is:
>
>  (gdb) p&foo->bar
>  $22 = (int *) 0x12345
>  (gdb) watch *$22 

Thanks, but my trouble though is what to watch.  My thought was to watch 
the location of the guard variable that the stack protector code checks, 
but I have no idea how to find that out.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  orion(a)cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

[Jerry James]

On Thu, Aug 27, 2009 at 1:59 PM, Orion Poplawski<orion(a)cora.nwra.com> wrote:
>  Thanks, but my trouble though is what to watch.  My thought was to
> watch the
>  location of the guard variable that the stack protector code checks, but I
>  have no idea how to find that out.
>
>  --
>  Orion Poplawski
>  Technical Manager                     303-415-9701 x222
>  NWRA/CoRA Division                    FAX: [phone]
>  3380 Mitchell Lane                  orion(a)cora.nwra.com
>  Boulder, CO 80301              http://www.cora.nwra.com 
When I can't determine when a program first goes wrong, and when I can
put up with a big execution slowdown, I run the code with valgrind
--db-attach=yes.  That doesn't always reveal the cause, but it does
quite often.
-- 
Jerry James
http://www.jamezone.org/

[Orion Poplawski]

On 08/27/2009 02:26 PM, Jerry James wrote:
>  When I can't determine when a program first goes wrong, and when
> I can
>  put up with a big execution slowdown, I run the code with valgrind
>  --db-attach=yes.  That doesn't always reveal the cause, but it does
>  quite often. 
Funnily enough, it runs fine under valgrind (or at least past the point 
where it crashed before.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  orion(a)cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

[Orion Poplawski]

On 08/27/2009 01:59 PM, Orion Poplawski wrote:
>  Thanks, but my trouble though is what to watch. My thought was to
> watch
>  the location of the guard variable that the stack protector code checks,
>  but I have no idea how to find that out.
>  
By looking at the disassembly of the funtcion, I'm able to see the stack 
check code at the end:

0x08058f39 <an_check_lab_desc+553>:     mov    -0x1c(%ebp),%eax
0x08058f3c <an_check_lab_desc+556>:     xor    %gs:0x14,%eax
0x08058f43 <an_check_lab_desc+563>:     jne    0x8058f50 
<an_check_lab_desc+576>

so it's watching %ebp - 0x1c (it appears).

(gdb) print $ebp - 0x1c
$1 = (PTR TO -> ( void )) 0xbfffcb5c
(gdb) watch *(0xbfffcb5c)
Hardware watchpoint 2: *(0xbfffcb5c)
(gdb) c
Continuing.
Hardware watchpoint 2: *(0xbfffcb5c)

Old value = -987698962
New value = -987699200
DFANIgetann (filename=0x8125d10 "tdfanF.hdf", tag=<value optimized out>,
     ref=<value optimized out>, ann=0xbfffcb3e "Object label #1: sds 
       ",
     maxlen=31, type=0) at dfan.c:1103
1103      Lastref = annref;   /* remember ref last accessed */
Current language:  auto; currently c
(gdb) list
1098          HCLOSE_GOTO_ERROR(file_id,DFE_READERROR,FAIL);
1099        }
1100      if (type == DFAN_LABEL)
1101        ann[annlen] = '\0';     /* terminate string properly */
1102
1103      Lastref = annref;   /* remember ref last accessed */
(gdb) print &ann[annlen]
$7 = (uint8 *) 0xbfffcb5c ""

So that's where I get clobbered.  Need to figure out why, but at least I 
solved the watch location question.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  orion(a)cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

[Roland McGrath]

>  So that's where I get clobbered.  Need to figure out why, but at
> least I 
>  solved the watch location question. 
Yes.  Sorry I disappeared there for a bit talking to compiler people about
whether there is a method other than reading the disassembly to find it.
I think there isn't, but I'll see what we can do about making one.


Thanks,
Roland

[John Reiser]

>  Hardware watchpoint 2: *(0xbfffcb5c)
>
>  Old value = -987698962
>  New value = -987699200
>  DFANIgetann (filename=0x8125d10 "tdfanF.hdf", tag=<value optimized out>,
>  ref=<value optimized out>, ann=0xbfffcb3e "Object label #1: sds ",
>  maxlen=31, type=0) at dfan.c:1103
>  1103 Lastref = annref; /* remember ref last accessed */
>  Current language: auto; currently c
>  (gdb) list
>  1098 HCLOSE_GOTO_ERROR(file_id,DFE_READERROR,FAIL);
>  1099 }
>  1100 if (type == DFAN_LABEL)
>  1101 ann[annlen] = '\0'; /* terminate string properly */
>  1102
>  1103 Lastref = annref; /* remember ref last accessed */
>  (gdb) print &ann[annlen]
>  $7 = (uint8 *) 0xbfffcb5c ""
>
>  So that's where I get clobbered. Need to figure out why, but at least I
>  solved the watch location question. 
Because this is a trap which happens AFTER the damage has been done,
then the location identified (line 1103) is the NEXT point of
execution.  The damage was done one [dynamic] statement prior,
in this case line 1101: ann[annlen] = '\0';
This can be corroborated by looking at the watch values in hex:
(gdb) set output-radix 16
(gdb) p -987698962
$1 = 0xc520e8ee
(gdb) p -987699200
$2 = 0xc520e800   ### low byte set to '\0'

--

[Ralf Ertzinger]

Hi.

On Thu, 27 Aug 2009 14:49:40 -0700, John Reiser wrote:

>  execution.  The damage was done one [dynamic] statement prior,
>  in this case line 1101: ann[annlen] = '\0'; 
And that looks like a typical one-off-error.