Emacs crash backtrace.

Emacs crash backtrace.

[Vladimir Nikishkin]

Dear Emacs developers,

I am not sure this particular crash warrants a bug, and I do not know
how to reproduce it, but maybe having a crashdump may help someone debug
their code.

This is emacs-master f7816c94b61f87919afccbedbea5270ca5db4e15
built with pgtk and native-comp
mic-paren is a package from melpa

#0  0x00007fc4226f1258 in raise () at /lib64/libpthread.so.0
#1  0x000000000045d2a4 in terminate_due_to_signal ()
#2  0x000000000045d7d4 in  ()
#3  0x000000000056abcd in  ()
#4  0x000000000056acc9 in  ()
#5  0x00007fc4226f13a0 in <signal handler called> () at /lib64/libpthread.so.0
#6  0x00007fc4294831af in g_log_writer_default () at /usr/lib64/libglib-2.0.so.0
#7  0x00007fc4294813f3 in g_log_structured_array () at /usr/lib64/libglib-2.0.so.0
#8  0x00007fc429481e74 in g_log_structured_standard () at /usr/lib64/libglib-2.0.so.0
#9  0x00007fc429b21d96 in  () at /usr/lib64/libgdk-3.so.0
#10 0x00007fc429b2e9e3 in  () at /usr/lib64/libgdk-3.so.0
#11 0x00007fc420488e54 in _XError () at /usr/lib64/libX11.so.6
#12 0x00007fc420485ce7 in  () at /usr/lib64/libX11.so.6
#13 0x00007fc420485d75 in  () at /usr/lib64/libX11.so.6
#14 0x00007fc420486cdd in _XReply () at /usr/lib64/libX11.so.6
#15 0x00007fc4204826cd in XSync () at /usr/lib64/libX11.so.6
#16 0x00007fc429b2ed11 in  () at /usr/lib64/libgdk-3.so.0
#17 0x00007fc429b332bd in  () at /usr/lib64/libgdk-3.so.0
#18 0x00000000006996d5 in pgtk_handle_selection_event ()
#19 0x0000000000558487 in  ()
#20 0x000000000055882e in Finput_pending_p ()
#21 0x00000000005d5e77 in Ffuncall ()
#22 0x00007fc4180d7ee9 in F6d69632d706172656e2d636f6d6d616e642d686f6f6b_mic_paren_command_hook_0 ()
    at /home/lockywolf/.emacs.d/eln-cache/29.0.50-0b4e8e7d/mic-paren-07dd96c3-67eaf92f.eln
#23 0x00000000005d5e77 in Ffuncall ()
#24 0x00000000005d495d in internal_condition_case_n ()
#25 0x000000000054be69 in  ()
#26 0x00000000005d4fbd in run_hook_with_args ()
#27 0x000000000054fc48 in safe_run_hooks_maybe_narrowed ()
#28 0x000000000055f3ec in  ()



-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: Emacs crash backtrace.

[Po Lu]

Vladimir Nikishkin <lockywolf@gmail.com> writes:

> Dear Emacs developers,
>
> I am not sure this particular crash warrants a bug, and I do not know
> how to reproduce it, but maybe having a crashdump may help someone debug
> their code.
>
> This is emacs-master f7816c94b61f87919afccbedbea5270ca5db4e15
> built with pgtk and native-comp
> mic-paren is a package from melpa

You're using PGTK on X.  That is unsupported and will lead to problems.

> #0  0x00007fc4226f1258 in raise () at /lib64/libpthread.so.0
> #1  0x000000000045d2a4 in terminate_due_to_signal ()
> #2  0x000000000045d7d4 in  ()
> #3  0x000000000056abcd in  ()
> #4  0x000000000056acc9 in  ()
> #5  0x00007fc4226f13a0 in <signal handler called> () at /lib64/libpthread.so.0
> #6  0x00007fc4294831af in g_log_writer_default () at /usr/lib64/libglib-2.0.so.0
> #7  0x00007fc4294813f3 in g_log_structured_array () at /usr/lib64/libglib-2.0.so.0
> #8  0x00007fc429481e74 in g_log_structured_standard () at /usr/lib64/libglib-2.0.so.0
> #9  0x00007fc429b21d96 in  () at /usr/lib64/libgdk-3.so.0
> #10 0x00007fc429b2e9e3 in  () at /usr/lib64/libgdk-3.so.0
> #11 0x00007fc420488e54 in _XError () at /usr/lib64/libX11.so.6
> #12 0x00007fc420485ce7 in  () at /usr/lib64/libX11.so.6
> #13 0x00007fc420485d75 in  () at /usr/lib64/libX11.so.6
> #14 0x00007fc420486cdd in _XReply () at /usr/lib64/libX11.so.6
> #15 0x00007fc4204826cd in XSync () at /usr/lib64/libX11.so.6
> #16 0x00007fc429b2ed11 in  () at /usr/lib64/libgdk-3.so.0
> #17 0x00007fc429b332bd in  () at /usr/lib64/libgdk-3.so.0
> #18 0x00000000006996d5 in pgtk_handle_selection_event ()

Such as the above.  The PGTK port is only intended to support platforms
other than X, and does not implement very convoluted features, such as
INCR selection transfer, that are only needed with the GDK X11 backend.

Without INCR selection transfer, large X selection transfers will lead
to Alloc errors being generated by the X server as it rejects attempts
by Emacs to store large amounts of data in window properties.

Running the PGTK port on X also leads to various other problems with
keyboard input, frame focus, and child frames.

You should build with the regular X11 support (without PGTK) instead.

Re: Emacs crash backtrace.

[Andrea Corallo]

Po Lu <luangruo@yahoo.com> writes:

> Vladimir Nikishkin <lockywolf@gmail.com> writes:
>
>> Dear Emacs developers,
>>
>> I am not sure this particular crash warrants a bug, and I do not know
>> how to reproduce it, but maybe having a crashdump may help someone debug
>> their code.
>>
>> This is emacs-master f7816c94b61f87919afccbedbea5270ca5db4e15
>> built with pgtk and native-comp
>> mic-paren is a package from melpa
>
> You're using PGTK on X.  That is unsupported and will lead to problems.

Hi,

not sure if this was discussed already but, shouldn't we warn the user
running an Emacs in such unsupported configuration?

BR

  Andrea

Re: Emacs crash backtrace.

[Po Lu]

Andrea Corallo <akrl@sdf.org> writes:

> not sure if this was discussed already but, shouldn't we warn the user
> running an Emacs in such unsupported configuration?

That's already done so, in NEWS and other associated documentation.

Re: Emacs crash backtrace.

[Andrea Corallo]

Po Lu <luangruo@yahoo.com> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> not sure if this was discussed already but, shouldn't we warn the user
>> running an Emacs in such unsupported configuration?
>
> That's already done so, in NEWS and other associated documentation.

I'm talking about a run-time warning.  We do it for other dangerous confs
like using emacsclient with GTK/Emacs.

  Andrea

Re: Emacs crash backtrace.

[Stefan Monnier]

Po Lu [2022-11-08 21:42:47] wrote:
> Andrea Corallo <akrl@sdf.org> writes:
>> not sure if this was discussed already but, shouldn't we warn the user
>> running an Emacs in such unsupported configuration?
> That's already done so, in NEWS and other associated documentation.

I think Andrea was thinking of something more "in your face", like on
the splash screen or in the *scratch* buffer's initial text, or as
a `display-warning`, ...


        Stefan

Re: Emacs crash backtrace.

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Po Lu [2022-11-08 21:42:47] wrote:
>> Andrea Corallo <akrl@sdf.org> writes:
>>> not sure if this was discussed already but, shouldn't we warn the user
>>> running an Emacs in such unsupported configuration?
>> That's already done so, in NEWS and other associated documentation.
>
> I think Andrea was thinking of something more "in your face", like on
> the splash screen or in the *scratch* buffer's initial text, or as
> a `display-warning`, ...

Exactly, if Emacs is not supposed to work properly in a certain
configuration I believe we definitely should inform the user of this.

  Andrea

Re: Emacs crash backtrace.

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Po Lu <luangruo@yahoo.com>, Vladimir Nikishkin <lockywolf@gmail.com>,
>  emacs-devel@gnu.org
> Date: Wed, 09 Nov 2022 09:13:13 +0000
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Po Lu [2022-11-08 21:42:47] wrote:
> >> Andrea Corallo <akrl@sdf.org> writes:
> >>> not sure if this was discussed already but, shouldn't we warn the user
> >>> running an Emacs in such unsupported configuration?
> >> That's already done so, in NEWS and other associated documentation.
> >
> > I think Andrea was thinking of something more "in your face", like on
> > the splash screen or in the *scratch* buffer's initial text, or as
> > a `display-warning`, ...
> 
> Exactly, if Emacs is not supposed to work properly in a certain
> configuration I believe we definitely should inform the user of this.

Why not simply refuse to start in that case?  We could add a special
command-line option to override that, to leave users a "fire escape".

Re: Emacs crash backtrace.

[Po Lu]

Andrea Corallo <akrl@sdf.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Po Lu [2022-11-08 21:42:47] wrote:
>>> Andrea Corallo <akrl@sdf.org> writes:
>>>> not sure if this was discussed already but, shouldn't we warn the user
>>>> running an Emacs in such unsupported configuration?
>>> That's already done so, in NEWS and other associated documentation.
>>
>> I think Andrea was thinking of something more "in your face", like on
>> the splash screen or in the *scratch* buffer's initial text, or as
>> a `display-warning`, ...
>
> Exactly, if Emacs is not supposed to work properly in a certain
> configuration I believe we definitely should inform the user of this.
>
>   Andrea

Sounds reasonable, now done.

Re: Emacs crash backtrace.

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Why not simply refuse to start in that case?  We could add a special
> command-line option to override that, to leave users a "fire escape".

I made it display a large dialog box upon startup on X instead.  But
that would be fine with me too.

Re: Emacs crash backtrace.

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Po Lu <luangruo@yahoo.com>, Vladimir Nikishkin <lockywolf@gmail.com>,
>>  emacs-devel@gnu.org
>> Date: Wed, 09 Nov 2022 09:13:13 +0000
>> 
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>> > Po Lu [2022-11-08 21:42:47] wrote:
>> >> Andrea Corallo <akrl@sdf.org> writes:
>> >>> not sure if this was discussed already but, shouldn't we warn the user
>> >>> running an Emacs in such unsupported configuration?
>> >> That's already done so, in NEWS and other associated documentation.
>> >
>> > I think Andrea was thinking of something more "in your face", like on
>> > the splash screen or in the *scratch* buffer's initial text, or as
>> > a `display-warning`, ...
>> 
>> Exactly, if Emacs is not supposed to work properly in a certain
>> configuration I believe we definitely should inform the user of this.
>
> Why not simply refuse to start in that case?  We could add a special
> command-line option to override that, to leave users a "fire escape".

That's good as well, I've no strong preference over the two options.

Thanks

  Andrea

Re: Emacs crash backtrace.

[Andrea Corallo]

Po Lu <luangruo@yahoo.com> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>> Po Lu [2022-11-08 21:42:47] wrote:
>>>> Andrea Corallo <akrl@sdf.org> writes:
>>>>> not sure if this was discussed already but, shouldn't we warn the user
>>>>> running an Emacs in such unsupported configuration?
>>>> That's already done so, in NEWS and other associated documentation.
>>>
>>> I think Andrea was thinking of something more "in your face", like on
>>> the splash screen or in the *scratch* buffer's initial text, or as
>>> a `display-warning`, ...
>>
>> Exactly, if Emacs is not supposed to work properly in a certain
>> configuration I believe we definitely should inform the user of this.
>>
>>   Andrea
>
> Sounds reasonable, now done.

Thanks Po Lu

  Andrea