Emacs hangs on Mac OS X

Emacs hangs on Mac OS X

[Piet van Oostrum]

With Emacs.app compiled from the pretest tarball (downloaded Dec 19) I get
a hang fairly often. I can't remember that I had these with the previous
version (from a CVS checkout), or at least much less often. Now I get them
about once a day. I have grabbed a stack trace with gdb:

#0  0xffff85d8 in ___spin_lock_relinquish () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186
#1  0x900031b4 in szone_malloc ()
#2  0x900030e4 in malloc_zone_malloc ()
#3  0x907bb488 in CFAllocatorAllocate ()
#4  0x907dc41c in CFRunLoopRunSpecific ()
#5  0x93208740 in RunCurrentEventLoopInMode ()
#6  0x93207d4c in ReceiveNextEventCommon ()
#7  0x9330c940 in ReceiveNextEventInMode ()
#8  0x00158034 in XTread_socket (sd=0, expected=1, hold_quit=0xbfffca6c) at macterm.c:10410
#9  0x0008ad24 in read_avail_input (expected=0) at keyboard.c:6823
#10 0x001387a4 in alarm_signal_handler (signo=0) at atimer.c:397
#11 <signal handler called>
#12 0x9000437c in szone_malloc ()
#13 0x00000000 in ?? ()

I don't have the source of /System/Library/Frameworks/System.framework/
PrivateHeaders/ppc/cpu_capabilities.h, apparently this is compiled into the
system by Apple's developers.

It looks like a malloc call is interrupted by a timer alarm, and then the
system also needs a malloc. Malloc probably not being reentrant this should
be a cause of problems. Maybe the spin_lock stuff is a way to serialize the
malloc calls but this won't work for a signal handler, only for threads.

The timer is probably for poll_for_input.

I think something should be done to prevent mallocs (and probably also
frees) to be interrupted by the alarm signal. Or maybe doing the event loop
in a signal handler is not such a good idea.

Another possibility would be to run the event loop in a different thread
and let it put all events in a synchronized queue, where it can be popped
by read_avail_input.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org

Re: Emacs hangs on Mac OS X

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 03 Jan 2007 11:47:29 +0100, Piet van Oostrum <piet@cs.uu.nl> said:

> With Emacs.app compiled from the pretest tarball (downloaded Dec 19) I get
> a hang fairly often. I can't remember that I had these with the previous
> version (from a CVS checkout), or at least much less often. Now I get them
> about once a day. I have grabbed a stack trace with gdb:

(snip)
> #10 0x001387a4 in alarm_signal_handler (signo=0) at atimer.c:397
> #11 <signal handler called>
> #12 0x9000437c in szone_malloc ()
> #13 0x00000000 in ?? ()

Unfortunately, the information about the interrupted library function
call seems to be already broken somehow.  Could you try to get
backtraces for a few instances of the hang?  Hopefully we will get
more detailed information.

> I think something should be done to prevent mallocs (and probably also
> frees) to be interrupted by the alarm signal.

That's what BLOCK_INPUT is for (see src/blockinput.h).

> Or maybe doing the event loop in a signal handler is not such a good
> idea.

SYNC_INPUT will obviate such calls, but it will not be set by default
until the next release.

> Another possibility would be to run the event loop in a different thread
> and let it put all events in a synchronized queue, where it can be popped
> by read_avail_input.

For this approach, maybe you want to look at Steven Tamm's "Jaguar
Carbon Event Patch":
http://homepage.mac.com/steventamm/software/jagemacs.html

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs hangs on Mac OS X

[Piet van Oostrum]

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> (YM) wrote:

>YM> Unfortunately, the information about the interrupted library function
>YM> call seems to be already broken somehow.  Could you try to get
>YM> backtraces for a few instances of the hang?  Hopefully we will get
>YM> more detailed information.

Here is a complete one. The `lowest' malloc appears to be called from
localtime(). Mallocs from system library functions of course are much more
difficult to prevent, if at all.
IMHO this shows that is it quite bad to run the event loop in a signal handler.

There is an additional signal handler on top, but I think it is because I
tried to kill emacs.

#0  0xffff85d8 in ___spin_lock_relinquish () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:186
#1  0x900040a4 in szone_malloc ()
#2  0x90002e00 in malloc ()
#3  0x90015188 in __smakebuf ()
#4  0x90015058 in __swsetup ()
#5  0x9000fcac in __sfvwrite ()
#6  0x90027fc4 in fwrite ()
#7  0x000bc200 in Fdo_auto_save (no_message=58721337, current_only=58721289) at fileio.c:5939
#8  0x00081194 in shut_down_emacs (sig=15, no_x=1, stuff=58721289) at emacs.c:2109
#9  0x000813c4 in fatal_error_signal (sig=15) at emacs.c:380
#10 <signal handler called>
#11 0xffff8260 in ___spin_lock () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:178
#12 0x90003200 in szone_malloc ()
#13 0x900030e4 in malloc_zone_malloc ()
#14 0x907bb488 in CFAllocatorAllocate ()
#15 0x907dc41c in CFRunLoopRunSpecific ()
#16 0x93208740 in RunCurrentEventLoopInMode ()
#17 0x93207d4c in ReceiveNextEventCommon ()
#18 0x9330c940 in ReceiveNextEventInMode ()
#19 0x00158034 in XTread_socket (sd=41943096, expected=1, hold_quit=0xbfffac5c) at macterm.c:10410
#20 0x0008ad24 in read_avail_input (expected=0) at keyboard.c:6823
#21 0x001387a4 in alarm_signal_handler (signo=41943096) at atimer.c:397
#22 <signal handler called>
#23 0x90008954 in szone_calloc ()
#24 0x900087e4 in calloc ()
#25 0x9000b858 in token_table_add ()
#26 0x9001b0fc in notify_register_check ()
#27 0x90021598 in notify_register_tz ()
#28 0x900209d0 in tzset_basic ()
#29 0x9001fe9c in localtime ()
#30 0x000ec7f8 in Fcurrent_time_zone (specified_time=41943096) at editfns.c:1932
#31 0x000f684c in Ffuncall (nargs=41943096, args=0xbfffc7d4) at eval.c:2997
#32 0x0012813c in Fbyte_code (bytestr=4, vector=-1073756208, maxdepth=32) at bytecode.c:679
#33 0x000f62ec in funcall_lambda (fun=9107780, nargs=2, arg_vector=0xbfffc9b4) at eval.c:3184
#34 0x000f69fc in Ffuncall (nargs=41943096, args=0x2a9a441) at eval.c:3054
#35 0x0012813c in Fbyte_code (bytestr=4, vector=-1073755728, maxdepth=72) at bytecode.c:679
#36 0x000f62ec in funcall_lambda (fun=9108084, nargs=3, arg_vector=0xbfffcbb4) at eval.c:3184
#37 0x000f69fc in Ffuncall (nargs=41943096, args=0x2954ee9) at eval.c:3054
#38 0x0012813c in Fbyte_code (bytestr=4, vector=-1073755216, maxdepth=72) at bytecode.c:679
#39 0x000f62ec in funcall_lambda (fun=9101588, nargs=1, arg_vector=0xbfffcdc0) at eval.c:3184
#40 0x000f69fc in Ffuncall (nargs=41943096, args=0x2a9a279) at eval.c:3054
#41 0x0012813c in Fbyte_code (bytestr=4, vector=-1073754692, maxdepth=40) at bytecode.c:679
#42 0x000f5aec in Feval (form=2802064) at eval.c:2334
#43 0x000f8a14 in internal_lisp_condition_case (var=58721289, bodyform=24728245, handlers=24727181) at eval.c:1426
#44 0x00128b30 in Fbyte_code (bytestr=4, vector=-1073753408, maxdepth=24) at bytecode.c:869
#45 0x000f62ec in funcall_lambda (fun=51800004, nargs=1, arg_vector=0xbfffd4a4) at eval.c:3184
#46 0x000f69fc in Ffuncall (nargs=41943096, args=0x3853b29) at eval.c:3054
#47 0x0012813c in Fbyte_code (bytestr=4, vector=-1073752928, maxdepth=24) at bytecode.c:679
#48 0x000f62ec in funcall_lambda (fun=51924788, nargs=1, arg_vector=0xbfffd68c) at eval.c:3184
#49 0x000f69fc in Ffuncall (nargs=41943096, args=0x3853ba1) at eval.c:3054
#50 0x0012813c in Fbyte_code (bytestr=4, vector=-1073752440, maxdepth=32) at bytecode.c:679
#51 0x000f5aec in Feval (form=2802064) at eval.c:2334
#52 0x000f8a14 in internal_lisp_condition_case (var=58721289, bodyform=41877517, handlers=41879469) at eval.c:1426
#53 0x00128b30 in Fbyte_code (bytestr=4, vector=-1073751168, maxdepth=32) at bytecode.c:869
#54 0x000f62ec in funcall_lambda (fun=52188180, nargs=4, arg_vector=0xbfffdd64) at eval.c:3184
#55 0x000f69fc in Ffuncall (nargs=41943096, args=0x2cf9181) at eval.c:3054
#56 0x0012813c in Fbyte_code (bytestr=4, vector=-1073750688, maxdepth=48) at bytecode.c:679
#57 0x000f62ec in funcall_lambda (fun=55535444, nargs=4, arg_vector=0xbfffdf54) at eval.c:3184
#58 0x000f69fc in Ffuncall (nargs=41943096, args=0x7338521) at eval.c:3054
#59 0x0012813c in Fbyte_code (bytestr=4, vector=-1073750192, maxdepth=48) at bytecode.c:679
#60 0x000f62ec in funcall_lambda (fun=54957460, nargs=2, arg_vector=0xbfffe144) at eval.c:3184
#61 0x000f69fc in Ffuncall (nargs=41943096, args=0x2c2f0a1) at eval.c:3054
#62 0x0012813c in Fbyte_code (bytestr=4, vector=-1073749696, maxdepth=72) at bytecode.c:679
#63 0x000f62ec in funcall_lambda (fun=55347604, nargs=0, arg_vector=0xbfffe3ac) at eval.c:3184
#64 0x000f69fc in Ffuncall (nargs=41943096, args=0x2c9af91) at eval.c:3054
#65 0x000f8180 in run_hook_with_args (nargs=1, args=0xbfffe3a8, cond=to_completion) at eval.c:2656
#66 0x000f82bc in Frun_hooks (nargs=1, args=0x0) at eval.c:2519
#67 0x000f6738 in Ffuncall (nargs=41943096, args=0x3810be1) at eval.c:2978
#68 0x000f83a0 in Fapply (nargs=2, args=0xbfffe5a4) at eval.c:2430
#69 0x000f6738 in Ffuncall (nargs=41943096, args=0x3811661) at eval.c:2978
#70 0x0012813c in Fbyte_code (bytestr=4, vector=-1073748576, maxdepth=24) at bytecode.c:679
#71 0x000f62ec in funcall_lambda (fun=51734836, nargs=1, arg_vector=0xbfffe784) at eval.c:3184
#72 0x000f69fc in Ffuncall (nargs=41943096, args=0x2c717c9) at eval.c:3054
#73 0x0012813c in Fbyte_code (bytestr=4, vector=-1073748096, maxdepth=40) at bytecode.c:679
#74 0x000f62ec in funcall_lambda (fun=55317636, nargs=0, arg_vector=0xbfffe974) at eval.c:3184
#75 0x000f69fc in Ffuncall (nargs=41943096, args=0x2beab21) at eval.c:3054
#76 0x0012813c in Fbyte_code (bytestr=4, vector=-1073747600, maxdepth=40) at bytecode.c:679
#77 0x000f62ec in funcall_lambda (fun=55361380, nargs=1, arg_vector=0xbfffeba4) at eval.c:3184
#78 0x000f69fc in Ffuncall (nargs=41943096, args=0x2ef6719) at eval.c:3054
#79 0x000f344c in Fcall_interactively (function=49243929, record_flag=58721289, keys=56882580) at callint.c:860
#80 0x000892ec in Fcommand_execute (cmd=49243929, record_flag=58721289, keys=58721289, special=-1) at keyboard.c:10013
#81 0x000927c4 in command_loop_1 () at keyboard.c:1873
#82 0x000f43e8 in internal_condition_case (bfun=0x916c0 <command_loop_1>, handlers=58767529, hfun=0x89fe0 <cmd_error>) at eval.c:1481
#83 0x00083110 in command_loop_2 () at keyboard.c:1329
#84 0x000f4270 in internal_catch (tag=41943096, func=0x830d0 <command_loop_2>, arg=58721289) at eval.c:1222
#85 0x00082e20 in command_loop () at keyboard.c:1308
#86 0x00082f44 in recursive_edit_1 () at keyboard.c:1006
#87 0x00083090 in Frecursive_edit () at keyboard.c:1067
#88 0x00082a1c in main (argc=400, argv=0xbffff8dc) at emacs.c:1761

-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org

Re: Emacs hangs on Mac OS X

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 03 Jan 2007 22:39:00 +0100, Piet van Oostrum <piet@cs.uu.nl> said:

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> (YM) wrote:
YM> Unfortunately, the information about the interrupted library function
YM> call seems to be already broken somehow.  Could you try to get
YM> backtraces for a few instances of the hang?  Hopefully we will get
YM> more detailed information.

> Here is a complete one. The `lowest' malloc appears to be called
> from localtime(). Mallocs from system library functions of course
> are much more difficult to prevent, if at all.

Thanks.  Actually it is in the list (*1) of such library functions
detected (*2) so far on Darwin:

   localtime, gmtime, getc, getaddrinfo, fwrite, mkstemp, mktime,
   fclose, freeaddrinfo

(*1) http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-07/msg00070.html
(*2) http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00074.html

I'll put BLOCK_INPUT at least around localtime/gmtime/mktime calls.

Among them, we cannot simply put BLOCK_INPUT around getaddrinfo
because it is called with immediate_quit == 1.

> IMHO this shows that is it quite bad to run the event loop in a
> signal handler.

IIUC, many of us agree that SYNC_INPUT is the right direction, but
after the next release.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp