Stack clobbering bug

Stack clobbering bug

[Richard Stallman]

Today I started running the latest sources.  ( Emacs has crashed twice
with a clobbered stack after I typed C-g.  The stack was so badly
clobbered that I could not find any sign of where Emacs had been
running.

Has anyone else seen this?

Previously I was running a binary I made on June 18.  I am not certain
whether that was made with the latest C sources at the time.

Can someone tell me how to make a checkout of the sources as
of a given date and time?

Re: Stack clobbering bug

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 21 Jul 2006 00:47:13 -0400
> 
> Can someone tell me how to make a checkout of the sources as
> of a given date and time?

Give the "-D DATE_SPEC" option to "cvs co".

Re: Stack clobbering bug

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 21 Jul 2006 00:47:13 -0400
> 
> Today I started running the latest sources.  ( Emacs has crashed twice
> with a clobbered stack after I typed C-g.  The stack was so badly
> clobbered that I could not find any sign of where Emacs had been
> running.
> 
> Has anyone else seen this?

I just built Emacs on GNU/Linux and on MS-Windows from today's CVS,
and I don't see this problem.  Of course, you didn't post any specific
recipe to reproduce the problem, so perhaps I just didn't hit it by
chance.

Re: Stack clobbering bug

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

> Has anyone else seen this?

i see occasional crashes on C-g as well.
under gdb, backtrace looks something like:

 Starting program: /home/ttn/build/GNU/emacs/src/emacs 
     
 Program received signal SIGSEGV, Segmentation fault.
 0x40131f7a in XSetClipRectangles () from /usr/X11R6/lib/libX11.so.6
 (gdb) bt
 #0  0x40131f7a in XSetClipRectangles () from /usr/X11R6/lib/libX11.so.6
 #1  0x4011d212 in _XFlushGCCache () from /usr/X11R6/lib/libX11.so.6
 #2  0x00800040 in ?? ()
 Cannot access memory at address 0x40038

i haven't looked further.  what is a good way
to get more useful info than this from gdb?

thi

Re: Stack clobbering bug

[Andreas Schwab]

Thien-Thi Nguyen <ttn@gnu.org> writes:

>  Program received signal SIGSEGV, Segmentation fault.
>  0x40131f7a in XSetClipRectangles () from /usr/X11R6/lib/libX11.so.6
>  (gdb) bt
>  #0  0x40131f7a in XSetClipRectangles () from /usr/X11R6/lib/libX11.so.6
>  #1  0x4011d212 in _XFlushGCCache () from /usr/X11R6/lib/libX11.so.6
>  #2  0x00800040 in ?? ()
>  Cannot access memory at address 0x40038
>
> i haven't looked further.  what is a good way
> to get more useful info than this from gdb?

You need to install debug info for libX11.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Stack clobbering bug

[Richard Stallman]

      #2  0x00800040 in ?? ()
      Cannot access memory at address 0x40038

That "Cannot access memory" suggests that the stack is clobbered.  On
some platforms, with some kinds of optimization, there is no frame
pointer and chasing the stack requires some additional info.
However, aside from such cases, the lack of debug info for a library
should not stop GDB from finding and displaying further frames.
So I think the stack is clobbered, as it was in my case.

    i haven't looked further.  what is a good way
    to get more useful info than this from gdb?

The first thing to do is x/20xw  $sp
and then repeat x/20xw a few times
to see if part of the stack is clobbered with -1.

However, I suspect that the way to debug this is to try
the sources from various different dates, and determine
which change made the problem start to happen.

Re: Stack clobbering bug

[Richard Stallman]

    I just built Emacs on GNU/Linux and on MS-Windows from today's CVS,
    and I don't see this problem.  Of course, you didn't post any specific
    recipe to reproduce the problem, so perhaps I just didn't hit it by
    chance.

It is unreproducible and has happened to me twice in a little more
than a day.

I hope that someone else will experience this problem, and will do the
work of binary-searching dates to find out when it was introduced.
If no one else does it, I will do it; but since I am so overloaded,
it may take a while for me to do it.

Re: Stack clobbering bug

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

> The first thing to do is x/20xw  $sp
> and then repeat x/20xw a few times
> to see if part of the stack is clobbered with -1.

appended is some gdb output for the latest crash.  i don't
see any -1 (assuming its representation is 0xffffffff).

thi

___________________________________________
(gdb) bt
#0  0x40131d95 in _XSetClipRectangles () from /usr/X11R6/lib/libX11.so.6
Cannot access memory at address 0x8
(gdb) x/20xw $sp
0xbfffe2a8:  0x085c9aa8  0x00000000  0x0805ece8  0x085ef2c0
0xbfffe2b8:  0x00000001  0xbfffe30c  0x0805ecd3  0x00000008
0xbfffe2c8:  0x00000001  0xbfffe30c  0x40131f77  0x085c9aa8
0xbfffe2d8:  0x087ce7c8  0x00000000  0x00000000  0xbfffe354
0xbfffe2e8:  0x00000001  0x00000000  0x40131f3d  0xbfffe414
(gdb) x/20xw
0xbfffe2f8:  0xbfffe354  0xbfffe32c  0x4011d270  0x085c9aa8
0xbfffe308:  0x087ce7c8  0x085ca048  0x4011d212  0x401dbfdc
0xbfffe318:  0x085c9aa8  0x087ce7c8  0x00000000  0x091c7a78
0xbfffe328:  0xbfffe414  0xbfffe35c  0x40131ffb  0x085c9aa8
0xbfffe338:  0x087ce7c8  0x00000000  0x40131fbe  0x091c7a78
(gdb) x/20xw
0xbfffe348:  0xbfffe414  0x00000000  0x00000000  0xbfffe404
0xbfffe358:  0x00000001  0xbfffe3ec  0x080b409e  0x085c9aa8
0xbfffe368:  0x087ce7c8  0x00000000  0xbfffe398  0x00000000
0xbfffe378:  0x00000001  0x085ef2c0  0x080768e1  0x08a7f048
0xbfffe388:  0x08c4b1e0  0xbfffe3bc  0x0805dcb2  0x085ef2c0
(gdb) x/20xw
0xbfffe398:  0x00000000  0xbfffe404  0xbfffe3c8  0x085ef2c0
0xbfffe3a8:  0x00000000  0x091c7a78  0x080768e1  0x085ef2c0
0xbfffe3b8:  0x00000000  0xbfffe3ec  0x0805dddc  0x085ef2c0
0xbfffe3c8:  0x00000001  0xbfffe56c  0x08078958  0x085ef2c0
0xbfffe3d8:  0x00000001  0x00000000  0x0000000c  0x00000000
(gdb) x/20xw
0xbfffe3e8:  0x00000016  0xbfffe56c  0x08078a18  0x085ef2c0
0xbfffe3f8:  0x00000001  0x000003fd  0x00000000  0x00002020
0xbfffe408:  0x00000001  0x085ef2c0  0x00800011  0x00000001
0xbfffe418:  0x000002d7  0x000002e9  0x0000000c  0x0000000c
0xbfffe428:  0x00000016  0x00000000  0x00000000  0x085eefe8

Re: Stack clobbering bug

[Richard Stallman]

There is no obvious clobberage in your stack data.  Can you try
looking at it for something that resembles a chain of stack frames?
If you find them, there is a GDB command you can use to examie a stack
frame at a specified address.

Re: Stack clobbering bug

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

> There is no obvious clobberage in your stack data.  Can you try
> looking at it for something that resembles a chain of stack frames?
> If you find them, there is a GDB command you can use to examie a stack
> frame at a specified address.

ok, will do that the next time it crashes.

thi