GNU bug report logs - #53136
28.0.90; segfault in lock_file

Previous Next

Package: emacs;

Reported by: Po Lu <luangruo <at> yahoo.com>

Date: Sun, 9 Jan 2022 06:05:01 UTC

Severity: normal

Found in version 28.0.90

Full log


Message #26 received at 53136 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Sun, 09 Jan 2022 14:56:54 +0200
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 53136 <at> debbugs.gnu.org
> Date: Sun, 09 Jan 2022 19:43:47 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > So we somehow wrote more than 8192 bytes by that memcpy line?  I find
> > this hard to believe.
> 
> Manual inspection of the core dump seems to reveal something very
> different from what the debugger said (and I asked for a second opinion
> on this as well):
> 
>  - lock_info.dot and lock_info.colon are NULL.
>  - lock_filename is a Lisp string, the data is
>    "/home/oldosfan/Mail/archive/sent/2022-01".
>  - handler, subject_buf are NULL
>  - dot is NULL
>  - pidlen is -1 (long int)
>  - replacementlen is 6

On second thought, these values are strange.  Is PC really at the
memcpy line?  I don't see how dot could be NULL at that point: if
lock_if_free returns a negative value, lock_info.dot cannot be NULL,
according to my reading of the code.

What is the contents of lock_info.user upto the first null byte?




This bug report was last modified 3 years and 254 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.