From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add nil check for decoding buffer Date: Wed, 11 Apr 2018 20:00:59 +0300 Message-ID: <83d0z53cfo.fsf@gnu.org> References: <877epepwi1.fsf@mailbox.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1523466003 24289 195.159.176.226 (11 Apr 2018 17:00:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Apr 2018 17:00:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lukas =?iso-8859-1?Q?F=FCrmetz?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 11 18:59:59 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f6J6F-0006Bu-3p for ged-emacs-devel@m.gmane.org; Wed, 11 Apr 2018 18:59:59 +0200 Original-Received: from localhost ([::1]:40799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6J8L-0006XF-Gw for ged-emacs-devel@m.gmane.org; Wed, 11 Apr 2018 13:02:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6J79-0005aw-0P for emacs-devel@gnu.org; Wed, 11 Apr 2018 13:00:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f6J73-0001Im-0w for emacs-devel@gnu.org; Wed, 11 Apr 2018 13:00:55 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6J72-0001Ib-UI; Wed, 11 Apr 2018 13:00:48 -0400 Original-Received: from [176.228.60.248] (port=2515 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f6J72-0002gA-8d; Wed, 11 Apr 2018 13:00:48 -0400 In-reply-to: <877epepwi1.fsf@mailbox.org> (message from Lukas =?iso-8859-1?Q?F=FCrmetz?= on Tue, 10 Apr 2018 23:44:22 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224515 Archived-At: > From: Lukas Fürmetz > Date: Tue, 10 Apr 2018 23:44:22 +0200 > > This patch prevents a emacs crash under Windows for me. Sometimes the > buffer is split between \r\n and the \n is carried over, but the > decoding_buf is NIL, so "SCHARS (p->decoding_buf)" leads to a SEGFAULT. > > Would be nice, if this is backported to emacs-26.. > > Best regards, > Lukas > > --- > src/process.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/process.c b/src/process.c > index c357a8bdc3..ab2e6ce4da 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -5996,7 +5996,7 @@ read_and_dispose_of_process_output (struct Lisp_Process *p, char *chars, > > if (coding->carryover_bytes > 0) > { > - if (SCHARS (p->decoding_buf) < coding->carryover_bytes) > + if (NILP (p->decoding_buf) || (SCHARS (p->decoding_buf) < coding->carryover_bytes)) > pset_decoding_buf (p, make_uninit_string (coding->carryover_bytes)); > memcpy (SDATA (p->decoding_buf), coding->carryover, > coding->carryover_bytes); Thanks, but I don't think this is the right fix for the problem. Every process object must have an associated decoding_buf, so if some process doesn't, it's a bug in that process's creation code. My reading of the code is that all the process types we support have decoding_buf defined during creation -- except one: make-pipe-process fails to do that. So the fix should be in make-pipe-process. Is the problem reproducible, or do you remember what you did when it happened? I'd like to make sure that indeed some pipe process was involved in the crash, because otherwise I don't see how it could happen.