Bug 1789 - assert() corrupts the stack?
Summary: assert() corrupts the stack?
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.2
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
Depends on:
Reported: 2005-11-03 09:57 UTC by BK
Modified: 2016-05-20 19:47 UTC (History)
2 users (show)

See Also:
Host: Ubuntu Linux 2.6.10-5-686
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description BK 2005-11-03 09:57:27 UTC
Here is the sample program:
#include <assert.h>
int main(void){
   int i = 1;
   assert(i == 0);
   return 0;

It compiles OK (gcc -g t.c); it runs OK, stopping at the assertion like it 
should. But here's the output from running the program under gdb:

(gdb) run
a.out: t.c:5: main: Assertion `i == 0' failed.

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7ed6175 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7ed77d8 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xbffff4f0 in ?? ()
#4  0x00000000 in ?? ()
#5  0x00000020 in ?? ()
#6  0x00000000 in ?? ()
[... many null pointers...]
#36 0x00000000 in ?? ()
#37 0xb7f19307 in _IO_file_write () from /lib/tls/i686/cmov/libc.so.6
Previous frame inner to this frame (corrupt stack?)

I don't know if gdb's "corrupt stack?" claim is true, but assert() pretty 
consistently gives me this less-than-useless backtrace. Call me a crappy 
programmer, but without a backtrace I have a lot of trouble fixing my code.
Comment 1 Dwayne Grant McConnell 2005-11-07 17:25:53 UTC
I tried this testcase on Fedora Core 4 i386 running on a Pentium 4 box and I get

$ gdb a.out
GNU gdb Red Hat Linux (
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /home/dwayne/glibc/bug/1789/a.out
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x49c000
a.out: t.c:4: main: Assertion `i == 0' failed.

Program received signal SIGABRT, Aborted.
0x0049c402 in __kernel_vsyscall ()

It seems to me the problem is likely to either be Ubuntu specific or a problem
with gdb. My advice is to open an Ubuntu bug at http://bugzilla.ubuntu.com/.
When you do that you will want to tell them the version of glibc, gcc, and gdb
that you are using. This information is available from dpkg I believe.

I'm going to mark this bug as INVALID because there is not enough information to
demonstrate that this is a generic glibc bug.