[Converted from Gnats 1547] Server receives SIGSEGV, program stops. But when I called 'bt', GDB 5.3 shows me frames without any symbol table information (only address), 6.0 says: "Previous frame inner to this frame (corrupt stack?)". GDB typescripts are in attachments. It repeats very often, I don't know what to do. Error happens cause 'tmp' is 'char tmp[30]', but 'i' is aproximatly 62438. But how to fix if stack is "corrupted"? Is this a bug or maybe it has another explanation?.. Release: 5.3 & 6.0 also Environment: Red Hat Linux release 6.2 (Zoot). Kernel 2.2.14-5.0 on an i686. How-To-Repeat: Get chessd called lasker (v.2.2.2.) from http://chess.samba.org/, enter as guests, create match by command "match guest_nick 20 150 black", and make first move - 'd2d3'. Thats all.
From: "Nikita \"Lestat\" Andreev" <nik@kemsu.ru> To: <chastain@sourceware.org>, <gdb-prs@sources.redhat.com>, <nik@kemsu.ru>, <nobody@sources.redhat.com>, <gdb-gnats@sources.redhat.com> Cc: Subject: Re: backtrace/1547: corrupt stack? Date: Mon, 9 Feb 2004 17:52:44 +0700 This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C3EF35.857DDFB0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hi! Sorry, but I can't understand how to work with http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb. How to reply on bug reports? I didn't see any "Edit Problem Report Page". Right report is 1548. But I give you duplicate in attachment. Thanks. ----- Original Message ----- From: <chastain@sourceware.org> To: <chastain@sourceware.org>; <gdb-prs@sources.redhat.com>; <nik@kemsu.ru>; <nobody@sources.redhat.com> Sent: Monday, February 09, 2004 5:32 PM Subject: Re: backtrace/1547: corrupt stack? > Synopsis: corrupt stack? > > Responsible-Changed-From-To: unassigned->chastain > Responsible-Changed-By: chastain > Responsible-Changed-When: Mon Feb 9 10:32:59 2004 > Responsible-Changed-Why: > > Mine. > > State-Changed-From-To: open->feedback > State-Changed-By: chastain > State-Changed-When: Mon Feb 9 10:32:59 2004 > State-Changed-Why: > I need the gdb typescript that you mentioned. > > I tried running lasker 2.2.2 on red hat linux 8.0. > It worked fine. I logged in as admin, then logged in twice more as two guests, did "match guest EYWJ 20 150 black", and moved d2d3, d7d6, e2e4, e7e5. Worked fine. > > I really need that typescript to see what you are talking about. > > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&databas e=gdb&pr=1547 > ------=_NextPart_000_0028_01C3EF35.857DDFB0 Content-Type: application/octet-stream; name="gdb.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="gdb.log" -------------------------------------------------------------------------= --- 5.3 -------------------------------------------------------------------------= --- Script started on Fri Feb 6 14:01:44 2004 [root@radius chessd]# gdb GNU gdb 19991004 Copyright 1998 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". (gdb) file /usr/local/debug-chess/chessd/bin/chessd Reading symbols from /usr/local/debug-chessd/chessd/bin/chessd...done. (gdb) attach 17544 Attaching to program: /usr/local/debug-chessd/chessd/bin/chessd, Pid = 17544 Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from = /usr/local/debug-chessd/chessd/./lib/chessd.so...done. 0x1dbc61 in __libc_nanosleep () from /lib/libc.so.6 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x2501b6 in holding_str (holding=3D0x2abe1c) at board.c:176 176 tmp[i++] =3D wpstring[p][0]; (gdb) bt #0 0x2501b6 in holding_str (holding=3D0x2abe1c) at board.c:176 #1 0x2502e5 in append_holding_display (buf=3D0x2ac520 'P' <repeats 200 = times>..., gs=3D0x2abd1c, white=3D1) at board.c:205 #2 0x2506ad in board_to_string (wn=3D0x2506ad "\215\203\004\b", = bn=3D0x2ac520 'P' <repeats 200 times>..., wt=3D2800924, bt=3D1,=20 b=3D0x2abd1c, ml=3D0x2bb978, style=3D135640364, orientation=3D0, = relation=3D-1073745028, p=3D2481331) at board.c:297 #3 0xbffff300 in ?? () #4 0x804a788 in ?? () -------------------------------------------------------------------------= --- 6.0 -------------------------------------------------------------------------= --- Script started on Sat Feb 7 17:29:32 2004 [root@radius chessd]# gdb GNU gdb 6.0 Copyright 2003 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 "i686-pc-linux-gnu". (gdb) fiel bin/chessd Reading symbols from bin/chessd...done. (gdb) attach 18551 Attaching to program: /usr/local/debug-chessd/chessd/bin/chessd, process = 18551 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from ./lib/chessd.so...done. Loaded symbols for ./lib/chessd.so 0x001f717e in __select () from /lib/libc.so.6 (gdb) bt #0 0x001f717e in __select () from /lib/libc.so.6 #1 0x0026ff98 in select_loop () at network.c:593 #2 0x08048d78 in main_event_loop () at ficsmain.c:90 #3 0x08049222 in main (argc=3D5, argv=3D0xbffffa44) at ficsmain.c:232 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x002501b6 in holding_str (holding=3D0x2abe1c) at board.c:176 176 tmp[i++] =3D wpstring[p][0]; (gdb) bt #0 0x002501b6 in holding_str (holding=3D0x2abe1c) at board.c:176 #1 0x002502e5 in append_holding_display (buf=3D0x2ac520 'P' <repeats = 200 times>..., gs=3D0x2abd1c, white=3D1) at board.c:205 #2 0x002506ad in board_to_string (wn=3D0x2506ad "\215\203\004\b", = bn=3D0x2ac520 'P' <repeats 200 times>..., wt=3D2800924, bt=3D1,=20 b=3D0x2abd1c, ml=3D0x2bb978, style=3D135618500, orientation=3D0, = relation=3D-1073745028, p=3D2481331) at board.c:297 Previous frame inner to this frame (corrupt stack?) (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/debug-chessd/chessd/bin/chessd, = process 18551 [root@radius chessd]# exit Script done on Sat Feb 7 17:32:46 2004 ------=_NextPart_000_0028_01C3EF35.857DDFB0--
From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) To: nik@kemsu.ru Cc: gdb-gnats@sources.redhat.com Subject: Re: backtrace/1547: corrupt stack? Date: Mon, 9 Feb 2004 06:08:14 -0500 (EST) Yes, the PR database is difficult to work with sometimes. From your stack trace, it looks like chessd has clobbered its stack. gdb really can't recover a clobbered stack -- the information simply isn't there any more. Can you mail me (just me) these files: Your binary "chessd" file Your binary "lib/chessd.so" shared library Your "core" file Michael C
Responsible-Changed-From-To: unassigned->chastain Responsible-Changed-Why: Mine.
State-Changed-From-To: open->feedback State-Changed-Why: I need the gdb typescript that you mentioned. I tried running lasker 2.2.2 on red hat linux 8.0. It worked fine. I logged in as admin, then logged in twice more as two guests, did "match guest EYWJ 20 150 black", and moved d2d3, d7d6, e2e4, e7e5. Worked fine. I really need that typescript to see what you are talking about.
State-Changed-From-To: feedback->suspended State-Changed-Why: I can't reproduce the chessd crash, even with the user's chessd and chessd.so files. I need a core dump file to proceed. Even with a core dump file, it's unlikely that gdb has a bug here.
From: Francois Taiani <f.taiani@computer.org> To: gdb-gnats@sources.redhat.com Cc: adq_dvb@lidskialf.net Subject: Re: backtrace/1547: corrupt stack? Date: Thu, 27 Oct 2005 14:03:08 +0100 Dear GDB team, This problems looks similar to the one reported by Andrew de Quincey here [1] (copied below). Andrew provides a far smaller and easy-to-repeat example: [1] http://sourceware.org/ml/gdb/2004-11/msg00060.html Basically gdb seems to struggle to analyse stack frames from code compiled with the options "-O2 -fPIC". If you happen to debug a program that uses optimised libraries, you tipically run into this kind of problems, even if your program does not use those options. For information, the problem does not seem to be limited to PPC405 code. I've got the same issue on my G4 powerbook (with gdb 2.3, gcc 4.0.2, and a 2.6x kernel), it has been reported to happen on x86 as well. See [2]: [2] http://lists.debian.org/debian-powerpc/2005/05/msg00202.html Older versions of gdb do not seem to suffer from this. It might be related to the use of newer gcc versions as well. Regards Francois -------------------------------------------------------- From: Andrew de Quincey <adq_dvb at lidskialf dot net> To: gdb at sources dot redhat dot com Date: Mon, 8 Nov 2004 00:19:19 +0000 Subject: GDB, g++, backtrace problem Hi, I've now patched my PPC405 kernel so GDB's breakpoints work correctly. I now have another problem. GDB 6.2.1 GCC 3.3.4 linux 2.4.20 uclibc latest snapshot test program: ------- #include <stdio.h> #include <stdlib.h> #include <stdint.h> class test{ public: int testmethod(); }; int main(int argc, char* argv[]) { test* test1 = new test(); test1->testmethod(); } int test::testmethod() { printf("hi\n"); } --------- Compiled with: g++ -g -O2 -fPIC test.cpp I put a breakpoint on test::testmethod. GDB gives the following in the backtrace: #0 test::testmethod (this=0x10011050) at test.cpp:22 #1 0x10000608 in test::testmethod (this=0x10011050) at test.cpp:21 #2 0x10000608 in test::testmethod (this=0x10011050) at test.cpp:21 #3 0x10000608 in test::testmethod (this=0x10011050) at test.cpp:21 Previous frame inner to this frame (corrupt stack?) It needs -O2 (or -O3) and -fPIC to do it - if you use -O, or miss off -fPIC, the backtrace is correct. Does anyone have any suggestions what might be causing this?
Suspended for years and years.