From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6858 invoked by alias); 15 Apr 2009 19:10:06 -0000 Received: (qmail 6815 invoked by uid 22791); 15 Apr 2009 19:10:03 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_JMF_BR,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout6.012.net.il (HELO mtaout6.012.net.il) (84.95.2.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Apr 2009 19:09:58 +0000 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KI500N00P371B00@i-mtaout6.012.net.il> for gdb-patches@sourceware.org; Wed, 15 Apr 2009 22:08:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.229.34.97]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KI500LPYP5XVH00@i-mtaout6.012.net.il> for gdb-patches@sourceware.org; Wed, 15 Apr 2009 22:08:23 +0300 (IDT) Date: Wed, 15 Apr 2009 19:10:00 -0000 From: Eli Zaretskii Subject: Current GDB crashes when it sources Emacs's .gdbinit To: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ocuxlopc.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00340.txt.bz2 This happens with today's snapshot (and also with the snapshot 5 days ago): eliz@fencepost:~/emacs.cvs/emacs/src$ ~/gdb-6.8.50.20090415/gdb/gdb ./emacs GNU gdb (GDB) 6.8.50.20090415 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: ... SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] Environment variable "DISPLAY" not defined. TERM = xterm Breakpoint 1 at 0x4bc730: file emacs.c, line 431. Segmentation fault (core dumped) <<<<<<<<<<<<<<<<<<<<<< As far as I could see, it crashes when it reads this line of the .gdbinit file supplied with Emacs: if $tem[0] == 'w' && $tem[1] == 'i' && $tem[2] == 'n' && $tem[3] == 'd' Here's the backtrace from the core file: eliz@fencepost:~/emacs.cvs/emacs/src$ cd .. eliz@fencepost:~/emacs.cvs/emacs$ ~/gdb-6.8.50.20090415/gdb/gdb{,} ./src/core GNU gdb (GDB) 6.8.50.20090415 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 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 /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/libthread_db.so.1...done. Loaded symbols for /lib/libthread_db.so.1 Core was generated by `/home/e/eliz/gdb-6.8.50.20090415/gdb/gdb ./emacs'. Program terminated with signal 11, Segmentation fault. #0 0x00002ae92925956f in obstack_free () from /lib/libc.so.6 0x00002ae92925956f : mov 0x8(%rdx),%rbp (gdb) bt #0 0x00002ae92925956f in obstack_free () from /lib/libc.so.6 #1 0x000000000044ce70 in do_my_cleanups (pmy_chain=0x8ee2b8, old_chain=0xa2e3f0) at utils.c:389 #2 0x000000000048cbb9 in execute_control_command (cmd=0xa2e450) at .././gdb/cli/cli-script.c:556 #3 0x000000000048cd10 in execute_control_command (cmd=0x9d6d80) at .././gdb/cli/cli-script.c:520 #4 0x000000000048d9c6 in if_command (arg=, from_tty=) at .././gdb/cli/cli-script.c:604 #5 0x000000000044aefd in execute_command (p=0x9af06d "rt", from_tty=0) at top.c:441 #6 0x000000000044beae in command_loop () at top.c:520 #7 0x000000000044c041 in read_command_file (stream=0x975ce0) at top.c:332 #8 0x00000000004fe087 in catch_exception (uiout=0x96b0e0, func=0x48e3a0 , func_args=0x7fffff9803e0, mask=) at exceptions.c:462 #9 0x000000000048e430 in script_from_file (stream=0x975ce0, file=0x9a9230 "/srv/data/home/e/eliz/emacs.cvs/emacs/src/.gdbinit") at .././gdb/cli/cli-script.c:1525 #10 0x000000000048ebda in source_script (file=, from_tty=0) at .././gdb/cli/cli-cmds.c:475 #11 0x00000000004fe2f6 in catch_command_errors ( command=0x48eb10 , arg=0x8dc0e0 ".gdbinit", from_tty=0, mask=) at exceptions.c:525 #12 0x0000000000445756 in captured_main (data=) at .././gdb/main.c:855 #13 0x00000000004fe264 in catch_errors (func=0x444f60 , func_args=0x7fffff980660, errstring=0x66d8eb "", mask=) at exceptions.c:510 #14 0x0000000000444de4 in gdb_main (args=0x0) at .././gdb/main.c:913 #15 0x0000000000444d76 in main (argc=, argv=0x0) at gdb.c:33 I see a similar crash in the DJGPP build. But because in the DJGPP build obstacks come from libiberty, I could debug a little deeper, and found that it crashes on this line: 374 CALL_FREEFUN (h, lp); and the crash happens because h->freefun is garbled (in fact, the whole `struct obstack' pointed to by h looks garbled, at least to me): (top-gdb) p *h $1 = {chunk_size = 4079084, chunk = 0x32ad36, object_base = 0x207
, next_free = 0x128f0 ")╚\211G\004\211EΣ\213B\b\211G\fδ¡\213U\b\213E\024┴α\002\211╙\203├(\211Eα\213E\024\213s\020\211\202T@", chunk_limit = 0x1f7
, temp = 4444000, alignment_mask = 512, chunkfun = 0x246, freefun = 0x2100b7 During symbol reading, Offset 168468 out of bounds for DW_AT_ranges attribute. , extra_arg = 0x12fe0000, use_extra_arg = 0, maybe_empty_object = 0, alloc_failed = 0} In the DJGPP build, the garbled freefun address causes GDB to land in the middle of some random instruction somewhere in BFD library (aout_32_reloc_type_lookup), and GDB then dies with SIGILL. The garbage is probably different on GNU/Linux, which is why we get SIGSEGV there. I tried to debug this, but as I'm not very familiar with that part of GDB (evaluate_expression, evaluate_subexp_c, and friends), I ran out of time before I could find the villain. So I'm posting the information here, in the hope that someone else could pick up where I left off.