From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: allocate_string_data memory corruption Date: Sun, 22 Jan 2006 20:58:17 -0500 Message-ID: <87y8174smu.fsf-monnier+emacs@gnu.org> References: <87vewha2zl.fsf@stupidchicken.com> <87zmlq6w62.fsf-monnier+emacs@gnu.org> <87u0bw6wwz.fsf-monnier+emacs@gnu.org> <272681AE-627E-4FDF-BD16-246D423524AC@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1137981549 23092 80.91.229.2 (23 Jan 2006 01:59:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2006 01:59:09 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 23 02:59:07 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F0qyv-0006SK-DU for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2006 02:59:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0r1X-0001cN-KN for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2006 21:01:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F0r1N-0001ZO-H7 for emacs-devel@gnu.org; Sun, 22 Jan 2006 21:01:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F0r1J-0001W8-NM for emacs-devel@gnu.org; Sun, 22 Jan 2006 21:01:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0r1J-0001W5-KQ for emacs-devel@gnu.org; Sun, 22 Jan 2006 21:01:25 -0500 Original-Received: from [209.226.175.110] (helo=tomts43-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1F0r5b-0000FB-3H; Sun, 22 Jan 2006 21:05:51 -0500 Original-Received: from alfajor ([67.71.115.65]) by tomts43-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060123015818.POLY23065.tomts43-srv.bellnexxia.net@alfajor>; Sun, 22 Jan 2006 20:58:18 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id BE9BFD73B3; Sun, 22 Jan 2006 20:58:17 -0500 (EST) Original-To: Ken Raeburn In-Reply-To: <272681AE-627E-4FDF-BD16-246D423524AC@gnu.org> (Ken Raeburn's message of "Sun, 22 Jan 2006 19:35:03 -0500") 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 Xref: news.gmane.org gmane.emacs.devel:49426 Archived-At: > It may just push the memory corruption from the Lisp object pool to the > malloc pool, since malloc isn't safe for signal handlers either. Indeed: if you want to really be signal-safe, use -DSYNC_INPUT. With -DSYNC_INPUT, Emacs uses a whole lot of things in signal handlers, including malloc and Xlib calls. So my patch doesn't make it much worse. At least on some systems, Emacs uses malloc hooks to wrap malloc operations inside (UN)BLOCK_INPUT, so that this part "works" (i.e. there's no guarantee it's safe, but in practice on those systems it should be). > Is it possible to pre-allocate this storage on a per-display basis, or > might we have to deal with multiple error messages from one server > without a chance to do processing outside of the signal handler? If this were the only place where we do malloc in signal handlers, it might be worth the trouble. But given the current state of affairs, it'd be a waste of time, I think. Stefan