From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: problems building trunk in OpenBSD/i386 Date: Thu, 12 Jul 2007 13:22:59 -0400 Message-ID: References: <874pkaezdu.fsf@tarn.lan> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1184261039 24838 80.91.229.12 (12 Jul 2007 17:23:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 12 Jul 2007 17:23:59 +0000 (UTC) Cc: Ryan Yeske , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 12 19:23:55 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 1I92ON-0006dD-59 for ged-emacs-devel@m.gmane.org; Thu, 12 Jul 2007 19:23:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I92OM-0001pb-GF for ged-emacs-devel@m.gmane.org; Thu, 12 Jul 2007 13:23:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I92OJ-0001pW-CD for emacs-devel@gnu.org; Thu, 12 Jul 2007 13:23:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I92OG-0001pJ-S9 for emacs-devel@gnu.org; Thu, 12 Jul 2007 13:23:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I92OG-0001pG-MB for emacs-devel@gnu.org; Thu, 12 Jul 2007 13:23:44 -0400 Original-Received: from alnrmhc13.comcast.net ([204.127.225.93]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I92OF-0006UR-H1; Thu, 12 Jul 2007 13:23:43 -0400 Original-Received: from raeburn.org (c-65-96-188-63.hsd1.ma.comcast.net[65.96.188.63]) by comcast.net (alnrmhc13) with ESMTP id <20070712172301b1300jf42ge>; Thu, 12 Jul 2007 17:23:01 +0000 Original-Received: from [69.25.196.100] (fwoosh.raeburn.org [69.25.196.100]) by raeburn.org (8.12.11/8.12.11) with ESMTP id l6CHN0qS027390; Thu, 12 Jul 2007 13:23:00 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.752.2) X-detected-kernel: NetCache Data OnTap 5.x 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:74692 Archived-At: On Jul 12, 2007, at 07:07, Eli Zaretskii wrote: >> Date: Thu, 12 Jul 2007 02:37:33 -0700 >> From: Ryan Yeske >> >> ./temacs --batch --load loadup bootstrap >> pid 17656: Fatal error 'Cannot create kernel pipe' at line 200 in >> file /usr/src/lib/libpthread/uthread/uthread_init.c (errno = 24) >> *** Signal 6 >> >> EMACS_22_BASE is the last version that I know builds fine on this >> platform. >> >> Advice on how to proceed in debugging this appreciated. > > The backtrace indicates there's infinite recursion in gmalloc.c: > >> #365 0x08184f6d in __malloc_initialize () at gmalloc.c:615 >> #366 0x081856c1 in malloc (size=3072) at gmalloc.c:982 > > These two lines repeat themselves again and again, with calls to other > functions interspersed in between. > > I'm guessing that the infinite recursion causes Emacs to eventually > run out of runtime stack, and then it dies with the above weird > message, which really tells you that the program is in deep trouble. > > If you can step through the code in question with GDB and try to > understand why it recurses, it will help. The other parts of the stack trace indicate that the rest of the loop is in the C library -- pthread_once calls pthread_mutex_lock, which initializes some thread support code, which is causing some priority queue code to try to allocate storage, which winds up calling into gmalloc, which again ensures that initialization has been done by calling pthread_once. The thread support in gmalloc.c appears to be turned on when gtk is available and selected and has the new file chooser interface, and pthread support is available. As to how to fix it... I have no good idea at the moment. I assume OpenBSD uses GCC exclusively; if the platform supports constructor attributes on functions, perhaps we could force __malloc_initialize to be called at program startup, without thread protection, and hope that threads don't get created before main starts. It seems a bit dicey, but hey, so is replacing malloc. :-) Trying to detect recursive calls as opposed to simultaneous calls from multiple threads seems tricky, with some of the thread support unavailable until after we finish. It could probably be worked around by specifying a toolkit other than gtk, or turning off x11 support altogether, at configure time, until we get a real fix. Ken