This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Current GDB crashes when it sources Emacs's .gdbinit


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 <http://gnu.org/licenses/gpl.html>
  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:
  <http://www.gnu.org/software/gdb/bugs/>...
  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 <http://gnu.org/licenses/gpl.html>
  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:
  <http://www.gnu.org/software/gdb/bugs/>...
  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 <obstack_free+47>:   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=<value optimized out>,
      from_tty=<value optimized out>) 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 <wrapped_read_command_file>, func_args=0x7fffff9803e0,
      mask=<value optimized out>) 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=<value optimized out>,
      from_tty=0) at .././gdb/cli/cli-cmds.c:475
  #11 0x00000000004fe2f6 in catch_command_errors (
      command=0x48eb10 <source_script>, arg=0x8dc0e0 ".gdbinit", from_tty=0,
      mask=<value optimized out>) at exceptions.c:525
  #12 0x0000000000445756 in captured_main (data=<value optimized out>)
      at .././gdb/main.c:855
  #13 0x00000000004fe264 in catch_errors (func=0x444f60 <captured_main>,
      func_args=0x7fffff980660, errstring=0x66d8eb "",
      mask=<value optimized out>) at exceptions.c:510
  #14 0x0000000000444de4 in gdb_main (args=0x0) at .././gdb/main.c:913
  #15 0x0000000000444d76 in main (argc=<value optimized out>, 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 <Address 0x207 out of bounds>,
    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 <Address 0x1f7 out of bounds>, temp = 4444000,
    alignment_mask = 512, chunkfun = 0x246, freefun = 0x2100b7
  During symbol reading, Offset 168468 out of bounds for DW_AT_ranges attribute.
   <aout_32_reloc_type_lookup+887>, 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]