Re: gdb 5.1 dumped core on me [was: Emacs abort under gdb]
From: Francesco Potorti` [EMAIL PROTECTED] Date: Sat, 26 Jan 2002 17:22:23 +0100 As far as I can tell, the backtrace of gdb's core looks like the backtrace of a dumped Emacs, but it is different from the real backtrace of the Emacs that was being debugged. Sorry, I don't understand what do you mean. Can you show the GDB backtrace from this crash? Maybe that's normal, I don't have any idea of what should a crashed gdb's backtrace look like. It should show functions which appear in GDB sources, not the ones in Emacs sources ;-) ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 5.1 dumped core on me [was: Emacs abort under gdb]
Sorry, I don't understand what do you mean. You couldn't :-) It was probably the result of some errors on my part, don't know what. Can you show the GDB backtrace from this crash? GNU gdb 5.1 Copyright 2001 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-linux...(no debugging symbols found)... warning: core file may not match specified executable file. Core was generated by `gdb -x ./emacs.gdb'. Program terminated with signal 11, Segmentation fault. #0 0x080e3917 in child_xfer_memory () (gdb) bt #0 0x080e3917 in child_xfer_memory () #1 0x080b2adb in do_xfer_memory () #2 0x080b2bec in do_xfer_memory () #3 0x080b2a7e in target_read_string () #4 0x080bb0b1 in memory_error () #5 0x080797cd in value_repeat () #6 0x08077b5f in evaluate_subexp_standard () #7 0x0807497a in _initialize_values () #8 0x08075cdd in evaluate_subexp_standard () #9 0x0807497a in _initialize_values () #10 0x08074b4a in parse_to_comma_and_eval () #11 0x0808160f in output_command () #12 0x080c9336 in execute_command () #13 0x081237c3 in print_command_lines () #14 0x08123737 in print_command_lines () #15 0x080c92ce in execute_command () #16 0x08099b3a in async_disable_stdin () #17 0x0809a1b3 in async_disable_stdin () #18 0x0816ffea in rl_stuff_char () #19 0x080994ab in _initialize_thread () #20 0x08099a10 in stdin_event_handler () #21 0x080e0186 in delete_file_handler () #22 0x080dfca6 in _initialize_regcache () #23 0x080dfce5 in _initialize_regcache () #24 0x080c8f8d in catch_errors () #25 0x080dfd18 in start_event_loop () #26 0x0809958a in cli_command_loop () #27 0x08070688 in _start () #28 0x080c8f8d in catch_errors () #29 0x08071063 in _start () #30 0x080c8f8d in catch_errors () #31 0x0807108f in _start () #32 0x400a065f in ?? () (gdb) ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 5.1 dumped core on me [was: Emacs abort under gdb]
(gdb) p/x current_buffer-auto_save_file_name $59 = 0x1827b31c (gdb) xstring $60 = (struct Lisp_String *) 0x827b31c Segmentation fault (core dumped) Does GDB's core file say something interesting about where did GDB crash? Especially a backtrace. As far as I can tell, the backtrace of gdb's core looks like the backtrace of a dumped Emacs, but it is different from the real backtrace of the Emacs that was being debugged. Maybe that's normal, I don't have any idea of what should a crashed gdb's backtrace look like. The other useful thing would be a confirmation that the Debian GDB 5.1 really is a stock GDB 5.1 and doesn't have patches applied. Is there anything unusual in the startup message for instance? Nothing. But I can read this in Debian's copyright file: Patch for Objective-C from: ftp://ftp.es.ele.tue.nl/pub/objc/gdb-gnu-objc.diff.gz.uue Since this is sent to Debian's maintainer too, he can confirm whether this is the only patch applied or not. GDB should never dump core. Yes, the same that any other program. This is obviously a bug ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 5.1 dumped core on me [was: Emacs abort under gdb]
Eli Zaretskii wrote: From: Francesco Potorti` [EMAIL PROTECTED] Date: Tue, 22 Jan 2002 12:27:11 +0100 (gdb) p/x current_buffer-auto_save_file_name $59 = 0x1827b31c (gdb) xstring $60 = (struct Lisp_String *) 0x827b31c Segmentation fault (core dumped) Does GDB's core file say something interesting about where did GDB crash? Anyway, since no one responded, let me rephrase the (implicit) question in Francesco's report: Is GDB supposed to handle invalid memory accesses gracefully? That is, if the user asks GDB to access the inferior's memory via an invalid pointer, does GDB protect itself against SIGSEGV and other related calamities? An illegal memory access in the child will not cause a signal in the parent. If GDB gets a segv, it is because of some bad pointer or data structure within GDB, not because of accessing a bad address in the child. ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 5.1 dumped core on me [was: Emacs abort under gdb]
From: Francesco Potorti` [EMAIL PROTECTED] Date: Tue, 22 Jan 2002 12:27:11 +0100 (gdb) p/x current_buffer-auto_save_file_name $59 = 0x1827b31c (gdb) xstring $60 = (struct Lisp_String *) 0x827b31c Segmentation fault (core dumped) Does GDB's core file say something interesting about where did GDB crash? Anyway, since no one responded, let me rephrase the (implicit) question in Francesco's report: Is GDB supposed to handle invalid memory accesses gracefully? That is, if the user asks GDB to access the inferior's memory via an invalid pointer, does GDB protect itself against SIGSEGV and other related calamities? ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 5.1 dumped core on me [was: Emacs abort under gdb]
From: Francesco Potorti` [EMAIL PROTECTED] Date: Tue, 22 Jan 2002 12:27:11 +0100 (gdb) p/x current_buffer-auto_save_file_name $59 = 0x1827b31c (gdb) xstring $60 = (struct Lisp_String *) 0x827b31c Segmentation fault (core dumped) Does GDB's core file say something interesting about where did GDB crash? Especially a backtrace. The other useful thing would be a confirmation that the Debian GDB 5.1 really is a stock GDB 5.1 and doesn't have patches applied. Is there anything unusual in the startup message for instance? Anyway, since no one responded, let me rephrase the (implicit) question in Francesco's report: Is GDB supposed to handle invalid memory accesses gracefully? That is, if the user asks GDB to access the inferior's memory via an invalid pointer, does GDB protect itself against SIGSEGV and other related calamities? GDB should never dump core. Which means it does need to try to protect its self from such calamities. Andrew ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
gdb 5.1 dumped core on me [was: Emacs abort under gdb]
GNU gdb 5.1 configured as i386-linux. This is the stock GDB in the woody Debian distribution. I have files in ftp://fly.cnuce.cnr.it/pub/tmp/gdb-bug/. They are the core left by gdb, which is enormous but compressed very well, and the whole Emacs src dir that I was debugging at the moment. All in all, about 30 MB to download, 200 on the disk. I had run emacs under gdb using this script file: ===File ~/News/emacs.gdb #! /usr/bin/gdb -x file /opt/e21/src/emacs source /opt/e21/src/.gdbinit r --funcall load-my-desktop when Emacs crashed. I have some logs of the session, that I report below. The last log is when gdb crashed: Last log (gdb crash) (gdb) p/x current_buffer-auto_save_file_name $59 = 0x1827b31c (gdb) xstring $60 = (struct Lisp_String *) 0x827b31c Segmentation fault (core dumped) -- end of last log --- In the middle, I had the problem that the x* commands defined in the .gdbinit file in the emacs src dir did not work: Intermediate log (x* commands not working --- (gdb) p/x current_buffer-size $46 = 0x2002006d (gdb) xtype Lisp_Misc Argument to arithmetic operation not a number or boolean. (gdb) p/x current_buffer-size $48 = 0x2002006d (gdb) xmisctype Argument to arithmetic operation not a number or boolean. --- end of intermidiate log -- This problem disappeared after I issued the xreload command, which too is defined in the emacs .gdbinit. --- First log (beginning of session) --- Fatal error (6). Program received signal SIGABRT, Aborted. 0x4031a911 in kill () from /lib/libc.so.6 (gdb) bt #0 0x4031a911 in kill () from /lib/libc.so.6 #1 0x080ceb86 in fatal_error_signal (sig=6) at emacs.c:370 #2 0x4031a848 in sigaction () from /lib/libc.so.6 #3 0x080eef51 in buf_charpos_to_bytepos (b=0x8b867c8, charpos=16230496) at marker.c:141 #4 0x08103434 in scan_newline (start=16230496, start_byte=16230496, limit=1, limit_byte=1, count=-1, allow_quit=1) at search.c:761 #5 0x081000e0 in current_column_1 () at indent.c:516 #6 0x080ffd08 in current_column () at indent.c:377 #7 0x08065d50 in redisplay_internal (preserve_echo_area=1) at xdisp.c:8492 #8 0x08066b2a in redisplay_preserve_echo_area (from_where=2) at xdisp.c:9057 #9 0x08056852 in sit_for (sec=0, usec=125000, reading=0, display=1, initial_display=1) at dispnew.c:6185 #10 0x0805696d in Fsit_for (seconds=1747435148, milliseconds=405254940, nodisp=405254940) at dispnew.c:6234 #11 0x08126377 in Ffuncall (nargs=2, args=0xbfffe434) at eval.c:2720 #12 0x0814d20c in Fbyte_code (bytestr=944247468, vector=1212685872, maxdepth=7) at bytecode.c:709 #13 0x0812693b in funcall_lambda (fun=1212686208, nargs=0, arg_vector=0xbfffe5fc) at eval.c:2905 #14 0x081264a1 in Ffuncall (nargs=1, args=0xbfffe5f8) at eval.c:2770 #15 0x08125d4e in Fapply (nargs=2, args=0xbfffe5f8) at eval.c:2220 #16 0x081262c2 in Ffuncall (nargs=3, args=0xbfffe5f4) at eval.c:2694 #17 0x0814d20c in Fbyte_code (bytestr=941712480, vector=1210147972, maxdepth=4) at bytecode.c:709 #18 0x0812594a in Feval (form=1478583376) at eval.c:2069 #19 0x0812474b in Fcondition_case (args=1479058100) at eval.c:1258 #20 0x0814d6bc in Fbyte_code (bytestr=941712240, vector=1210147820, maxdepth=5) at bytecode.c:891 #21 0x0812693b in funcall_lambda (fun=1210147660, nargs=1, arg_vector=0xbfffe978) at eval.c:2905 #22 0x081264a1 in Ffuncall (nargs=2, args=0xbfffe974) at eval.c:2770 #23 0x081260af in call1 (fn=405309492, arg1=1210640616) at eval.c:2509 #24 0x080d512b in timer_check (do_it_now=1) at keyboard.c:4090 #25 0x080d415a in readable_events (do_timers_now=1) at keyboard.c:3168 #26 0x080d6dc7 in get_input_pending (addr=0x82737c4, do_timers_now=1) at keyboard.c:6058 #27 0x080db001 in detect_input_pending_run_timers (do_display=1) at keyboard.c:9477 #28 0x08151417 in wait_reading_process_input (time_limit=30, microsecs=0, read_kbd=268435455, do_display=1) at process.c:2686 #29 0x08056884 in sit_for (sec=30, usec=0, reading=1, display=1, initial_display=0) at dispnew.c:6195 #30 0x080d3116 in read_char (commandflag=1, nmaps=3, maps=0xbfffee04, prev_event=405254940, used_mouse_menu=0xbfffee58) at keyboard.c:2494 #31 0x080d91ad in read_key_sequence (keybuf=0xbfffef64, bufsize=30, prompt=405254940, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8217 #32 0x080d1784 in command_loop_1 () at keyboard.c:1437 #33 0x08124835 in internal_condition_case (bfun=0x80d1490 command_loop_1, handlers=405351332, hfun=0x80d10c8 cmd_error) at eval.c:1314 #34 0x080d1368 in command_loop_2 () at keyboard.c:1243 #35 0x081243c1 in internal_catch (tag=405312684, func=0x80d1344 command_loop_2, arg=405254940) at eval.c:1074 #36 0x080d1312 in command_loop () at keyboard.c:1222 #37 0x080d0e6d in recursive_edit_1 () at keyboard.c:948 #38
