From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Core dumps in redisplay. Date: Mon, 28 Feb 2005 21:05:51 +0100 Message-ID: <4357caad916e5632561b09c094c5d375@swipnet.se> References: <7eee8e4a0b7241b67a0ae97e4923b908@swipnet.se> <49e5a9dfdc9abedb548ffb2ba94ee4bb@swipnet.se> <854df3d393258d420a5f4a60c87f6ea0@swipnet.se> <7452a19cb26d7b5243c6cac47273f10e@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1109621695 13277 80.91.229.2 (28 Feb 2005 20:14:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 28 Feb 2005 20:14:55 +0000 (UTC) Cc: Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 28 21:14:54 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D5rGK-0001rT-Gw for ged-emacs-devel@m.gmane.org; Mon, 28 Feb 2005 21:13:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D5rYk-0004bL-Fa for ged-emacs-devel@m.gmane.org; Mon, 28 Feb 2005 15:32:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D5rOk-0004KU-Ir for emacs-devel@gnu.org; Mon, 28 Feb 2005 15:21:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D5rOQ-00048R-VM for emacs-devel@gnu.org; Mon, 28 Feb 2005 15:21:28 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D5rOQ-00048H-Rt for emacs-devel@gnu.org; Mon, 28 Feb 2005 15:21:26 -0500 Original-Received: from [195.54.107.73] (helo=mxfep02.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D5rA8-0006Uj-9M; Mon, 28 Feb 2005 15:06:40 -0500 Original-Received: from coolsville.localdomain ([83.226.180.210] [83.226.180.210]) by mxfep02.bredband.com with ESMTP id <20050228200637.GYWQ27886.mxfep02.bredband.com@coolsville.localdomain>; Mon, 28 Feb 2005 21:06:37 +0100 In-Reply-To: Original-To: David Kastrup X-Mailer: Apple Mail (2.619.2) 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33945 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33945 > "Jan D." writes: > >>> But xmalloc and all related routines use BLOCK_INPUT nevertheless. >>> So >>> it is obvious that although malloc seemingly can be used (given >>> _BOTH_ >>> PTHREAD and GTK) without problems, all uses of xmalloc still are >>> flawed in the old way. >>> >>> So we still can't allow using xmalloc except in the main thread. >>> What >>> is the design? Should xmalloc be usable outside of the main thread >>> or >>> not? >> >> The Gnome file backend does not know about or use xmalloc and friends, >> so only the main thread calls it. > > You wish. No. I know. The only way the other threads can call xmalloc is if a signal handler is called in a non-main thread and then calls xmalloc. This should not happen, but if it does there is a bug somewhere. > > I am putting appropriate assertions in right now and expect > to report otherwise soon (the trace output is rather clear-spoken > about this). I want to have this out of the way before I make an > Emacs/AUCTeX/preview-latex representation at a major GNU/Linux > conference Saturday and a workshop at a major TeX conference next week > without having the demos crash. That's simply uncool. Please insert the thread id in the trace output, otherwise you can't know if it is another thread or a signal handler that calls xmalloc. Jan D.