From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Piet van Oostrum Newsgroups: gmane.emacs.devel Subject: Emacs hangs on Mac OS X Date: Wed, 03 Jan 2007 11:47:29 +0100 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1167821279 32754 80.91.229.12 (3 Jan 2007 10:47:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 3 Jan 2007 10:47:59 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 03 11:47:58 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1H23f3-0003zE-94 for ged-emacs-devel@m.gmane.org; Wed, 03 Jan 2007 11:47:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H23f2-0004ai-Op for ged-emacs-devel@m.gmane.org; Wed, 03 Jan 2007 05:47:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H23ej-0004Ys-Pf for emacs-devel@gnu.org; Wed, 03 Jan 2007 05:47:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H23ei-0004Xx-1i for emacs-devel@gnu.org; Wed, 03 Jan 2007 05:47:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H23eh-0004Xk-Pp for emacs-devel@gnu.org; Wed, 03 Jan 2007 05:47:35 -0500 Original-Received: from [131.211.80.10] (helo=mail.cs.uu.nl) by monty-python.gnu.org with esmtp (Exim 4.52) id 1H23eh-0006Ii-A7 for emacs-devel@gnu.org; Wed, 03 Jan 2007 05:47:35 -0500 Original-Received: from mail.cs.uu.nl (localhost.localdomain [127.0.0.1]) by mail.cs.uu.nl (Postfix) with ESMTP id 81E68A35F4 for ; Wed, 3 Jan 2007 11:47:30 +0100 (CET) Original-Received: from ordesa.cs.uu.nl (ordesa.cs.uu.nl [131.211.81.146]) by mail.cs.uu.nl (Postfix) with ESMTP id 75F87A35F0 for ; Wed, 3 Jan 2007 11:47:30 +0100 (CET) Original-Received: by ordesa.cs.uu.nl (Postfix, from userid -2) id BECC961C8B5; Wed, 3 Jan 2007 11:47:32 +0100 (CET) Original-Received: from ordesa.cs.uu.nl (localhost [127.0.0.1]) by ordesa.cs.uu.nl (Postfix) with ESMTP id 28BFE61C89C for ; Wed, 3 Jan 2007 11:47:32 +0100 (CET) X-Mailer: emacs 22.0.92.2 (via feedmail 8 I) Original-To: emacs-devel@gnu.org User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.92 (darwin) X-AV-Checked: ClamAV using ClamSMTP at cs.uu.nl X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:64676 Archived-At: 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 #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 URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: piet@vanoostrum.org