GNU bug report logs - #9723
24.0.50; Emacs Clipboard crash

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Jones <josejones <at> expedia.com>
Cc: 9723 <at> debbugs.gnu.org
Subject: bug#9723: 24.0.50; Emacs Clipboard crash
Date: Fri, 21 Oct 2011 10:49:15 +0200

> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Thu, 20 Oct 2011 15:29:33 -0700
> 
> Just got a new crash while in GDB. Here is the GDB session information you requested last time.

Thanks.

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 13664.0x2a74]
> 0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712, args_template=16837538, nargs=23009797,
>     args=0x186a00) at bytecode.c:1012
> 1012    bytecode.c: No such file or directory.
>         in bytecode.c
> (gdb) i threads
>   63 Thread 13664.0x38b4  0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
>   4 Thread 13664.0x3060  0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
>   3 Thread 13664.0x1c64  0x7d61c846 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
>   2 Thread 13664.0x33e4  0x7d947860 in USER32!SetActiveWindow () from C:\WINDOWS\syswow64\user32.dll
> * 1 Thread 13664.0x2a74  0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712,
>     args_template=16837538, nargs=23009797, args=0x186a00) at bytecode.c:1012
> (gdb) bt 63
> #0  0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712, args_template=16837538,
>     nargs=23009797, args=0x186a00) at bytecode.c:1012
> #1  0x010dfd99 in exec_byte_code (bytestr=23009797, vector=1600000, maxdepth=8578600, args_template=17642311, nargs=20835142,
>     args=0x13e281a) at bytecode.c:1182
> #2  0x0100eba2 in make_lispy_position (f=0x10dfd6c, x=23009797, y=20835142, t=17593177) at keyboard.c:5148
> #3  0x010e0d54 in exec_byte_code (bytestr=0, vector=0, maxdepth=20850714, args_template=20850714, nargs=0, args=0x0)
>     at bytecode.c:1730
> #4  0x01025592 in Fsequencep (object=-875902696) at data.c:352
> #5  0x010279f6 in let_shadows_buffer_binding_p (symbol=0x13e281a) at data.c:1082
> #6  0x01029a11 in Fkill_local_variable (variable=8583808) at data.c:1672
> #7  0x0100ee4f in make_lispy_position (f=0x1029871, x=20908442, y=16922106, t=2102413915) at keyboard.c:5168
> #8  0x0101cf4b in read_key_sequence (keybuf=0x13e281a, bufsize=7602259, prompt=7209057, dont_downcase_last=6357092,
>     can_return_switch_frame=20906466, fix_current_buffer=20850714) at keyboard.c:9472
> #9  0x0100ed84 in make_lispy_position (f=0x13f01e2, x=16895784, y=20850714, t=2009014352) at keyboard.c:5163
> #10 0x0101cdfe in read_key_sequence (keybuf=0x101cac1, bufsize=20850714, prompt=2009021072, dont_downcase_last=8585048,
>     can_return_switch_frame=0, fix_current_buffer=-1) at keyboard.c:9452
> #11 0x0101cf12 in read_key_sequence (keybuf=0x135bdd6, bufsize=0, prompt=1, dont_downcase_last=0,
>     can_return_switch_frame=8585028, fix_current_buffer=8584944) at keyboard.c:9472
> #12 0x01002eb0 in shut_down_emacs (sig=1, no_x=11551144, stuff=11546872) at emacs.c:2039
> #13 0x010010b6 in __mingw_CRTStartup ()
> #14 0x01001148 in WinMainCRTStartup ()
> #15 0x00000001 in ?? ()
> #16 0x00000001 in ?? ()
> #17 0x00000000 in ?? ()

I don't understand this backtrace.  It says that Emacs was being shut
down because of a fatal signal.  sig=1 on Windows means SIGHUP, and
the only relevant place seems to be this line in keyboard.c:

                kill (getpid (), SIGHUP);

But even if this is so, how come GDB shows that shut_down_emacs was
called from the library startup code, and why does it say that
shut_down_emacs calls read_key_sequence?  There are no such calls in
the code, and this being an unoptimized build, I don't expect any
intermediate functions to be inlined and disappear from the backtrace.

If you set a breakpoint in shut_down_emacs, do you get a more
reasonable backtrace?

In any case, it looks like the crash is secondary; the primary reason
is that Emacs hits some fatal error and commits suicide.  Why that
happens is still a mystery for me, as is why it happens only to you.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.