Help with new Windows 98 crash

Help with new Windows 98 crash

[Po Lu]

Emacs 30 (with unexec) is crashing on Windows 98 again, this time during
GC.

I cannot find a version of GDB that reads DWARF generated by GCC 9,
but here is the backtrace from GDB 5, which cannot read the debug
information in emacs.exe:

  #0 0x011e5491
  #1 0x00a44b68
  #2 0x00160070
  #3 0x00343030

the backtrace stops here, after which GDB complains it cannot access
memory at address 0x30303030.

addr2line says the first address belongs to line 606 of w32heap.c.  The
rest are garbage.  Could it be that something is trying to free dumped
memory?

(and if anyone can find a copy of GDB that works on Windows 98 and can
read the debuginfo, that would be best.  Thanks in advance.)

Re: Help with new Windows 98 crash

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Mon, 05 Dec 2022 22:18:18 +0800
> 
> Emacs 30 (with unexec) is crashing on Windows 98 again, this time during
> GC.

I tried to build it on X, but the build fails:

  xfns.c:46:10: fatal error: xcb/xcb_aux.h: No such file or directory
   #include <xcb/xcb_aux.h>
	    ^~~~~~~~~~~~~~~
  compilation terminated.

can you please fix that?  Then I could see if the problem is not only
Windows specific.

> I cannot find a version of GDB that reads DWARF generated by GCC 9,
> but here is the backtrace from GDB 5, which cannot read the debug
> information in emacs.exe:
> 
>   #0 0x011e5491
>   #1 0x00a44b68
>   #2 0x00160070
>   #3 0x00343030
> 
> the backtrace stops here, after which GDB complains it cannot access
> memory at address 0x30303030.
> 
> addr2line says the first address belongs to line 606 of w32heap.c.  The
> rest are garbage.  Could it be that something is trying to free dumped
> memory?

Could be, I have no idea yet.  But then FREEABLE_P doesn't do its job,
right?

> (and if anyone can find a copy of GDB that works on Windows 98 and can
> read the debuginfo, that would be best.  Thanks in advance.)

Did you try building with -gstabs+ instead?

P.S. And maybe we should try fixing the problem that requires to use unexec
on Windows 9X to begin with.

Re: Help with new Windows 98 crash

[Eli Zaretskii]

> Date: Mon, 05 Dec 2022 16:52:28 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Po Lu <luangruo@yahoo.com>
> > Date: Mon, 05 Dec 2022 22:18:18 +0800
> > 
> > Emacs 30 (with unexec) is crashing on Windows 98 again, this time during
> > GC.
> 
> I tried to build it on X, but the build fails:
> 
>   xfns.c:46:10: fatal error: xcb/xcb_aux.h: No such file or directory
>    #include <xcb/xcb_aux.h>
> 	    ^~~~~~~~~~~~~~~
>   compilation terminated.
> 
> can you please fix that?

Never mind, I already fixed this.

> Then I could see if the problem is not only Windows specific.

Seems to be: the build on GNU/Linux doesn't crash.  Unless there's something
special that I need to do to crash it.

Re: Help with new Windows 98 crash

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 05 Dec 2022 16:52:28 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > From: Po Lu <luangruo@yahoo.com>
>> > Date: Mon, 05 Dec 2022 22:18:18 +0800
>> > 
>> > Emacs 30 (with unexec) is crashing on Windows 98 again, this time during
>> > GC.
>> 
>> I tried to build it on X, but the build fails:
>> 
>>   xfns.c:46:10: fatal error: xcb/xcb_aux.h: No such file or directory
>>    #include <xcb/xcb_aux.h>
>> 	    ^~~~~~~~~~~~~~~
>>   compilation terminated.
>> 
>> can you please fix that?
>
> Never mind, I already fixed this.
>
>> Then I could see if the problem is not only Windows specific.
>
> Seems to be: the build on GNU/Linux doesn't crash.  Unless there's something
> special that I need to do to crash it.

I think I have figured it out.

init_bignum must be called before make_initial_frame, because that
allocates a bignum in temacs (as set_window_buffer calls
bset_display_time and Fcurrent_time, which go through the time
arithmetic stuff), before our own allocator has been set up, which ends
up in the dumped Emacs, leading to a free of a pointer from the wrong
heap once the bignum is garbage collected.

I have installed the change on the Emacs 30 branch because I am not sure
it is safe for Emacs 29.  Can you think of a safer fix?

Re: Help with new Windows 98 crash

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 06 Dec 2022 09:29:04 +0800
> 
> init_bignum must be called before make_initial_frame, because that
> allocates a bignum in temacs (as set_window_buffer calls
> bset_display_time and Fcurrent_time, which go through the time
> arithmetic stuff), before our own allocator has been set up, which ends
> up in the dumped Emacs, leading to a free of a pointer from the wrong
> heap once the bignum is garbage collected.
> 
> I have installed the change on the Emacs 30 branch because I am not sure
> it is safe for Emacs 29.  Can you think of a safer fix?

There's nothing unsafe in what you did, but:

  . the call to init_bignum inside the !initialized block should be
    conditioned on HAVE_UNEXEC
  . the call to init_bignum that is a few lines below that, and outside of
    the !initialized condition should be conditioned using HAVE_UNEXEC and
    initialized such that we don't invoke this function twice in any case,
    whether this is during dumping or not and whether this is a pdumper
    build or not

If you do these two changes, we can have the result on the release branch.

Please show the patch before installing.

Thanks.

Re: Help with new Windows 98 crash

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 06 Dec 2022 09:29:04 +0800
>> 
>> init_bignum must be called before make_initial_frame, because that
>> allocates a bignum in temacs (as set_window_buffer calls
>> bset_display_time and Fcurrent_time, which go through the time
>> arithmetic stuff), before our own allocator has been set up, which ends
>> up in the dumped Emacs, leading to a free of a pointer from the wrong
>> heap once the bignum is garbage collected.
>> 
>> I have installed the change on the Emacs 30 branch because I am not sure
>> it is safe for Emacs 29.  Can you think of a safer fix?
>
> There's nothing unsafe in what you did, but:
>
>   . the call to init_bignum inside the !initialized block should be
>     conditioned on HAVE_UNEXEC

But doesn't it have to come before init_window_once in any case?
Otherwise, the wrong malloc will be used even on pdumper builds.

>   . the call to init_bignum that is a few lines below that, and outside of
>     the !initialized condition should be conditioned using HAVE_UNEXEC and
>     initialized such that we don't invoke this function twice in any case,
>     whether this is during dumping or not and whether this is a pdumper
>     build or not

Okay, that's fine by me.

Re: Help with new Windows 98 crash

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 06 Dec 2022 20:53:53 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There's nothing unsafe in what you did, but:
> >
> >   . the call to init_bignum inside the !initialized block should be
> >     conditioned on HAVE_UNEXEC
> 
> But doesn't it have to come before init_window_once in any case?
> Otherwise, the wrong malloc will be used even on pdumper builds.

You mean, in the pdumper build?  In that build, what init_bignum does is not
dumped, so I don't think we need it.  Otherwise, why didn't we see any
problems until now?

But if you want to call it in the pdumper build as well, I won't mind.  Just
let's make sure it is called only once upon each invocation.

Re: Help with new Windows 98 crash

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> You mean, in the pdumper build?  In that build, what init_bignum does is not
> dumped, so I don't think we need it.  Otherwise, why didn't we see any
> problems until now?
>
> But if you want to call it in the pdumper build as well, I won't mind.  Just
> let's make sure it is called only once upon each invocation.

OK, please see the patch I attached in my reply in the other thread.