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.
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 (6.3.0.0-1.84rh) 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 () (gdb) 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.