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

Previous Next

To reply to this bug, email your comments to 53136 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.90; segfault in lock_file
Date: Sun, 09 Jan 2022 14:04:23 +0800

This write in `lock_file':

      memcpy (dot, replacement, replacementlen);

Ends up writing one byte outside dot.

I could not find the problem, but someone else may want to take a look.
Thanks.

Message #8 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 09:36:36 +0200

> Resent-From: Po Lu <luangruo <at> yahoo.com>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs <at> gnu.org
> Resent-Sender: help-debbugs <at> gnu.org
> Date: Sun, 09 Jan 2022 14:04:23 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> This write in `lock_file':
> 
>       memcpy (dot, replacement, replacementlen);
> 
> Ends up writing one byte outside dot.
> 
> I could not find the problem, but someone else may want to take a look.

Details, please: the values of all the relevant variables at that
point, including the contents of all the string variables.  And what
is your value of MAX_LFINFO?  I don't see how this can be efficiently
investigated without this data.  In particular, 'dot' has no storage
of its own, it's just a pointer into the lock_info.user[] array.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Sun, 09 Jan 2022 16:10:42 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> This write in `lock_file':
>> 
>>       memcpy (dot, replacement, replacementlen);
>> 
>> Ends up writing one byte outside dot.
>> 
>> I could not find the problem, but someone else may want to take a look.

> Details, please: the values of all the relevant variables at that
> point, including the contents of all the string variables.

gdb says dot is "optimized out" (but valgrind, which I happened to be
running that Emacs under in an attempt to catch the GC bug I reported a
month ago, disagrees).  pidlen is 6.

I will try to get more information from the valgrind core file.

> And what is your value of MAX_LFINFO?

MAX_LFINFO is 8192.

> I don't see how this can be efficiently investigated without this
> data.  In particular, 'dot' has no storage of its own, it's just a
> pointer into the lock_info.user[] array.

Thanks.

Message #14 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 10:42:07 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 53136 <at> debbugs.gnu.org
> Date: Sun, 09 Jan 2022 16:10:42 +0800
> 
> >>       memcpy (dot, replacement, replacementlen);
> >> 
> >> Ends up writing one byte outside dot.
> >> 
> >> I could not find the problem, but someone else may want to take a look.
> 
> > Details, please: the values of all the relevant variables at that
> > point, including the contents of all the string variables.
> 
> gdb says dot is "optimized out" (but valgrind, which I happened to be
> running that Emacs under in an attempt to catch the GC bug I reported a
> month ago, disagrees).  pidlen is 6.
> 
> I will try to get more information from the valgrind core file.

Thanks.

> > And what is your value of MAX_LFINFO?
> 
> MAX_LFINFO is 8192.

So we somehow wrote more than 8192 bytes by that memcpy line?  I find
this hard to believe.

What exactly did valgrind say?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Sun, 09 Jan 2022 17:40:17 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> gdb says dot is "optimized out" (but valgrind, which I happened to be
>> running that Emacs under in an attempt to catch the GC bug I reported a
>> month ago, disagrees).  pidlen is 6.
>> 
>> I will try to get more information from the valgrind core file.

A superficial examination didn't reveal any string that made sense in
the (stack) frame of lock_file.  I will dig deeper later.

> So we somehow wrote more than 8192 bytes by that memcpy line?  I find
> this hard to believe.

Same here, I couldn't find how that happened.

> What exactly did valgrind say?

It complained about an invalid write of size 1 at one byte outside the
current stack frame.

Thanks.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
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

Any ideas?  Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Sun, 09 Jan 2022 14:03:21 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 53136 <at> debbugs.gnu.org
> Date: Sun, 09 Jan 2022 19:43:47 +0800
> 
>  - 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

Maybe that's the problem: it means current_lock_owner returned early
due to some error, and we are dereferencing a NULL pointer.

Paul, could you please take a look?

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?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Sun, 09 Jan 2022 21:00:53 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

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

It's "oldosfan" (which is correct).

Message #32 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 15:10:38 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 53136 <at> debbugs.gnu.org
> Date: Sun, 09 Jan 2022 21:00:53 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > What is the contents of lock_info.user upto the first null byte?
> 
> It's "oldosfan" (which is correct).

No, it's not: it should be of the form USER <at> HOST.PID[:BOOT-TIME].  See
the commentary around line 288 in filelock.c.  The string is generated
in lock_file_1.  maybe you can step into it and see what happens
there.

What is "oldosfan"? is it the user or the host name?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Sun, 09 Jan 2022 21:16:42 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> No, it's not: it should be of the form USER <at> HOST.PID[:BOOT-TIME].  See
> the commentary around line 288 in filelock.c.  The string is generated
> in lock_file_1.  maybe you can step into it and see what happens
> there.

Thanks, I'll look into it.

> What is "oldosfan"? is it the user or the host name?

That is my username.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Sun, 09 Jan 2022 21:23:14 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> Thanks, I'll look into it.

Perhaps the problem is in valgrind: when running under Valgrind, trying
to lock that file makes lock_if_free return -2147459069.

That shouldn't happen, right?  (BTW, while investigating that value, I
noticed a portability problem to Haiku, which I'll fix on the master
branch.)

Thanks.

Message #41 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 15:30:00 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 53136 <at> debbugs.gnu.org
> Date: Sun, 09 Jan 2022 21:23:14 +0800
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> > Thanks, I'll look into it.
> 
> Perhaps the problem is in valgrind: when running under Valgrind, trying
> to lock that file makes lock_if_free return -2147459069.
> 
> That shouldn't happen, right?

It's a strange value, no matter what.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>,
 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Sun, 09 Jan 2022 14:47:59 +0100

On Jan 09 2022, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> That shouldn't happen, right?  (BTW, while investigating that value, I
> noticed a portability problem to Haiku, which I'll fix on the master
> branch.)

This means Haiku is not POSIX compliant, since error numbers must be
positive.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Po Lu <luangruo <at> yahoo.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Mon, 10 Jan 2022 08:29:43 +0800

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> This means Haiku is not POSIX compliant, since error numbers must be
> positive.

This bug isn't about Haiku, but yes, it's not entirely POSIX compliant.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Mon, 10 Jan 2022 15:11:04 -0800

[Message part 1 (text/plain, inline)]

On 1/9/22 04:03, Eli Zaretskii wrote:

> Paul, could you please take a look?

The problem (as Po deduced) seems to be that Haiku errno values are 
negative by default.

However, I see some problems with the recently installed fix.

1. It uses BE_USE_POSITIVE_POSIX_ERRORS but Haiku spells it 
B_USE_POSITIVE_POSIX_ERRORS.

2. There's no need to replace "if (err < 0)" with "if (err == -1 || err 
== -2)", as this replacement is not needed given the "#if !defined HAIKU 
..." stuff.

3. More importantly, I'm sure there are other places where Emacs assumes 
that errno values are positive. I doubt whether it's reasonable to 
expect Emacs developers to remember and work around this Haiku 
incompatibility, every time they call a function that sets errno or 
returns an errno value. Instead, we should arrange for Haiku builds to 
use positive errno values, they way errno behaves on GNU and other 
POSIX-compatible hosts. This should be a much more maintainable solution.

Proposed patch attached.

[0001-Improve-port-to-Haiku-errno-values.patch (text/x-patch, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
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: Mon, 10 Jan 2022 15:30:10 -0800

[Message part 1 (text/plain, inline)]

One little thing I noticed in the Haiku port. I assume the lisp.h 
complication for pD was needed on 32-bit Haiku to avoid compiler 
warnings when passing long vs int (same size, either would work, but 
compiler warning). I installed the attached to simplify the ifdefs here. 
If my diagnosis of the issue is wrong and this patch doesn't work for 
Haiku, please let me know or feel free to revert and we can find a 
better way.

At some point we can get rid of pD by replacing pD with "t" everywhere 
in Emacs, but one step at a time.

[0001-Assume-C99-when-defining-pD.patch (text/x-patch, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Tue, 11 Jan 2022 08:51:25 +0800

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 1/9/22 04:03, Eli Zaretskii wrote:
>
>> Paul, could you please take a look?
>
> The problem (as Po deduced) seems to be that Haiku errno values are
> negative by default.

That was an unrelated problem.  This bug is on GNU/Linux, when running
under Valgrind.  (I was trying to find the GC bug from last month.)

> 1. It uses BE_USE_POSITIVE_POSIX_ERRORS but Haiku spells it
> B_USE_POSITIVE_POSIX_ERRORS.

I'll fix that.

> 2. There's no need to replace "if (err < 0)" with "if (err == -1 ||
> err == -2)", as this replacement is not needed given the "#if !defined
> HAIKU ..." stuff.

> 3. More importantly, I'm sure there are other places where Emacs
> assumes that errno values are positive. I doubt whether it's
> reasonable to expect Emacs developers to remember and work around this
> Haiku incompatibility, every time they call a function that sets errno
> or returns an errno value. Instead, we should arrange for Haiku builds
> to use positive errno values, they way errno behaves on GNU and other
> POSIX-compatible hosts. This should be a much more maintainable
> solution.

I would prefer for us to find and fix those instances manually, because
B_USE_POSITIVE_POSIX_ERRORS is some kind of stopgap measure for porting
POSIX utilities like sshfs, and prevents some other functionality from
working correctly (i.e. apparently it's an error to -ltracker with it
defined, so file dialogs won't work.)

Thanks.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Tue, 11 Jan 2022 08:51:51 +0800

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> At some point we can get rid of pD by replacing pD with "t" everywhere
> in Emacs, but one step at a time.

It works here, thanks.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Tue, 11 Jan 2022 08:58:16 +0800

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> +    AC_DEFINE([B_USE_POSITIVE_POSIX_ERRORS], [],
> +      [Define to cause Haiku to use POSIX-compatible errno values.])

Also, for this to have a chance of working in purely tty Haiku builds,
you have to give the linker `-lposix_error_mapper'.

Maybe doing that in tty builds would be a good idea.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Tue, 11 Jan 2022 09:05:34 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> That was an unrelated problem.  This bug is on GNU/Linux, when running
> under Valgrind.  (I was trying to find the GC bug from last month.)

It happens with valgrind-3.18.1-7.fc35, but not valgrind-3.17.0-13.fc35.

Paul, any idea why this may be?  Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: luangruo <at> yahoo.com, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Tue, 11 Jan 2022 14:30:03 +0200

> Date: Mon, 10 Jan 2022 15:11:04 -0800
> Cc: 53136 <at> debbugs.gnu.org, Po Lu <luangruo <at> yahoo.com>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> 3. More importantly, I'm sure there are other places where Emacs assumes 
> that errno values are positive. I doubt whether it's reasonable to 
> expect Emacs developers to remember and work around this Haiku 
> incompatibility, every time they call a function that sets errno or 
> returns an errno value. Instead, we should arrange for Haiku builds to 
> use positive errno values, they way errno behaves on GNU and other 
> POSIX-compatible hosts. This should be a much more maintainable solution.

I agree.

Message #74 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: eggert <at> cs.ucla.edu, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Tue, 11 Jan 2022 14:45:57 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  53136 <at> debbugs.gnu.org
> Date: Tue, 11 Jan 2022 08:51:25 +0800
> 
> > 3. More importantly, I'm sure there are other places where Emacs
> > assumes that errno values are positive. I doubt whether it's
> > reasonable to expect Emacs developers to remember and work around this
> > Haiku incompatibility, every time they call a function that sets errno
> > or returns an errno value. Instead, we should arrange for Haiku builds
> > to use positive errno values, they way errno behaves on GNU and other
> > POSIX-compatible hosts. This should be a much more maintainable
> > solution.
> 
> I would prefer for us to find and fix those instances manually, because
> B_USE_POSITIVE_POSIX_ERRORS is some kind of stopgap measure for porting
> POSIX utilities like sshfs, and prevents some other functionality from
> working correctly (i.e. apparently it's an error to -ltracker with it
> defined, so file dialogs won't work.)

Ugh!

Fixing each place individually is a time bomb: no one will remember
that after enough time has passed, and we will add bugs.

The only alternative is to filter errno via some macro, which will do
nothing on all platforms but Haiku, where it will map them to Posix
values.  Butt-ugly, but it's not our fault.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Tue, 11 Jan 2022 13:16:35 +0000 (UTC)

[Message part 1 (text/plain, inline)]

 [Sorry for the webmail, but Yahoo SMTP is wedged; I hope Reply All
worked and this reaches the bug tracker]

> Ugh!

I agree completely.

> Fixing each place individually is a time bomb: no one will remember
> that after enough time has passed, and we will add bugs.

> The only alternative is to filter errno via some macro, which will do
> nothing on all platforms but Haiku, where it will map them to Posix
> values. Butt-ugly, but it's not our fault.

Hmm, perhaps gnulib can do something in this area? Paul, any ideas?
Thanks in advance.
  

[Message part 2 (text/html, inline)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>
Cc: 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Tue, 11 Jan 2022 09:05:25 -0800

[Message part 1 (text/plain, inline)]

On 1/11/22 05:16, Po Lu wrote:

>  > Fixing each place individually is a time bomb: no one will remember
>  > that after enough time has passed, and we will add bugs.
> 
>  > The only alternative is to filter errno via some macro, which will do
>  > nothing on all platforms but Haiku, where it will map them to Posix
>  > values. Butt-ugly, but it's not our fault.
> 
> Hmm, perhaps gnulib can do something in this area? Paul, any ideas?
> Thanks in advance.

Here are three possibilities:

1. Carefully audit the many hundreds of use of errno values in Emacs and 
make sure they still work even on Haiku, updating Gnulib accordingly. I 
think we agree this is a big and continuing maintenance hassle. I just 
did a bit more of this sort of thing in filelock.c (please see attached) 
and would rather not do more.


2. Change Gnulib so that on Haiku Gnulib wraps errno-producing functions 
called by Emacs (and by Gnulib), so that they negate errno before 
returning. Gnulib would also wrap errno.h so that errno constants are 
positive. This would affect only calls from Emacs code; it wouldn't 
affect calls from Haiku libraries, so file dialogs would continue to work.

Unfortunately this would be a maintenance hassle too. I suppose we could 
adjust Gnulib to wrap only the errno-producing functions that Emacs 
cares about, either directly or indirectly via Gnulib. However, I expect 
there are some such functions not in the standard library, and I doubt 
whether we'd want to change Gnulib to wrap random functions in random 
libraries. For these functions, we'd need to modify Emacs much as we 
already modified filelock.c.


3. Compile Emacs code with B_USE_POSITIVE_POSIX_ERRORS, and use linker 
magic only on this code; do not use linker magic on library code (e.g., 
-ltracker) so that Haiku library code uses the original functions. That 
way, Emacs source code proper would need to worry about negative errno 
values only in haiku*.c files that call Haiku-specific libraries. If 
this is feasible, it should be much less work and more maintainable. 
Could you look into that?

[0001-Clean-up-filelock-code-related-to-errno.patch (text/x-patch, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Wed, 12 Jan 2022 08:35:52 +0800

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> 3. Compile Emacs code with B_USE_POSITIVE_POSIX_ERRORS, and use linker
> magic only on this code; do not use linker magic on library code
> (e.g., -ltracker) so that Haiku library code uses the original
> functions. That way, Emacs source code proper would need to worry
> about negative errno values only in haiku*.c files that call
> Haiku-specific libraries. If this is feasible, it should be much less
> work and more maintainable. Could you look into that?

I tried yesterday and got many mysterious assertation failures in the
system library code, but it won't hurt to take another crack at that.

Thanks.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Tue, 11 Jan 2022 18:59:35 -0800

On 1/10/22 17:05, Po Lu wrote:
> Po Lu <luangruo <at> yahoo.com> writes:
> 
>> That was an unrelated problem.  This bug is on GNU/Linux, when running
>> under Valgrind.  (I was trying to find the GC bug from last month.)
> 
> It happens with valgrind-3.18.1-7.fc35, but not valgrind-3.17.0-13.fc35.
> 
> Paul, any idea why this may be?  Thanks.

Looking at the 3.18.1 release notes:

https://valgrind.org/docs/manual/dist.news.html

what jumps out at me are these entries:

 * glibc 2.34, which moved various functions from libpthread.so into
   libc.so, is now supported.
 407589  [Linux] Add support for C11 aligned_alloc() and GNU reallocarray()
 442061  very slow execution under Fedora 34 (readdwarf3)

It could be that these changes caused a bug in Valgrind. I think Emacs 
is using aligned_alloc and reallocarray.

I tried building Emacs master (savannah) on both Ubuntu 21.10 x86-64, 
which has valgrind-3.17.0, and on Fedora 35 x86-64, which has 
valgrind-3.18.1, and both instances worked for me. I was running the 
Fedora 35 instance on an AMD Phenom II X4 910e.

I merely stole a lock using an interactive Emacs as my test, though. 
What test are you using to reproduce the bug?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Wed, 12 Jan 2022 11:04:53 +0800

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 1/10/22 17:05, Po Lu wrote:
>> Po Lu <luangruo <at> yahoo.com> writes:
>> 
>>> That was an unrelated problem.  This bug is on GNU/Linux, when running
>>> under Valgrind.  (I was trying to find the GC bug from last month.)
>> It happens with valgrind-3.18.1-7.fc35, but not
>> valgrind-3.17.0-13.fc35.
>> Paul, any idea why this may be?  Thanks.
>
> Looking at the 3.18.1 release notes:
>
> https://valgrind.org/docs/manual/dist.news.html
>
> what jumps out at me are these entries:
>
>  * glibc 2.34, which moved various functions from libpthread.so into
>    libc.so, is now supported.
>  407589  [Linux] Add support for C11 aligned_alloc() and GNU reallocarray()
>  442061  very slow execution under Fedora 34 (readdwarf3)
>
> It could be that these changes caused a bug in Valgrind. I think Emacs
> is using aligned_alloc and reallocarray.
>
> I tried building Emacs master (savannah) on both Ubuntu 21.10 x86-64,
> which has valgrind-3.17.0, and on Fedora 35 x86-64, which has
> valgrind-3.18.1, and both instances worked for me. I was running the
> Fedora 35 instance on an AMD Phenom II X4 910e.

> I merely stole a lock using an interactive Emacs as my test,
> though. What test are you using to reproduce the bug?

(lock-file "~/any/nonexistent/file/with/a/very/long/path") will
consistently reproduce the bug.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53136 <at> debbugs.gnu.org
Subject: Re: bug#53136: 28.0.90; segfault in lock_file
Date: Wed, 12 Jan 2022 11:22:16 -0800

[Message part 1 (text/plain, inline)]

On 1/11/22 19:04, Po Lu wrote:
> (lock-file "~/any/nonexistent/file/with/a/very/long/path")

Unfortunately I'm still not reproducing the problem on Fedora 35 x86-64. 
Here's how I tried to reproduce it, while in the src directory:

 valgrind --suppressions=valgrind.supp ./emacs -Q -batch -eval '
   (let ((f "/d"))
     (dotimes (i 13) (setq f (concat f f)))
     (lock-file f))
 '

I configured Emacs this way:

./configure --enable-checking

(in general this is needed if you want to use Valgrind), and used the 
attached valgrind.supp.

[valgrind.supp (text/plain, attachment)]

Previous Next

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