Subject: bug#53136: 28.0.90; segfault in lock_file

From: Eli Zaretskii <[email-masked]>
Date: Sun, 09 Jan 2022 14:56:54 +0200

> From: Po Lu <[email-masked]>
> Cc: [email-masked]
> Date: Sun, 09 Jan 2022 19:43:47 +0800
> 
> Eli Zaretskii <[email-masked]> 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?