bug#51688: ELC+ELN international/emoji.elc crashes

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

ELC+ELN  international/emoji.elc
Backtrace:
../src/emacs(+0x15f9ed)[0x55bccc00b9ed]
../src/emacs(+0x4de1c)[0x55bccbef9e1c]
../src/emacs(+0x4e3c4)[0x55bccbefa3c4]
../src/emacs(+0x27105d)[0x55bccc11d05d]
/lib64/libc.so.6(+0x427a0)[0x7f7c6c30b7a0]
/lib64/libgccjit.so.0(+0x10251f1)[0x7f7c6d4f81f1]
/lib64/libgccjit.so.0(+0x102a7c9)[0x7f7c6d4fd7c9]
/lib64/libgccjit.so.0(+0x104b66f)[0x7f7c6d51e66f]
/lib64/libgccjit.so.0(+0xedca52)[0x7f7c6d3afa52]
/lib64/libgccjit.so.0(+0x106d1d2)[0x7f7c6d5401d2]
/lib64/libgccjit.so.0(gcc_jit_context_compile_to_file+0x355)[0x7f7c6d51bca5]
../src/emacs(+0x217e4e)[0x55bccc0c3e4e]
../src/emacs(+0x1ca548)[0x55bccc076548]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/native-lisp/29.0.50-85554438/comp-7672a6ed-a040a5e7.eln(F636f6d702d636f6d70696c652d637478742d746f2d66696c65_comp_compile_ctxt_to_file_0+0x1aa)[0x7f7c672d2cda]
../src/emacs(+0x1ca548)[0x55bccc076548]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/native-lisp/29.0.50-85554438/comp-7672a6ed-a040a5e7.eln(F636f6d702d66696e616c31_comp_final1_0+0xc5)[0x7f7c672d2ec5]
../src/emacs(+0x1ca548)[0x55bccc076548]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/native-lisp/29.0.50-85554438/comp-7672a6ed-a040a5e7.eln(F636f6d702d66696e616c_comp_final_0+0xdc)[0x7f7c672d311c]
../src/emacs(+0x1ca548)[0x55bccc076548]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/native-lisp/29.0.50-85554438/comp-7672a6ed-a040a5e7.eln(F636f6d702d2d6e61746976652d636f6d70696c65_comp__native_compile_0+0x72a)[0x7f7c672d6e1a]
../src/emacs(+0x1ca548)[0x55bccc076548]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/native-lisp/29.0.50-85554438/comp-7672a6ed-a040a5e7.eln(F636f6d702d7472616d706f6c696e652d636f6d70696c65_comp_trampoline_compile_0+0x5cd)[0x7f7c672d455d]
../src/emacs(+0x1ca548)[0x55bccc076548]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/native-lisp/29.0.50-85554438/comp-7672a6ed-a040a5e7.eln(F636f6d702d737562722d7472616d706f6c696e652d696e7374616c6c_comp_subr_trampoline_install_0+0x16a)[0x7f7c67280a0a]
../src/emacs(+0x1ca548)[0x55bccc076548]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/src/../native-lisp/29.0.50-85554438/preloaded/nadvice-64630aaa-4c5c4a90.eln(F6164766963652d2d6164642d66756e6374696f6e_advice__add_function_0+0x14f)[0x7f7c67d6355f]
../src/emacs(+0x1ca548)[0x55bccc076548]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/src/../native-lisp/29.0.50-85554438/preloaded/nadvice-64630aaa-4c5c4a90.eln(F6164766963652d616464_advice_add_0+0x1b0)[0x7f7c67d64ba0]
../src/emacs(+0x1ca548)[0x55bccc076548]
../src/emacs(+0x20fd46)[0x55bccc0bbd46]
../src/emacs(+0x1cb908)[0x55bccc077908]
../src/emacs(+0x1ccc7b)[0x55bccc078c7b]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/native-lisp/29.0.50-85554438/transient-376febf1-23039d56.eln(top_level_run+0x3dea)[0x7f7c6705e44a]
../src/emacs(+0x2186e1)[0x55bccc0c46e1]
../src/emacs(+0x218bc0)[0x55bccc0c4bc0]
../src/emacs(+0x1f67fd)[0x55bccc0a27fd]
../src/emacs(+0x27368a)[0x55bccc11f68a]
../src/emacs(+0x1e298b)[0x55bccc08e98b]
../src/emacs(+0x1ca548)[0x55bccc076548]
../src/emacs(+0x1cad53)[0x55bccc076d53]
/home/abuild/rpmbuild/BUILD/emacs-29.0.50/native-lisp/29.0.50-85554438/bytecomp-12882072-9ede205f.eln(F627974652d636f6d70696c652d66696c652d666f726d2d72657175697265_byte_compile_file_form_require_0+0x6e)[0x7f7c6721f91e]
...
make[3]: *** [Makefile:316: international/emoji.elc] Segmentation fault

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Mon, 08 Nov 2021 14:11:59 +0100
> 
> ELC+ELN  international/emoji.elc
> Backtrace:
> ../src/emacs(+0x15f9ed)[0x55bccc00b9ed]
> ../src/emacs(+0x4de1c)[0x55bccbef9e1c]
> ../src/emacs(+0x4e3c4)[0x55bccbefa3c4]
> ../src/emacs(+0x27105d)[0x55bccc11d05d]

Could you please also provide the details collected by
report-emacs-bug, and perhaps also a more readable backtrace (in the C
parts)?

Thanks.

bug#51688: ELC+ELN international/emoji.elc crashes

[Lars Ingebrigtsen]

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

> ELC+ELN  international/emoji.elc
> Backtrace:
> ../src/emacs(+0x15f9ed)[0x55bccc00b9ed]

This is with a full AOT compilation, I guess?  I just tried the same on
Debian/bullseye, and it didn't segfault for me, so perhaps it's tied to
a specific libgccjit version?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

On Nov 08 2021, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Date: Mon, 08 Nov 2021 14:11:59 +0100
>> 
>> ELC+ELN  international/emoji.elc
>> Backtrace:
>> ../src/emacs(+0x15f9ed)[0x55bccc00b9ed]
>> ../src/emacs(+0x4de1c)[0x55bccbef9e1c]
>> ../src/emacs(+0x4e3c4)[0x55bccbefa3c4]
>> ../src/emacs(+0x27105d)[0x55bccc11d05d]
>
> Could you please also provide the details collected by
> report-emacs-bug, and perhaps also a more readable backtrace (in the C
> parts)?

I have only the log file.

https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/f/x86_64

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: 51688@debbugs.gnu.org
> Date: Mon, 08 Nov 2021 14:50:36 +0100
> 
> On Nov 08 2021, Eli Zaretskii wrote:
> 
> > Could you please also provide the details collected by
> > report-emacs-bug, and perhaps also a more readable backtrace (in the C
> > parts)?
> 
> I have only the log file.
> 
> https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/f/x86_64

Thanks.  So there's no chance of getting the file names and line
numbers from the backtrace?  If so, I guess someone will have to
reproduce this crash and debug it.

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

On Nov 08 2021, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> ELC+ELN  international/emoji.elc
>> Backtrace:
>> ../src/emacs(+0x15f9ed)[0x55bccc00b9ed]
>
> This is with a full AOT compilation, I guess?  I just tried the same on
> Debian/bullseye, and it didn't segfault for me, so perhaps it's tied to
> a specific libgccjit version?

Did you run a full bootstrap?

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Lars Ingebrigtsen]

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

> Did you run a full bootstrap?

Yes, I said:

NATIVE_FULL_AOT=1 make -j16 bootstrap

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

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

> ELC+ELN  international/emoji.elc
> Backtrace:
> ../src/emacs(+0x15f9ed)[0x55bccc00b9ed]
> ../src/emacs(+0x4de1c)[0x55bccbef9e1c]
> ../src/emacs(+0x4e3c4)[0x55bccbefa3c4]
> ../src/emacs(+0x27105d)[0x55bccc11d05d]
> /lib64/libc.so.6(+0x427a0)[0x7f7c6c30b7a0]
> /lib64/libgccjit.so.0(+0x10251f1)[0x7f7c6d4f81f1]
> /lib64/libgccjit.so.0(+0x102a7c9)[0x7f7c6d4fd7c9]
> /lib64/libgccjit.so.0(+0x104b66f)[0x7f7c6d51e66f]
> /lib64/libgccjit.so.0(+0xedca52)[0x7f7c6d3afa52]
> /lib64/libgccjit.so.0(+0x106d1d2)[0x7f7c6d5401d2]
> /lib64/libgccjit.so.0(gcc_jit_context_compile_to_file+0x355)[0x7f7c6d51bca5]
> ../src/emacs(+0x217e4e)[0x55bccc0c3e4e]
> ../src/emacs(+0x1ca548)[0x55bccc076548]
> /home/abuild/rpmbuild/BUILD/emacs-29.0.50/native-lisp/29.0.50-85554438/comp-7672a6ed-a040a5e7.eln(F636f6d702d636f6d70696c652d637478742d746f2d66696c65_comp_compile_ctxt_to_file_0+0x1aa)[0x7f7c672d2cda]

[...]

I cannot reproduce this on my system (I guess cause of the different
libgccjit version).

If the crash is on the libgccjit side IMO it indicates it's a libgccjit
bug.

Regards

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

On Nov 17 2021, Andrea Corallo wrote:

> If the crash is on the libgccjit side IMO it indicates it's a libgccjit
> bug.

It can easily be a wrong use of it, too.

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

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

> On Nov 17 2021, Andrea Corallo wrote:
>
>> If the crash is on the libgccjit side IMO it indicates it's a libgccjit
>> bug.
>
> It can easily be a wrong use of it, too.

Agree, but it should not crash.

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

On Nov 17 2021, Andrea Corallo wrote:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> On Nov 17 2021, Andrea Corallo wrote:
>>
>>> If the crash is on the libgccjit side IMO it indicates it's a libgccjit
>>> bug.
>>
>> It can easily be a wrong use of it, too.
>
> Agree, but it should not crash.

If you pass it invalid data (like use-after-free), it may not be able to
avoid a crash.

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

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

> On Nov 17 2021, Andrea Corallo wrote:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>
>>> On Nov 17 2021, Andrea Corallo wrote:
>>>
>>>> If the crash is on the libgccjit side IMO it indicates it's a libgccjit
>>>> bug.
>>>
>>> It can easily be a wrong use of it, too.
>>
>> Agree, but it should not crash.
>
> If you pass it invalid data (like use-after-free), it may not be able to
> avoid a crash.

That is true.  OTOH the API of libgccjit AFAIK is made to copy any
region of memory passed to it during the libgccjit record phase so it's
quite robust in this sense.

Here we are crashing calling from 'comp_compile_ctxt_to_file' therfore
we are in the replay phase and use-after-free should have caused a
problem earlier.

I can't prove my conclusion is correct, but that's what my knowledge and
experience on this system tells me here.

Anyway, if someone has access to a machine were we can reproduce it,
creating a libgccjit reproducer using `comp-libgccjit-reproducer' should
be the way to look at it and test if my idea is correct or not.

Regards

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

On Nov 17 2021, Andrea Corallo wrote:

> Anyway, if someone has access to a machine were we can reproduce it,

It is 100% reproducible here:

https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/f/x86_64

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

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

> On Nov 17 2021, Andrea Corallo wrote:
>
>> Anyway, if someone has access to a machine were we can reproduce it,
>
> It is 100% reproducible here:
>
> https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/f/x86_64
>
> Andreas.

Yes but I don't have access to that machine, do you?

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

On Nov 18 2021, Andrea Corallo wrote:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> On Nov 17 2021, Andrea Corallo wrote:
>>
>>> Anyway, if someone has access to a machine were we can reproduce it,
>>
>> It is 100% reproducible here:
>>
>> https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/f/x86_64
>>
>> Andreas.
>
> Yes but I don't have access to that machine, do you?

Everyone can run that locally.

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

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

> On Nov 18 2021, Andrea Corallo wrote:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>
>>> On Nov 17 2021, Andrea Corallo wrote:
>>>
>>>> Anyway, if someone has access to a machine were we can reproduce it,
>>>
>>> It is 100% reproducible here:
>>>
>>> https://build.opensuse.org/package/live_build_log/home:AndreasSchwab:emacs:master/emacs/f/x86_64
>>>
>>> Andreas.
>>
>> Yes but I don't have access to that machine, do you?
>
> Everyone can run that locally.
>
> Andreas.

Wonderful, then if you have time to configure a system where you can
reproduce it locally just please do it.  ATM I don't as similarly I've
no time to answer obvious mails.

BR

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

On Nov 17 2021, Andrea Corallo wrote:

> I cannot reproduce this on my system (I guess cause of the different
> libgccjit version).

With the very latest libgccjit version it crashes all the same.

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Mon, 22 Nov 2021 11:51:47 +0100
> Cc: 51688@debbugs.gnu.org
> 
> On Nov 17 2021, Andrea Corallo wrote:
> 
> > I cannot reproduce this on my system (I guess cause of the different
> > libgccjit version).
> 
> With the very latest libgccjit version it crashes all the same.

Can you produce a reproducer for Andrea to analyze?  (How to do that
is explained in etc/DEBUG; search for "reproducer".)

Thanks.

bug#51688: ELC+ELN international/emoji.elc crashes

[Robert Pluim]

>>>>> On Mon, 22 Nov 2021 16:48:13 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Andreas Schwab <schwab@linux-m68k.org>
    >> Date: Mon, 22 Nov 2021 11:51:47 +0100
    >> Cc: 51688@debbugs.gnu.org
    >> 
    >> On Nov 17 2021, Andrea Corallo wrote:
    >> 
    >> > I cannot reproduce this on my system (I guess cause of the different
    >> > libgccjit version).
    >> 
    >> With the very latest libgccjit version it crashes all the same.

    Eli> Can you produce a reproducer for Andrea to analyze?  (How to do that
    Eli> is explained in etc/DEBUG; search for "reproducer".)

Iʼve seen this crash *once* in my Tumbleweed VM, which unfortunately
had core dumps disabled. Iʼve not seen it since enabling core
dumps. Iʼll see what happens if I uses Andreas' configure options.

Robert
-- 

bug#51688: ELC+ELN international/emoji.elc crashes

[Robert Pluim]

>>>>> On Mon, 22 Nov 2021 15:55:57 +0100, Robert Pluim <rpluim@gmail.com> said:

    Robert> Iʼve seen this crash *once* in my Tumbleweed VM, which unfortunately
    Robert> had core dumps disabled. Iʼve not seen it since enabling core
    Robert> dumps. Iʼll see what happens if I uses Andreas' configure options.

So this only seems to happen in a clean checkout, and I suspect I need
to remove ~/.emacs.d/eln-cache as well.

SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0
TERM = xterm-256color
Breakpoint 1 at 0x4247e3: file emacs.c, line 406.
Breakpoint 2 at 0x4df170: file xterm.c, line 11599.
#0  0x00007f9e6a53387c in __pthread_kill_implementation () at /lib64/libc.so.6
#1  0x00007f9e6a4e66f6 in raise () at /lib64/libc.so.6
#2  0x0000000000424880 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:443
#3  0x0000000000424cff in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1780
#4  0x0000000000527688 in deliver_thread_signal (sig=sig@entry=11, handler=0x424cf4 <handle_fatal_signal>) at sysdep.c:1772
#5  0x00000000005276f9 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1792
#6  handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1885
#7  0x00007f9e6a4e67a0 in <signal handler called> () at /lib64/libc.so.6
#8  0x00007f9e6b6d3231 in  () at /lib64/libgccjit.so.0
#9  0x00007f9e6b6d8809 in  () at /lib64/libgccjit.so.0
#10 0x00007f9e6b6f969f in  () at /lib64/libgccjit.so.0
#11 0x00007f9e6b58aa92 in  () at /lib64/libgccjit.so.0
#12 0x00007f9e6b71b1f2 in  () at /lib64/libgccjit.so.0
#13 0x00007f9e6b6f6cd5 in gcc_jit_context_compile_to_file () at /lib64/libgccjit.so.0
#14 0x00000000005cfc7e in Fcomp__compile_ctxt_to_file (filename=XIL(0x2259fd4)) at /home/rpluim/repos/emacs-3/src/lisp.h:1577
#15 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffab190) at eval.c:3068
#16 0x00007f9e67173cda in F636f6d702d636f6d70696c652d637478742d746f2d66696c65_comp_compile_ctxt_to_file_0 ()
    at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#17 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffab250) at eval.c:3068
#18 0x00007f9e67173ec5 in F636f6d702d66696e616c31_comp_final1_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#19 0x000000000058aa0b in Ffuncall (nargs=1, args=0x7ffc4ffab420) at eval.c:3068
#20 0x00007f9e6717411c in F636f6d702d66696e616c_comp_final_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#21 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffab598) at eval.c:3068
#22 0x00007f9e67177e1a in F636f6d702d2d6e61746976652d636f6d70696c65_comp__native_compile_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#23 0x000000000058aa0b in Ffuncall (nargs=4, args=0x7ffc4ffab6a8) at eval.c:3068
#24 0x00007f9e6717555d in F636f6d702d7472616d706f6c696e652d636f6d70696c65_comp_trampoline_compile_0 ()
    at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#25 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffab790) at eval.c:3068
#26 0x00007f9e67121a0a in F636f6d702d737562722d7472616d706f6c696e652d696e7374616c6c_comp_subr_trampoline_install_0 ()
    at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#27 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffab8d0) at eval.c:3068
#28 0x00007f9e67ea855f in F6164766963652d2d6164642d66756e6374696f6e_advice__add_function_0 ()
    at /home/rpluim/repos/emacs-3/src/../native-lisp/29.0.50-22b306c1/preloaded/nadvice-64630aaa-4c5c4a90.eln
#29 0x000000000058aa0b in Ffuncall (nargs=5, args=0x7ffc4ffabac0) at eval.c:3068
#30 0x00007f9e67ea9ba0 in F6164766963652d616464_advice_add_0 () at /home/rpluim/repos/emacs-3/src/../native-lisp/29.0.50-22b306c1/preloaded/nadvice-64630aaa-4c5c4a90.eln
#31 0x000000000058aa0b in Ffuncall (nargs=4, args=args@entry=0x7ffc4ffabbc8) at eval.c:3068
#32 0x00000000005c5ec0 in exec_byte_code
    (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#33 0x000000000058ce72 in eval_sub (form=<optimized out>) at eval.c:2549
#34 0x000000000058ea19 in Feval (form=XIL(0x226a553), lexical=<optimized out>) at eval.c:2372
#35 0x00007f9e66f0045a in top_level_run () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/transient-376febf1-23039d56.eln
#36 0x00000000005d0747 in load_comp_unit (comp_u=0x222dbd0, loading_dump=<optimized out>, late_load=<optimized out>) at comp.c:5093
#37 0x00000000005d0bba in Fnative_elisp_load (filename=XIL(0x2202c74), late_load=late_load@entry=XIL(0)) at comp.c:5309
#38 0x00000000005b41b0 in Fload (file=<optimized out>, noerror=<optimized out>, nomessage=XIL(0x30), nosuffix=<optimized out>, must_suffix=<optimized out>) at lread.c:1564
#39 0x00000000005b471a in save_match_data_load
    (file=file@entry=XIL(0x2202604), noerror=noerror@entry=XIL(0), nomessage=nomessage@entry=XIL(0x30), nosuffix=nosuffix@entry=XIL(0), must_suffix=must_suffix@entry=XIL(0x30))
    at lread.c:1628
#40 0x0000000000599eeb in Frequire (feature=XIL(0x17c1760), filename=<optimized out>, noerror=XIL(0)) at fns.c:3188
#41 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffac350) at eval.c:3068
#42 0x000000000058c7a3 in Fapply (nargs=2, args=0x7ffc4ffac350) at eval.c:2655
#43 0x00007f9e670c095e in F627974652d636f6d70696c652d66696c652d666f726d2d72657175697265_byte_compile_file_form_require_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/bytecomp-12882072-c5edfb79.eln
#44 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffac430) at eval.c:3068
#45 0x00007f9e670bfa7a in F627974652d636f6d70696c652d66696c652d666f726d_byte_compile_file_form_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/bytecomp-12882072-c5edfb79.eln
#46 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffac4e0) at eval.c:3068
#47 0x00007f9e670bf993 in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_49 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/bytecomp-12882072-c5edfb79.eln
#48 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffac590) at eval.c:3068
#49 0x00007f9e670b0fc7 in F627974652d636f6d70696c652d726563757273652d746f706c6576656c_byte_compile_recurse_toplevel_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/bytecomp-12882072-c5edfb79.eln
#50 0x000000000058aa0b in Ffuncall (nargs=3, args=0x7ffc4ffac650) at eval.c:3068
#51 0x00007f9e670bf9f6 in F627974652d636f6d70696c652d746f706c6576656c2d66696c652d666f726d_byte_compile_toplevel_file_form_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/bytecomp-12882072-c5edfb79.eln
#52 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffac710) at eval.c:3068
#53 0x00007f9e670bd91f in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_47 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/bytecomp-12882072-c5edfb79.eln
#54 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffac828) at eval.c:3068
#55 0x00007f9e670be11d in F627974652d636f6d70696c652d66726f6d2d627566666572_byte_compile_from_buffer_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/bytecomp-12882072-c5edfb79.eln
#56 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffac990) at eval.c:3068
#57 0x00007f9e670bc066 in F627974652d636f6d70696c652d66696c65_byte_compile_file_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/bytecomp-12882072-c5edfb79.eln
#58 0x000000000058aa0b in Ffuncall (nargs=2, args=args@entry=0x7ffc4ffaca80) at eval.c:3068
#59 0x00000000005c5ec0 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#60 0x000000000058a8ad in Ffuncall (nargs=2, args=0x7ffc4ffacfc0) at eval.c:3084
#61 0x000000000058c760 in Fapply (nargs=3, args=0x7ffc4ffacfc0) at eval.c:2651
#62 0x000000000058aa0b in Ffuncall (nargs=4, args=args@entry=0x7ffc4ffacfb8) at eval.c:3068
#63 0x00000000005c5ec0 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#64 0x000000000058a8ad in Ffuncall (nargs=2, args=0x7ffc4ffad2f0) at eval.c:3084
#65 0x00007f9e6713ec0a in F636f6d702d7370696c6c2d6c6170_comp_spill_lap_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#66 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffad3e8) at eval.c:3068
#67 0x00007f9e67177e1a in F636f6d702d2d6e61746976652d636f6d70696c65_comp__native_compile_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#68 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffad4e0) at eval.c:3068
#69 0x00007f9e671791e0 in F62617463682d6e61746976652d636f6d70696c65_batch_native_compile_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#70 0x000000000058aa0b in Ffuncall (nargs=1, args=0x7ffc4ffad5e8) at eval.c:3068
#71 0x00007f9e67179360 in F62617463682d627974652b6e61746976652d636f6d70696c65_batch_bytenative_compile_0 () at /home/rpluim/repos/emacs-3/native-lisp/29.0.50-22b306c1/comp-7672a6ed-a040a5e7.eln
#72 0x000000000058aa0b in Ffuncall (nargs=1, args=0x7ffc4ffad738) at eval.c:3068
#73 0x00007f9e67f6552b in F636f6d6d616e642d6c696e652d31_command_line_1_0 () at /home/rpluim/repos/emacs-3/src/../native-lisp/29.0.50-22b306c1/preloaded/startup-bbc6ea72-1e61e581.eln
#74 0x000000000058aa0b in Ffuncall (nargs=2, args=0x7ffc4ffada40) at eval.c:3068
#75 0x00007f9e67f5d2d0 in F636f6d6d616e642d6c696e65_command_line_0 () at /home/rpluim/repos/emacs-3/src/../native-lisp/29.0.50-22b306c1/preloaded/startup-bbc6ea72-1e61e581.eln
#76 0x000000000058aa0b in Ffuncall (nargs=1, args=0x7ffc4ffadb48) at eval.c:3068
#77 0x00007f9e67f59354 in F6e6f726d616c2d746f702d6c6576656c_normal_top_level_0 () at /home/rpluim/repos/emacs-3/src/../native-lisp/29.0.50-22b306c1/preloaded/startup-bbc6ea72-1e61e581.eln
#78 0x000000000058cef6 in eval_sub (form=<optimized out>) at eval.c:2540
#79 0x000000000058ea19 in Feval (form=XIL(0x7f9e689e0feb), lexical=<optimized out>) at eval.c:2372
#80 0x00000000005899a7 in internal_condition_case (bfun=bfun@entry=0x50f200 <top_level_2>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x514da0 <cmd_error>) at eval.c:1495
#81 0x000000000050fe52 in top_level_1 (ignore=ignore@entry=XIL(0)) at keyboard.c:1151
#82 0x0000000000589901 in internal_catch (tag=tag@entry=XIL(0xe9d0), func=func@entry=0x50fe30 <top_level_1>, arg=arg@entry=XIL(0)) at eval.c:1226
#83 0x000000000050f17b in command_loop () at keyboard.c:1111
#84 0x000000000051499c in recursive_edit_1 () at keyboard.c:721
#85 0x0000000000514ce3 in Frecursive_edit () at keyboard.c:804
#86 0x000000000042c8cf in main (argc=11, argv=<optimized out>) at emacs.c:2376
You can't do that without a process to debug.


Robert
-- 

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

On Nov 22 2021, Eli Zaretskii wrote:

> Can you produce a reproducer for Andrea to analyze?  (How to do that
> is explained in etc/DEBUG; search for "reproducer".)

That doesn't work.

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

[-- Attachment #1: Type: text/plain, Size: 214 bytes --]

Actually there is a repro.c in eln-cache.

Andreas.

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

[-- Attachment #2: subr--trampoline-61626f72742d7265637572736976652d65646974_abort_recursive_edit_0_libgccjit_repro.c.xz --]
[-- Type: application/x-xz, Size: 98952 bytes --]

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 51688@debbugs.gnu.org,  Andreas Schwab <schwab@linux-m68k.org>, Eli
>  Zaretskii <eliz@gnu.org>
> Date: Tue, 23 Nov 2021 09:44:01 +0100
> 
> >>>>> On Mon, 22 Nov 2021 15:55:57 +0100, Robert Pluim <rpluim@gmail.com> said:
> 
>     Robert> Iʼve seen this crash *once* in my Tumbleweed VM, which unfortunately
>     Robert> had core dumps disabled. Iʼve not seen it since enabling core
>     Robert> dumps. Iʼll see what happens if I uses Andreas' configure options.
> 
> So this only seems to happen in a clean checkout, and I suspect I need
> to remove ~/.emacs.d/eln-cache as well.

Can you produce a reproducer and post it?  See etc/DEBUG for how to do
that.

Thanks.

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: akrl@sdf.org,  51688@debbugs.gnu.org
> Date: Tue, 23 Nov 2021 12:36:54 +0100
> 
> Actually there is a repro.c in eln-cache.

Thanks, I updated etc/DEBUG with this possibility.

Andrea, can you tell when the reproducer will be written as literally
"repro.c" in the eln-cache directory?  If possible, I'd like to
describe such a situation as accurate as I can, so that users won't
have to search high and low for the file.

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> Date: Tue, 23 Nov 2021 14:56:44 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 51688@debbugs.gnu.org, akrl@sdf.org
> 
> > From: Andreas Schwab <schwab@linux-m68k.org>
> > Cc: akrl@sdf.org,  51688@debbugs.gnu.org
> > Date: Tue, 23 Nov 2021 12:36:54 +0100
> > 
> > Actually there is a repro.c in eln-cache.
> 
> Thanks, I updated etc/DEBUG with this possibility.
> 
> Andrea, can you tell when the reproducer will be written as literally
> "repro.c" in the eln-cache directory?

Or maybe I misunderstood what Andreas wrote, and the file's name was
the expected one, just the directory not the expected one?

bug#51688: ELC+ELN international/emoji.elc crashes

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

>>>>> On Tue, 23 Nov 2021 14:42:11 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: 51688@debbugs.gnu.org,  Andreas Schwab <schwab@linux-m68k.org>, Eli
    >> Zaretskii <eliz@gnu.org>
    >> Date: Tue, 23 Nov 2021 09:44:01 +0100
    >> 
    >> >>>>> On Mon, 22 Nov 2021 15:55:57 +0100, Robert Pluim <rpluim@gmail.com> said:
    >> 
    Robert> Iʼve seen this crash *once* in my Tumbleweed VM, which unfortunately
    Robert> had core dumps disabled. Iʼve not seen it since enabling core
    Robert> dumps. Iʼll see what happens if I uses Andreas' configure options.
    >> 
    >> So this only seems to happen in a clean checkout, and I suspect I need
    >> to remove ~/.emacs.d/eln-cache as well.

    Eli> Can you produce a reproducer and post it?  See etc/DEBUG for how to do
    Eli> that.

Attached (itʼs rather large). Note that running 'NATIVE_FULL_AOT=1
make' again, lisp/international/emoji.el is successfully compiled, so
Iʼm not 100% sure that the repro file will cause a crash.


[-- Attachment #2: emoji-aca2d225-0997194d_libgccjit_repro.c.gz --]
[-- Type: application/gzip, Size: 284633 bytes --]

[-- Attachment #3: Type: text/plain, Size: 12 bytes --]


Robert
-- 

bug#51688: ELC+ELN international/emoji.elc crashes

[Robert Pluim]

>>>>> On Tue, 23 Nov 2021 14:56:44 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Andreas Schwab <schwab@linux-m68k.org>
    >> Cc: akrl@sdf.org,  51688@debbugs.gnu.org
    >> Date: Tue, 23 Nov 2021 12:36:54 +0100
    >> 
    >> Actually there is a repro.c in eln-cache.

    Eli> Thanks, I updated etc/DEBUG with this possibility.

    Eli> Andrea, can you tell when the reproducer will be written as literally
    Eli> "repro.c" in the eln-cache directory?  If possible, I'd like to
    Eli> describe such a situation as accurate as I can, so that users won't
    Eli> have to search high and low for the file.

Strange. Mine ended up in "<path-to-emacs-src>/native-lisp/29.0.50-04b8e366"

Robert
-- 

bug#51688: ELC+ELN international/emoji.elc crashes

[Robert Pluim]

>>>>> On Tue, 23 Nov 2021 14:18:45 +0100, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Tue, 23 Nov 2021 14:42:11 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >>> From: Robert Pluim <rpluim@gmail.com>
    >>> Cc: 51688@debbugs.gnu.org,  Andreas Schwab <schwab@linux-m68k.org>, Eli
    >>> Zaretskii <eliz@gnu.org>
    >>> Date: Tue, 23 Nov 2021 09:44:01 +0100
    >>> 
    >>> >>>>> On Mon, 22 Nov 2021 15:55:57 +0100, Robert Pluim <rpluim@gmail.com> said:
    >>> 
    Robert> Iʼve seen this crash *once* in my Tumbleweed VM, which unfortunately
    Robert> had core dumps disabled. Iʼve not seen it since enabling core
    Robert> dumps. Iʼll see what happens if I uses Andreas' configure options.
    >>> 
    >>> So this only seems to happen in a clean checkout, and I suspect I need
    >>> to remove ~/.emacs.d/eln-cache as well.

    Eli> Can you produce a reproducer and post it?  See etc/DEBUG for how to do
    Eli> that.

    Robert> Attached (itʼs rather large). Note that running 'NATIVE_FULL_AOT=1
    Robert> make' again, lisp/international/emoji.el is successfully compiled, so
    Robert> Iʼm not 100% sure that the repro file will cause a crash.

In fact, ignore this one. Andreas' is correct. For anyone wanting to
reproduce this, after itʼs crashed the first time:

- rm lisp/international/emoji.elc
- rm ~/.emacs.d/eln-cache/29.0.50-whatever/*.eln*
- run with comp-libgccjit-reproducer set to t

So I can now reliably reproduce it if anything more is needed (without
rebuilding a whole checkout).

Robert
-- 

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 51688@debbugs.gnu.org,  schwab@linux-m68k.org,  akrl@sdf.org
> Date: Tue, 23 Nov 2021 15:03:07 +0100
> 
> - rm lisp/international/emoji.elc
> - rm ~/.emacs.d/eln-cache/29.0.50-whatever/*.eln*
> - run with comp-libgccjit-reproducer set to t

Where does this write the reproducer file, and under what name?  I'd
like to make sure the etc/DEBUG text is accurate.

bug#51688: ELC+ELN international/emoji.elc crashes

[Robert Pluim]

>>>>> On Tue, 23 Nov 2021 16:11:52 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: 51688@debbugs.gnu.org,  schwab@linux-m68k.org,  akrl@sdf.org
    >> Date: Tue, 23 Nov 2021 15:03:07 +0100
    >> 
    >> - rm lisp/international/emoji.elc
    >> - rm ~/.emacs.d/eln-cache/29.0.50-whatever/*.eln*
    >> - run with comp-libgccjit-reproducer set to t

    Eli> Where does this write the reproducer file, and under what name?  I'd
    Eli> like to make sure the etc/DEBUG text is accurate.

    $ ls ~/.emacs.d/eln-cache/29.0.50-04b8e366/
    subr--trampoline-61626f72742d7265637572736976652d65646974_abort_recursive_edit_0.eln
    subr--trampoline-61626f72742d7265637572736976652d65646974_abort_recursive_edit_0_libgccjit_repro.c
    subr--trampoline-746f702d6c6576656c_top_level_052OgiY.eln.tmp
    subr--trampoline-746f702d6c6576656c_top_level_0_libgccjit_repro.c

Robert
-- 

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 51688@debbugs.gnu.org,  schwab@linux-m68k.org,  akrl@sdf.org
> Date: Tue, 23 Nov 2021 15:15:27 +0100
> 
>     $ ls ~/.emacs.d/eln-cache/29.0.50-04b8e366/
>     subr--trampoline-61626f72742d7265637572736976652d65646974_abort_recursive_edit_0.eln
>     subr--trampoline-61626f72742d7265637572736976652d65646974_abort_recursive_edit_0_libgccjit_repro.c
>     subr--trampoline-746f702d6c6576656c_top_level_052OgiY.eln.tmp
>     subr--trampoline-746f702d6c6576656c_top_level_0_libgccjit_repro.c

Thanks.  I guess these end up in eln-cache because of NATIVE_FULL_AOT=1?

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: akrl@sdf.org,  51688@debbugs.gnu.org
>> Date: Tue, 23 Nov 2021 12:36:54 +0100
>> 
>> Actually there is a repro.c in eln-cache.
>
> Thanks, I updated etc/DEBUG with this possibility.
>
> Andrea, can you tell when the reproducer will be written as literally
> "repro.c" in the eln-cache directory?  If possible, I'd like to
> describe such a situation as accurate as I can, so that users won't
> have to search high and low for the file.

The reproducer should be named XXX_libgccjit_repro.c where XXX is the
base name of the corresponding .eln.  Also it should be produced in the
same directory where the .eln goes.

So I think the previous wording in etc/DEBUG was more accurate.  If we
are building Emacs the reproducer should be deposed under the
native-lisp/whatever/ directory.

Regards

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 23 Nov 2021 14:42:11 +0200, Eli Zaretskii <eliz@gnu.org> said:
>
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Cc: 51688@debbugs.gnu.org,  Andreas Schwab <schwab@linux-m68k.org>, Eli
>     >> Zaretskii <eliz@gnu.org>
>     >> Date: Tue, 23 Nov 2021 09:44:01 +0100
>     >> 
>     >> >>>>> On Mon, 22 Nov 2021 15:55:57 +0100, Robert Pluim <rpluim@gmail.com> said:
>     >> 
>     Robert> Iʼve seen this crash *once* in my Tumbleweed VM, which unfortunately
>     Robert> had core dumps disabled. Iʼve not seen it since enabling core
>     Robert> dumps. Iʼll see what happens if I uses Andreas' configure options.
>     >> 
>     >> So this only seems to happen in a clean checkout, and I suspect I need
>     >> to remove ~/.emacs.d/eln-cache as well.
>
>     Eli> Can you produce a reproducer and post it?  See etc/DEBUG for how to do
>     Eli> that.
>
> Attached (itʼs rather large). Note that running 'NATIVE_FULL_AOT=1
> make' again, lisp/international/emoji.el is successfully compiled, so
> Iʼm not 100% sure that the repro file will cause a crash.
>

Could you verify if you can produce the libgccjit crash using the
produced reproducer?

You should just compile it with like

$ gcc emoji-aca2d225-0997194d_libgccjit_repro.c -lgccjit

And run it to see if it crashes.

$ ./a.out

Thanks

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Robert Pluim]

>>>>> On Tue, 23 Nov 2021 14:34:45 +0000, Andrea Corallo <akrl@sdf.org> said:

    Andrea> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Tue, 23 Nov 2021 14:42:11 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >> 
    >> >> From: Robert Pluim <rpluim@gmail.com>
    >> >> Cc: 51688@debbugs.gnu.org,  Andreas Schwab <schwab@linux-m68k.org>, Eli
    >> >> Zaretskii <eliz@gnu.org>
    >> >> Date: Tue, 23 Nov 2021 09:44:01 +0100
    >> >> 
    >> >> >>>>> On Mon, 22 Nov 2021 15:55:57 +0100, Robert Pluim <rpluim@gmail.com> said:
    >> >> 
    Robert> Iʼve seen this crash *once* in my Tumbleweed VM, which unfortunately
    Robert> had core dumps disabled. Iʼve not seen it since enabling core
    Robert> dumps. Iʼll see what happens if I uses Andreas' configure options.
    >> >> 
    >> >> So this only seems to happen in a clean checkout, and I suspect I need
    >> >> to remove ~/.emacs.d/eln-cache as well.
    >> 
    Eli> Can you produce a reproducer and post it?  See etc/DEBUG for how to do
    Eli> that.
    >> 
    >> Attached (itʼs rather large). Note that running 'NATIVE_FULL_AOT=1
    >> make' again, lisp/international/emoji.el is successfully compiled, so
    >> Iʼm not 100% sure that the repro file will cause a crash.
    >> 

    Andrea> Could you verify if you can produce the libgccjit crash using the
    Andrea> produced reproducer?

    Andrea> You should just compile it with like

    Andrea> $ gcc emoji-aca2d225-0997194d_libgccjit_repro.c -lgccjit

    Andrea> And run it to see if it crashes.

    Andrea> $ ./a.out

No, that doesnʼt crash. And similarly for the .c files in
.emacs.d/eln-cache, they donʼt crash.

Robert
-- 

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 23 Nov 2021 14:34:45 +0000, Andrea Corallo <akrl@sdf.org> said:
>
>     Andrea> Robert Pluim <rpluim@gmail.com> writes:
>     >>>>>>> On Tue, 23 Nov 2021 14:42:11 +0200, Eli Zaretskii <eliz@gnu.org> said:
>     >> 
>     >> >> From: Robert Pluim <rpluim@gmail.com>
>     >> >> Cc: 51688@debbugs.gnu.org,  Andreas Schwab <schwab@linux-m68k.org>, Eli
>     >> >> Zaretskii <eliz@gnu.org>
>     >> >> Date: Tue, 23 Nov 2021 09:44:01 +0100
>     >> >> 
>     >> >> >>>>> On Mon, 22 Nov 2021 15:55:57 +0100, Robert Pluim <rpluim@gmail.com> said:
>     >> >> 
>     Robert> Iʼve seen this crash *once* in my Tumbleweed VM, which unfortunately
>     Robert> had core dumps disabled. Iʼve not seen it since enabling core
>     Robert> dumps. Iʼll see what happens if I uses Andreas' configure options.
>     >> >> 
>     >> >> So this only seems to happen in a clean checkout, and I suspect I need
>     >> >> to remove ~/.emacs.d/eln-cache as well.
>     >> 
>     Eli> Can you produce a reproducer and post it?  See etc/DEBUG for how to do
>     Eli> that.
>     >> 
>     >> Attached (itʼs rather large). Note that running 'NATIVE_FULL_AOT=1
>     >> make' again, lisp/international/emoji.el is successfully compiled, so
>     >> Iʼm not 100% sure that the repro file will cause a crash.
>     >> 
>
>     Andrea> Could you verify if you can produce the libgccjit crash using the
>     Andrea> produced reproducer?
>
>     Andrea> You should just compile it with like
>
>     Andrea> $ gcc emoji-aca2d225-0997194d_libgccjit_repro.c -lgccjit
>
>     Andrea> And run it to see if it crashes.
>
>     Andrea> $ ./a.out
>
> No, that doesnʼt crash. And similarly for the .c files in
> .emacs.d/eln-cache, they donʼt crash.

To be sure, was the .c file produced when Emacs crashed?

Thanks

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Robert Pluim]

>>>>> On Tue, 23 Nov 2021 14:46:55 +0000, Andrea Corallo <akrl@sdf.org> said:

    Andrea> $ gcc emoji-aca2d225-0997194d_libgccjit_repro.c -lgccjit
    >> 
    Andrea> And run it to see if it crashes.
    >> 
    Andrea> $ ./a.out
    >> 
    >> No, that doesnʼt crash. And similarly for the .c files in
    >> .emacs.d/eln-cache, they donʼt crash.

    Andrea> To be sure, was the .c file produced when Emacs crashed?

Not quite, it was produced when I reran the compile but with the
comp-libgccjit-reproducer set to t. The crash doesnʼt always happen
the second time.

But I have a live emacs process thatʼs just crashed (the first time)
trapped in gdb if you want me to poke at it.

#0  0x00007ffff4fc4231 in  () at /lib64/libgccjit.so.0
#1  0x00007ffff4fc9809 in  () at /lib64/libgccjit.so.0
#2  0x00007ffff4fea69f in  () at /lib64/libgccjit.so.0
#3  0x00007ffff4e7ba92 in  () at /lib64/libgccjit.so.0
#4  0x00007ffff500c1f2 in  () at /lib64/libgccjit.so.0
#5  0x00007ffff4fe7cd5 in gcc_jit_context_compile_to_file () at /lib64/libgccjit.so.0
#6  0x0000000000692cd6 in Fcomp__compile_ctxt_to_file (filename=0x1260834) at comp.c:4652
#7  0x000000000063a3a8 in funcall_subr (subr=0xb00fe0 <Scomp__compile_ctxt_to_file>, numargs=1, args=0x7fffffff9918) at eval.c:3143
#8  0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffff9910) at eval.c:3068
#9  0x00007ffff0a64cda in F636f6d702d636f6d70696c652d637478742d746f2d66696c65_comp_compile_ctxt_to_file_0 ()
    at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#10 0x000000000063a3a8 in funcall_subr (subr=0xe94bd0, numargs=1, args=0x7fffffff9a78) at eval.c:3143
#11 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffff9a70) at eval.c:3068
#12 0x00007ffff0a64ec5 in F636f6d702d66696e616c31_comp_final1_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#13 0x000000000063a38f in funcall_subr (subr=0xe94c20, numargs=0, args=0x7fffffff9ce8) at eval.c:3141
#14 0x0000000000639fc2 in Ffuncall (nargs=1, args=0x7fffffff9ce0) at eval.c:3068
#15 0x00007ffff0a6511c in F636f6d702d66696e616c_comp_final_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#16 0x000000000063a3a8 in funcall_subr (subr=0xe94c70, numargs=1, args=0x7fffffff9f00) at eval.c:3143
#17 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffff9ef8) at eval.c:3068
#18 0x00007ffff0a68e1a in F636f6d702d2d6e61746976652d636f6d70696c65_comp__native_compile_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#19 0x000000000063a402 in funcall_subr (subr=0xe95150, numargs=3, args=0x7fffffffa0b0) at eval.c:3148
#20 0x0000000000639fc2 in Ffuncall (nargs=4, args=0x7fffffffa0a8) at eval.c:3068
#21 0x00007ffff0a6655d in F636f6d702d7472616d706f6c696e652d636f6d70696c65_comp_trampoline_compile_0 ()
    at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#22 0x000000000063a3a8 in funcall_subr (subr=0xe94ea0, numargs=1, args=0x7fffffffa238) at eval.c:3143
#23 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffa230) at eval.c:3068
#24 0x00007ffff0a12a0a in F636f6d702d737562722d7472616d706f6c696e652d696e7374616c6c_comp_subr_trampoline_install_0 ()
    at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#25 0x000000000063a3a8 in funcall_subr (subr=0xfca3a0, numargs=1, args=0x7fffffffa418) at eval.c:3143
#26 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffa410) at eval.c:3068
#27 0x00007ffff179955f in F6164766963652d2d6164642d66756e6374696f6e_advice__add_function_0 ()
    at /home/rpluim/repos/emacs-4/src/../native-lisp/29.0.50-04b8e366/preloaded/nadvice-64630aaa-4c5c4a90.eln
#28 0x000000000063a43d in funcall_subr (subr=0x7ffff225a8c0, numargs=4, args=0x7fffffffa6a8) at eval.c:3151
#29 0x0000000000639fc2 in Ffuncall (nargs=5, args=0x7fffffffa6a0) at eval.c:3068
#30 0x00007ffff179aba0 in F6164766963652d616464_advice_add_0 () at /home/rpluim/repos/emacs-4/src/../native-lisp/29.0.50-04b8e366/preloaded/nadvice-64630aaa-4c5c4a90.eln
#31 0x000000000063a43d in funcall_subr (subr=0x7ffff1fcd7f8, numargs=3, args=0x7fffffffa850) at eval.c:3151
#32 0x0000000000639fc2 in Ffuncall (nargs=4, args=0x7fffffffa848) at eval.c:3068
#33 0x0000000000685feb in exec_byte_code (bytestr=0x105bad4, vector=0x105abfd, maxdepth=0x12, args_template=0x0, nargs=0, args=0x0) at bytecode.c:632
#34 0x0000000000685556 in Fbyte_code (bytestr=0x105bad4, vector=0x105abfd, maxdepth=0x12) at bytecode.c:334
#35 0x0000000000638a28 in eval_sub (form=0x104e313) at eval.c:2549
#36 0x0000000000638115 in Feval (form=0x104e313, lexical=0x30) at eval.c:2372
#37 0x00007ffff07f145a in top_level_run () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/transient-376febf1-23039d56.eln
#38 0x0000000000693c1a in load_comp_unit (comp_u=0x10103c0, loading_dump=false, late_load=false) at comp.c:5093
#39 0x000000000069473b in Fnative_elisp_load (filename=0xfe51a4, late_load=0x0) at comp.c:5309
#40 0x000000000066cda6 in Fload (file=0x100e344, noerror=0x0, nomessage=0x30, nosuffix=0x0, must_suffix=0x30) at lread.c:1564
#41 0x000000000066d0e4 in save_match_data_load (file=0x100e344, noerror=0x0, nomessage=0x30, nosuffix=0x0, must_suffix=0x30) at lread.c:1628
#42 0x0000000000649046 in Frequire (feature=0x489f90 <Fcurrent_bidi_paragraph_direction+854>, filename=0x0, noerror=0x0) at fns.c:3188
#43 0x000000000063a402 in funcall_subr (subr=0xafe3a0 <Srequire>, numargs=1, args=0x7fffffffb418) at eval.c:3148
#44 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffb410) at eval.c:3068
#45 0x0000000000638f75 in Fapply (nargs=2, args=0x7fffffffb410) at eval.c:2655
#46 0x00007ffff09b195e in F627974652d636f6d70696c652d66696c652d666f726d2d72657175697265_byte_compile_file_form_require_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/bytecomp-12882072-c5edfb79.eln
#47 0x000000000063a3a8 in funcall_subr (subr=0xc90de0, numargs=1, args=0x7fffffffb598) at eval.c:3143
#48 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffb590) at eval.c:3068
#49 0x00007ffff09b0a7a in F627974652d636f6d70696c652d66696c652d666f726d_byte_compile_file_form_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/bytecomp-12882072-c5edfb79.eln
#50 0x000000000063a3a8 in funcall_subr (subr=0xc90bb0, numargs=1, args=0x7fffffffb6e8) at eval.c:3143
#51 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffb6e0) at eval.c:3068
#52 0x00007ffff09b0993 in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_49 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/bytecomp-12882072-c5edfb79.eln
#53 0x000000000063a3a8 in funcall_subr (subr=0xc19ad8, numargs=1, args=0x7fffffffb838) at eval.c:3143
#54 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffb830) at eval.c:3068
#55 0x00007ffff09a1fc7 in F627974652d636f6d70696c652d726563757273652d746f706c6576656c_byte_compile_recurse_toplevel_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/bytecomp-12882072-c5edfb79.eln
#56 0x000000000063a3cf in funcall_subr (subr=0xc888b0, numargs=2, args=0x7fffffffb998) at eval.c:3145
#57 0x0000000000639fc2 in Ffuncall (nargs=3, args=0x7fffffffb990) at eval.c:3068
#58 0x00007ffff09b09f6 in F627974652d636f6d70696c652d746f706c6576656c2d66696c652d666f726d_byte_compile_toplevel_file_form_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/bytecomp-12882072-c5edfb79.eln
#59 0x000000000063a3a8 in funcall_subr (subr=0xbf9ed0, numargs=1, args=0x7fffffffbaf8) at eval.c:3143
#60 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffbaf0) at eval.c:3068
#61 0x00007ffff09ae91f in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_47 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/bytecomp-12882072-c5edfb79.eln
#62 0x000000000063a3a8 in funcall_subr (subr=0xc19a38, numargs=1, args=0x7fffffffbcb0) at eval.c:3143
#63 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffbca8) at eval.c:3068
#64 0x00007ffff09af11d in F627974652d636f6d70696c652d66726f6d2d627566666572_byte_compile_from_buffer_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/bytecomp-12882072-c5edfb79.eln
#65 0x000000000063a3a8 in funcall_subr (subr=0xbf9ca0, numargs=1, args=0x7fffffffbeb8) at eval.c:3143
#66 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffbeb0) at eval.c:3068
#67 0x00007ffff09ad066 in F627974652d636f6d70696c652d66696c65_byte_compile_file_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/bytecomp-12882072-c5edfb79.eln
#68 0x000000000063a3cf in funcall_subr (subr=0xbf9c00, numargs=1, args=0x7fffffffc048) at eval.c:3145
#69 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffc040) at eval.c:3068
#70 0x0000000000685feb in exec_byte_code (bytestr=0xd26d84, vector=0xc6b685, maxdepth=0x42, args_template=0x406, nargs=1, args=0x7fffffffc850) at bytecode.c:632
#71 0x000000000063a65b in fetch_and_exec_byte_code (fun=0xc5741d, syms_left=0x406, nargs=1, args=0x7fffffffc848) at eval.c:3192
#72 0x000000000063a9e8 in funcall_lambda (fun=0xc5741d, nargs=1, arg_vector=0x7fffffffc848) at eval.c:3273
#73 0x000000000063a016 in Ffuncall (nargs=2, args=0x7fffffffc840) at eval.c:3072
#74 0x0000000000638f35 in Fapply (nargs=3, args=0x7fffffffc840) at eval.c:2651
#75 0x000000000063a2e4 in funcall_subr (subr=0xafbbe0 <Sapply>, numargs=3, args=0x7fffffffc840) at eval.c:3123
#76 0x0000000000639fc2 in Ffuncall (nargs=4, args=0x7fffffffc838) at eval.c:3068
#77 0x0000000000685feb in exec_byte_code (bytestr=0x7ffff24179ac, vector=0xeda71d, maxdepth=0x3a, args_template=0x606, nargs=1, args=0x7fffffffcd80) at bytecode.c:632
#78 0x000000000063a65b in fetch_and_exec_byte_code (fun=0xfa17e5, syms_left=0x606, nargs=1, args=0x7fffffffcd78) at eval.c:3192
#79 0x000000000063a9e8 in funcall_lambda (fun=0xfa17e5, nargs=1, arg_vector=0x7fffffffcd78) at eval.c:3273
#80 0x000000000063a016 in Ffuncall (nargs=2, args=0x7fffffffcd70) at eval.c:3072
#81 0x00007ffff0a2fc0a in F636f6d702d7370696c6c2d6c6170_comp_spill_lap_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#82 0x000000000063a3a8 in funcall_subr (subr=0xfb2ea0, numargs=1, args=0x7fffffffcf10) at eval.c:3143
#83 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffcf08) at eval.c:3068
#84 0x00007ffff0a68e1a in F636f6d702d2d6e61746976652d636f6d70696c65_comp__native_compile_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#85 0x000000000063a402 in funcall_subr (subr=0xe95150, numargs=1, args=0x7fffffffd0a8) at eval.c:3148
#86 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffd0a0) at eval.c:3068
#87 0x00007ffff0a6a1e0 in F62617463682d6e61746976652d636f6d70696c65_batch_native_compile_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#88 0x000000000063a3a8 in funcall_subr (subr=0xf24d60, numargs=0, args=0x7fffffffd250) at eval.c:3143
#89 0x0000000000639fc2 in Ffuncall (nargs=1, args=0x7fffffffd248) at eval.c:3068
#90 0x00007ffff0a6a360 in F62617463682d627974652b6e61746976652d636f6d70696c65_batch_bytenative_compile_0 () at /home/rpluim/repos/emacs-4/native-lisp/29.0.50-04b8e366/comp-7672a6ed-a040a5e7.eln
#91 0x000000000063a38f in funcall_subr (subr=0xf24db0, numargs=0, args=0x7fffffffd440) at eval.c:3141
#92 0x0000000000639fc2 in Ffuncall (nargs=1, args=0x7fffffffd438) at eval.c:3068
#93 0x00007ffff185652b in F636f6d6d616e642d6c696e652d31_command_line_1_0 () at /home/rpluim/repos/emacs-4/src/../native-lisp/29.0.50-04b8e366/preloaded/startup-bbc6ea72-1e61e581.eln
#94 0x000000000063a3a8 in funcall_subr (subr=0x7ffff22d8c78, numargs=1, args=0x7fffffffd7e8) at eval.c:3143
#95 0x0000000000639fc2 in Ffuncall (nargs=2, args=0x7fffffffd7e0) at eval.c:3068
#96 0x00007ffff184e2d0 in F636f6d6d616e642d6c696e65_command_line_0 () at /home/rpluim/repos/emacs-4/src/../native-lisp/29.0.50-04b8e366/preloaded/startup-bbc6ea72-1e61e581.eln
#97 0x000000000063a38f in funcall_subr (subr=0x7ffff22da5e0, numargs=0, args=0x7fffffffd990) at eval.c:3141
#98 0x0000000000639fc2 in Ffuncall (nargs=1, args=0x7fffffffd988) at eval.c:3068
#99 0x00007ffff184a354 in F6e6f726d616c2d746f702d6c6576656c_normal_top_level_0 () at /home/rpluim/repos/emacs-4/src/../native-lisp/29.0.50-04b8e366/preloaded/startup-bbc6ea72-1e61e581.eln
#100 0x000000000063899d in eval_sub (form=0x7ffff22d1feb) at eval.c:2540
#101 0x0000000000638115 in Feval (form=0x7ffff22d1feb, lexical=0x0) at eval.c:2372
#102 0x000000000057f95f in top_level_2 () at keyboard.c:1143
#103 0x0000000000636414 in internal_condition_case (bfun=0x57f93c <top_level_2>, handlers=0x90, hfun=0x57f2bb <cmd_error>) at eval.c:1495
#104 0x000000000057f9a3 in top_level_1 (ignore=0x0) at keyboard.c:1151
#105 0x0000000000635b4a in internal_catch (tag=0xe9d0, func=0x57f961 <top_level_1>, arg=0x0) at eval.c:1226
#106 0x000000000057f896 in command_loop () at keyboard.c:1111
#107 0x000000000057ee76 in recursive_edit_1 () at keyboard.c:721
#108 0x000000000057f013 in Frecursive_edit () at keyboard.c:804
#109 0x000000000057bb08 in main (argc=11, argv=0x7fffffffdf38) at emacs.c:2376

Robert
-- 

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 23 Nov 2021 14:46:55 +0000, Andrea Corallo <akrl@sdf.org> said:
>
>     Andrea> $ gcc emoji-aca2d225-0997194d_libgccjit_repro.c -lgccjit
>     >> 
>     Andrea> And run it to see if it crashes.
>     >> 
>     Andrea> $ ./a.out
>     >> 
>     >> No, that doesnʼt crash. And similarly for the .c files in
>     >> .emacs.d/eln-cache, they donʼt crash.
>
>     Andrea> To be sure, was the .c file produced when Emacs crashed?
>
> Not quite, it was produced when I reran the compile but with the
> comp-libgccjit-reproducer set to t. The crash doesnʼt always happen
> the second time.

It's really important we make sure the reproducer is produced when Emacs
crashes.  Could you clean-up the old repro before each test so we make
sure we get a new repro that we know is correlated with the crashy run?

> But I have a live emacs process thatʼs just crashed (the first time)
> trapped in gdb if you want me to poke at it.

I think without libgccjit with debug symbols there's not much that can be
easily inferred here.

BTW which libgccjit version are you on? (looks farily recent)

Thanks

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Robert Pluim]

>>>>> On Tue, 23 Nov 2021 15:29:40 +0000, Andrea Corallo <akrl@sdf.org> said:

    Andrea> It's really important we make sure the reproducer is produced when Emacs
    Andrea> crashes.  Could you clean-up the old repro before each test so we make
    Andrea> sure we get a new repro that we know is correlated with the crashy run?

As I suspected, my reproduction was faulty. The first crash produces
these files only (and linking and running them doesnʼt crash):

~/.emacs.d/eln-cache/29.0.50-04b8e366> ls
subr--trampoline-746f702d6c6576656c_top_level_0_libgccjit_repro.c
subr--trampoline-61626f72742d7265637572736976652d65646974_abort_recursive_edit_0.eln
subr--trampoline-746f702d6c6576656c_top_level_0vRK8HA.eln.tmp
subr--trampoline-61626f72742d7265637572736976652d65646974_abort_recursive_edit_0_libgccjit_repro.c

    >> But I have a live emacs process thatʼs just crashed (the first time)
    >> trapped in gdb if you want me to poke at it.

    Andrea> I think without libgccjit with debug symbols there's not much that can be
    Andrea> easily inferred here.

Well why didnʼt you say so in the first place. Itʼs a VM, I can
install whatever I like :-)

gdb) bt
#0  vec<gcc::jit::playback::block*, va_heap, vl_ptr>::space(int) const (nelems=1, this=0x7ffff06fe778) at ../../gcc/vec.h:1467
#1  vec<gcc::jit::playback::block*, va_heap, vl_ptr>::reserve(unsigned int, bool) (nelems=1, exact=false, this=0x7ffff06fe778) at ../../gcc/vec.h:1762
#2  vec<gcc::jit::playback::block*, va_heap, vl_ptr>::safe_push(gcc::jit::playback::block* const&) (obj=<synthetic pointer>: 0x7ffff0324870, this=0x7ffff06fe778) at ../../gcc/vec.h:1887
#3  gcc::jit::playback::function::new_block(char const*) (name=<optimized out>, this=0x7ffff06fe730) at ../../gcc/jit/jit-playback.c:1565
#4  gcc::jit::recording::block::replay_into(gcc::jit::playback::context*) (this=0x11eff50) at ../../gcc/jit/jit-recording.c:4452
#5  0x00007ffff4fc9809 in gcc::jit::recording::context::replay_into(gcc::jit::playback::context*) (this=0x115b370, r=0x7fffffff92f0) at ../../gcc/jit/jit-recording.c:688
#6  0x00007ffff4fea69f in gcc::jit::playback::context::replay() (this=<optimized out>) at ../../gcc/jit/jit-playback.c:2957
#7  jit_langhook_parse_file() () at ../../gcc/jit/dummy-frontend.c:615
#8  0x00007ffff4e7ba92 in compile_file() () at ../../gcc/toplev.c:457
#9  0x00007ffff500c1f2 in do_compile () at ../../gcc/toplev.c:2201
#10 toplev::main(int, char**) (argv=<optimized out>, argc=<optimized out>, this=0x7fffffff9222) at ../../gcc/toplev.c:2340
#11 gcc::jit::playback::context::compile() (this=0x7fffffff92f0) at ../../gcc/jit/jit-playback.c:2113
#12 0x00007ffff4fe7cd5 in gcc::jit::recording::context::compile_to_file(gcc_jit_output_kind, char const*) (output_path=<optimized out>, output_kind=<optimized out>, this=<optimized out>)
    at ../../gcc/jit/jit-recording.c:1429
#13 gcc_jit_context_compile_to_file(gcc_jit_context*, gcc_jit_output_kind, char const*) (ctxt=<optimized out>, output_kind=<optimized out>, output_path=<optimized out>)
    at ../../gcc/jit/libgccjit.c:2860
#14 0x0000000000692cd6 in Fcomp__compile_ctxt_to_file (filename=0x13c1874) at comp.c:4652

    Andrea> BTW which libgccjit version are you on? (looks farily recent)

Information for package libgccjit0:
-----------------------------------
Repository     : Main Repository (OSS)
Name           : libgccjit0
Version        : 11.2.1+git610-1.15
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 23.8 MiB
Installed      : Yes (automatically)
Status         : up-to-date
Source package : gcc11-11.2.1+git610-1.15.src

Robert
-- 

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585318.html

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Andrea Corallo <akrl@sdf.org>,  Eli Zaretskii <eliz@gnu.org>,
>   51688@debbugs.gnu.org
> Date: Wed, 24 Nov 2021 10:39:46 +0100
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585318.html

Thanks.

Do you happen to know which libgccjit versions are affected by the
bug?  We could tell people to avoid them.

Or did this bug exist since day one?  (But if it's an old bug, why
doesn't everyone see these crashes?)

bug#51688: ELC+ELN international/emoji.elc crashes

[Andreas Schwab]

On Nov 24 2021, Eli Zaretskii wrote:

> Do you happen to know which libgccjit versions are affected by the
> bug?  We could tell people to avoid them.

Most likely all of them.

> Or did this bug exist since day one?  (But if it's an old bug, why
> doesn't everyone see these crashes?)

That's the effect of undefined behaviour.

Andreas.

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

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rpluim@gmail.com,  akrl@sdf.org,  51688@debbugs.gnu.org
> Date: Wed, 24 Nov 2021 14:06:04 +0100
> 
> On Nov 24 2021, Eli Zaretskii wrote:
> 
> > Do you happen to know which libgccjit versions are affected by the
> > bug?  We could tell people to avoid them.
> 
> Most likely all of them.

Too bad.

Andrea, can anything be done to work around this somehow (except to
upgrade to a later GCC)?  Or is there nothing we can do except keep
fingers crossed?

> > Or did this bug exist since day one?  (But if it's an old bug, why
> > doesn't everyone see these crashes?)
> 
> That's the effect of undefined behaviour.

You mean, undefined behavior in libgccjit's own code, right?  Or in
our code?

Thanks.

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: rpluim@gmail.com,  akrl@sdf.org,  51688@debbugs.gnu.org
>> Date: Wed, 24 Nov 2021 14:06:04 +0100
>> 
>> On Nov 24 2021, Eli Zaretskii wrote:
>> 
>> > Do you happen to know which libgccjit versions are affected by the
>> > bug?  We could tell people to avoid them.
>> 
>> Most likely all of them.
>
> Too bad.
>
> Andrea, can anything be done to work around this somehow (except to
> upgrade to a later GCC)?  Or is there nothing we can do except keep
> fingers crossed?

I don't think there's much we can do to work around this on Emacs side
(Martin please correct me if I'm wrong).

>> > Or did this bug exist since day one?  (But if it's an old bug, why
>> > doesn't everyone see these crashes?)
>> 
>> That's the effect of undefined behaviour.
>
> You mean, undefined behavior in libgccjit's own code, right?  Or in
> our code?

In libgccjit's own code.

BR

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Martin Liška]

On 11/24/21 16:14, Andrea Corallo wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: Andreas Schwab <schwab@linux-m68k.org>
>>> Cc: rpluim@gmail.com,  akrl@sdf.org,  51688@debbugs.gnu.org
>>> Date: Wed, 24 Nov 2021 14:06:04 +0100
>>>
>>> On Nov 24 2021, Eli Zaretskii wrote:
>>>
>>>> Do you happen to know which libgccjit versions are affected by the
>>>> bug?  We could tell people to avoid them.
>>>
>>> Most likely all of them.
>>
>> Too bad.
>>
>> Andrea, can anything be done to work around this somehow (except to
>> upgrade to a later GCC)?  Or is there nothing we can do except keep
>> fingers crossed?
> 
> I don't think there's much we can do to work around this on Emacs side
> (Martin please correct me if I'm wrong).

No, it's UBSAN in libgccjit library. Unfortunately, the issue is there
for quite a long time and it was exposed by a bad luck where an used
memory was reused (and not initialized) in libgccjit.

Martin

> 
>>>> Or did this bug exist since day one?  (But if it's an old bug, why
>>>> doesn't everyone see these crashes?)
>>>
>>> That's the effect of undefined behaviour.
>>
>> You mean, undefined behavior in libgccjit's own code, right?  Or in
>> our code?
> 
> In libgccjit's own code.
> 
> BR
> 
>    Andrea
> 

bug#51688: ELC+ELN international/emoji.elc crashes

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andreas Schwab <schwab@linux-m68k.org>
>>> Cc: rpluim@gmail.com,  akrl@sdf.org,  51688@debbugs.gnu.org
>>> Date: Wed, 24 Nov 2021 14:06:04 +0100
>>> 
>>> On Nov 24 2021, Eli Zaretskii wrote:
>>> 
>>> > Do you happen to know which libgccjit versions are affected by the
>>> > bug?  We could tell people to avoid them.
>>> 
>>> Most likely all of them.
>>
>> Too bad.
>>
>> Andrea, can anything be done to work around this somehow (except to
>> upgrade to a later GCC)?  Or is there nothing we can do except keep
>> fingers crossed?
>
> I don't think there's much we can do to work around this on Emacs side
> (Martin please correct me if I'm wrong).
>
>>> > Or did this bug exist since day one?  (But if it's an old bug, why
>>> > doesn't everyone see these crashes?)
>>> 
>>> That's the effect of undefined behaviour.
>>
>> You mean, undefined behavior in libgccjit's own code, right?  Or in
>> our code?
>
> In libgccjit's own code.
>

As was identified as a libgccjit bug shall we close this one?

  Andrea

bug#51688: ELC+ELN international/emoji.elc crashes

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Andreas Schwab <schwab@linux-m68k.org>, rpluim@gmail.com,
>         51688@debbugs.gnu.org, Martin Liška <mliska@suse.cz>
> Date: Thu, 25 Nov 2021 10:57:35 +0000
> 
> >> You mean, undefined behavior in libgccjit's own code, right?  Or in
> >> our code?
> >
> > In libgccjit's own code.
> >
> 
> As was identified as a libgccjit bug shall we close this one?

Yes; done.