From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Core dumps in redisplay. Date: Mon, 28 Feb 2005 18:14:09 +0100 Message-ID: References: <7eee8e4a0b7241b67a0ae97e4923b908@swipnet.se> <49e5a9dfdc9abedb548ffb2ba94ee4bb@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109611921 11270 80.91.229.2 (28 Feb 2005 17:32:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 28 Feb 2005 17:32:01 +0000 (UTC) Cc: Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 28 18:32:01 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D5oij-0001nr-0R for ged-emacs-devel@m.gmane.org; Mon, 28 Feb 2005 18:30:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D5p17-0006xo-Dj for ged-emacs-devel@m.gmane.org; Mon, 28 Feb 2005 12:49:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D5ozq-0006YK-Q7 for emacs-devel@gnu.org; Mon, 28 Feb 2005 12:47:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D5ozq-0006Y1-0z for emacs-devel@gnu.org; Mon, 28 Feb 2005 12:47:54 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D5oxe-00053k-Qn for emacs-devel@gnu.org; Mon, 28 Feb 2005 12:45:38 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D5oTD-0007mC-Gd for emacs-devel@gnu.org; Mon, 28 Feb 2005 12:14:11 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D5oTC-0002aG-PL; Mon, 28 Feb 2005 12:14:11 -0500 Original-To: "Jan D." In-Reply-To: <49e5a9dfdc9abedb548ffb2ba94ee4bb@swipnet.se> (Jan D.'s message of "Mon, 28 Feb 2005 06:34:30 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:33937 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33937 "Jan D." writes: >> >> This sounds like normally only the main thread should ever be touching >> interrupt_input_blocked, unless we have a bug. Correct? So we need >> not think about how to synchronize accesses to the variable, but >> rather make sure that no thread except the main thread will ever run >> code touching it. Correct? >> >> A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a >> bug. Correct? > > Yes times three. I have got the debugging working. Clearly xmalloc is called in a separate thread (its BLOCK/UNBLOCK calls which are placed just round malloc are interspersed with that of other routines), and its deallocation interferes with the deallocation from the main thread. So we should probably add an xassert into BLOCK_INPUT and UNBLOCK_INPUT that complains when we are in anything but the main thread. And then see whether we can get rid of all the resulting aborts in a sane manner. If we don't do this, I am afraid that we will be plagued with occasional unreproduceable aborts and/or problems. I also doubt that it is a good idea to have mallocs in parallel threads at the same time. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum