--- Begin Message ---
|
Subject: |
24.0.50; GDB crash when hit C-g |
|
Date: |
Tue, 14 Jun 2011 10:15:13 -0700 |
Not from emacs -Q, but from my setup.
$ ./gdb -p 5708
GNU gdb (GDB) 7.2
Copyright (C) 2010 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 5708
[New Thread 5708.0x1798]
[New Thread 5708.0x15e8]
[New Thread 5708.0x1440]
Reading symbols from C:\Emacs-24-2011-06-13-lex\bin\emacs.exe...done.
[Switching to Thread 5708.0x1440]
Warning: c:\drews-lisp-20\bin/../lwlib: No such file or directory.
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 = cygwin
.gdbinit:1328: Error in sourced command file:
No symbol "Vsystem_type" in current context.
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 5708.0x1798]
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
#1 0x0114d811 in w32_abort () at w32fns.c:7199
#2 0x010419c3 in die (
msg=0x157dcc8 "assertion failed: EQ (XFRAME
(selected_frame)->selected_window, selecte
d_window)", file=0x1575980 "xdisp.c", line=12060) at alloc.c:6142
#3 0x011f8d04 in redisplay_internal () at xdisp.c:12060
#4 0x011f5a7b in redisplay () at xdisp.c:11234
#5 0x01008882 in read_char (commandflag=1, nmaps=4, maps=0x83f9b0,
prev_event=53831706, used_mouse_menu=0x83fa78, end_time=0x0) at
keyboard.c:2433
#6 0x0101be6e in read_key_sequence (keybuf=0x83fbf4, bufsize=30,
prompt=53831706,
dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1)
at keyboard.c:9272
#7 0x01005bf6 in command_loop_1 () at keyboard.c:1445
#8 0x0103282e in internal_condition_case (bfun=0x10055fb <command_loop_1>,
handlers=53885434, hfun=0x1004e1f <cmd_error>) at eval.c:1507
#9 0x01005257 in command_loop_2 (ignore=53831706) at keyboard.c:1156
#10 0x01032251 in internal_catch (tag=53883458, func=0x1005233 <command_loop_2>,
arg=53831706) at eval.c:1261
#11 0x01005213 in command_loop () at keyboard.c:1135
#12 0x010047f4 in recursive_edit_1 () at keyboard.c:756
#13 0x01004b0f in Frecursive_edit () at keyboard.c:820
#14 0x01002906 in main (argc=3, argv=0x33c58) at emacs.c:1698
(gdb) frame 2
#2 0x010419c3 in die (
msg=0x157dcc8 "assertion failed: EQ (XFRAME
(selected_frame)->selected_window, selecte
d_window)", file=0x1575980 "xdisp.c", line=12060) at alloc.c:6142
6142 alloc.c: No such file or directory.
in alloc.c
(gdb) p selected_window
$1 = 190280709
(gdb) xtype
Lisp_Vectorlike
There is no member named size.
(gdb) p selected_frame
$2 = 119366661
(gdb) xtype
Lisp_Vectorlike
There is no member named size.
(gdb)
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2011-06-13 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#8864: 24.0.50; GDB crash when hit C-g |
|
Date: |
Tue, 14 Jun 2011 23:41:28 +0300 |
> From: "Drew Adams" <address@hidden>
> Cc: <address@hidden>
> Date: Tue, 14 Jun 2011 12:06:52 -0700
>
> > Please leave this GDB session running, I will get to looking at this
> > soon.
>
> Too late. This is my work laptop. I need to use it. If left running, the
> screen is covered with multiple (blank, at this point) frames, etc. And I
> turn
> off the laptop periodically, when changing location etc. Leaving such a
> session
> is a non-starter.
Then please don't bother reporting such bugs anymore.
> If you want to let me know other gdb commands to use in the future to possibly
> provide more info at the outset, feel free to do so. I did my best, using the
> previous info you provided.
That's impossible. Each crash has a different place and the variables
that need to be explored are different. There's no way anyone could
give you such instructions up front, without knowing where the crash
will happen and due to what assertion.
--- End Message ---