From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: problems building trunk in OpenBSD/i386 Date: Fri, 13 Jul 2007 09:23:24 +0200 Message-ID: <4697286C.8040605@swipnet.se> References: <874pkaezdu.fsf@tarn.lan> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1184311454 9248 80.91.229.12 (13 Jul 2007 07:24:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 13 Jul 2007 07:24:14 +0000 (UTC) Cc: Eli Zaretskii , Ryan Yeske , emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 13 09:24:10 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 1I9FVa-0001y7-9l for ged-emacs-devel@m.gmane.org; Fri, 13 Jul 2007 09:24:10 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I9FVZ-0002Vg-Kl for ged-emacs-devel@m.gmane.org; Fri, 13 Jul 2007 03:24:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I9FVW-0002VT-Rt for emacs-devel@gnu.org; Fri, 13 Jul 2007 03:24:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I9FVV-0002VD-Al for emacs-devel@gnu.org; Fri, 13 Jul 2007 03:24:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I9FVV-0002VA-8E for emacs-devel@gnu.org; Fri, 13 Jul 2007 03:24:05 -0400 Original-Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I9FVU-0007ZX-QC for emacs-devel@gnu.org; Fri, 13 Jul 2007 03:24:05 -0400 Original-Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id BD05837F0D; Fri, 13 Jul 2007 09:24:03 +0200 (CEST) Original-Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 9020137EB1; Fri, 13 Jul 2007 09:24:03 +0200 (CEST) Original-Received: from husetbladh.homeip.net (81-235-205-78-no59.tbcn.telia.com [81.235.205.78]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 4C52237E45; Fri, 13 Jul 2007 09:24:03 +0200 (CEST) User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) In-Reply-To: X-detected-kernel: Linux 2.4-2.6 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:74716 Archived-At: Ken Raeburn skrev: > > 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. This sounds like a bug in 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. > I think we safely can call malloc_initialize from main itself without thread protection. The protection is from threads created by the file dialog, and they get created when the dialog is first used. So we should be safe. Jan D.