GNU bug report logs - #66068
30.0.50; xwidget-webkit-browse-url makes Emacs abort

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66068 in the body.
You can then email your comments to 66068 AT debbugs.gnu.org in the normal way.

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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 18 Sep 2023 12:06:37 +0200

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

I just built Emacs --with-xwidgets on a new system (glibc-2.38,
gcc-13.2.0, linux-6.5.2) on which I've installed webkitgtk-2.41.92 for
both Gtk3 and Gtk4 (libwebkit2gtk-4.1.so and libwebkitgtk-6.0.so).  When
I invoke `M-x xwidget-webkit-browse-url', enter a URL at the prompt and
press RET, Emacs aborts.  I ran under gdb and have attached a full
backtrace.

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.6) of 2023-09-18 built on strobelfs2
Repository revision: b331bf6d8a21ef3ac7e70d3f4a937e4256178d55
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Linux From Scratch r12.0-19

Configured using:
 'configure -C --with-xwidgets 'CFLAGS=-Og -g3'
 PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

[Message part 2 (text/plain, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 18 Sep 2023 19:16:40 +0800

Stephen Berman <stephen.berman <at> gmx.net> writes:

> I just built Emacs --with-xwidgets on a new system (glibc-2.38,
> gcc-13.2.0, linux-6.5.2) on which I've installed webkitgtk-2.41.92 for
> both Gtk3 and Gtk4 (libwebkit2gtk-4.1.so and libwebkitgtk-6.0.so).  When
> I invoke `M-x xwidget-webkit-browse-url', enter a URL at the prompt and
> press RET, Emacs aborts.  I ran under gdb and have attached a full
> backtrace.
>
> In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.38, cairo version 1.17.6) of 2023-09-18 built on strobelfs2
> Repository revision: b331bf6d8a21ef3ac7e70d3f4a937e4256178d55
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
> System Description: Linux From Scratch r12.0-19
>
> Configured using:
>  'configure -C --with-xwidgets 'CFLAGS=-Og -g3'
>  PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'
>
> Configured features:
> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
> JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
> SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
> XINPUT2 XPM XWIDGETS GTK3 ZLIB
>
> Important settings:
>   value of $LANG: en_US.UTF-8
>   locale-coding-system: utf-8-unix

Thanks for the report.  The X error itself is absent from the backtrace
you have provided, so please step to the frame incorporating
x_error_quitter, then type:

  (gdb) p *error

In case the error arises from an extension request, please also send the
output of the following command:

  $ xdpyinfo -ext

Thanks in advance.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 18 Sep 2023 14:28:03 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Mon, 18 Sep 2023 12:06:37 +0200
> 
> I just built Emacs --with-xwidgets on a new system (glibc-2.38,
> gcc-13.2.0, linux-6.5.2) on which I've installed webkitgtk-2.41.92 for
> both Gtk3 and Gtk4 (libwebkit2gtk-4.1.so and libwebkitgtk-6.0.so).  When
> I invoke `M-x xwidget-webkit-browse-url', enter a URL at the prompt and
> press RET, Emacs aborts.  I ran under gdb and have attached a full
> backtrace.

Thanks.  However, when Emacs aborts in x_error_quitter, the backtrace
is usually not useful (due to asynchronous treatment of X errors).  So
please run Emacs in X synchronous mode and post the backtrace from
that session.  The file etc/DEBUG explains how to do this; search for
"If you encounter X protocol errors" there.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 18 Sep 2023 14:16:03 +0200

On Mon, 18 Sep 2023 19:16:40 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> I just built Emacs --with-xwidgets on a new system (glibc-2.38,
>> gcc-13.2.0, linux-6.5.2) on which I've installed webkitgtk-2.41.92 for
>> both Gtk3 and Gtk4 (libwebkit2gtk-4.1.so and libwebkitgtk-6.0.so).  When
>> I invoke `M-x xwidget-webkit-browse-url', enter a URL at the prompt and
>> press RET, Emacs aborts.  I ran under gdb and have attached a full
>> backtrace.
>>
>> In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>>  3.24.38, cairo version 1.17.6) of 2023-09-18 built on strobelfs2
>> Repository revision: b331bf6d8a21ef3ac7e70d3f4a937e4256178d55
>> Repository branch: master
>> Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
>> System Description: Linux From Scratch r12.0-19
>>
>> Configured using:
>>  'configure -C --with-xwidgets 'CFLAGS=-Og -g3'
>>  PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'
>>
>> Configured features:
>> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
>> JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
>> SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
>> XINPUT2 XPM XWIDGETS GTK3 ZLIB
>>
>> Important settings:
>>   value of $LANG: en_US.UTF-8
>>   locale-coding-system: utf-8-unix
>
> Thanks for the report.  The X error itself is absent from the backtrace
> you have provided, so please step to the frame incorporating
> x_error_quitter, then type:
>
>   (gdb) p *error

Is the following what you want?  It doesn't seem very informative...

(gdb) up 0
#0  x_error_quitter (display=0x555555ead980, event=0x7fffffffc950)
    at /home/steve/src/emacs/emacs-master/src/xterm.c:26905
26905	{
(gdb) p *error
$1 = {void (const char *, ...)} 0x55555575ae68 <error>

FWIW, I get the same output when I run Emacs in gdb with -xrm
"emacs.synchronous: true", as requested by Eli.

> In case the error arises from an extension request, please also send the
> output of the following command:
>
>   $ xdpyinfo -ext

How do I know if there was an extension request?  The -ext flag requires
an extension-name as argument.

Steve Berman

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 18 Sep 2023 14:17:10 +0200

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

On Mon, 18 Sep 2023 14:28:03 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Mon, 18 Sep 2023 12:06:37 +0200
>>
>> I just built Emacs --with-xwidgets on a new system (glibc-2.38,
>> gcc-13.2.0, linux-6.5.2) on which I've installed webkitgtk-2.41.92 for
>> both Gtk3 and Gtk4 (libwebkit2gtk-4.1.so and libwebkitgtk-6.0.so).  When
>> I invoke `M-x xwidget-webkit-browse-url', enter a URL at the prompt and
>> press RET, Emacs aborts.  I ran under gdb and have attached a full
>> backtrace.
>
> Thanks.  However, when Emacs aborts in x_error_quitter, the backtrace
> is usually not useful (due to asynchronous treatment of X errors).  So
> please run Emacs in X synchronous mode and post the backtrace from
> that session.  The file etc/DEBUG explains how to do this; search for
> "If you encounter X protocol errors" there.

In the shell, with cwd the src directory of the emacs build tree, I
entered `gdb ./emacs' and at the gdb prompt: r -Q -xrm
"emacs.synchronous: true".  In Emacs I invoked xwidget-webkit-browse-url
as above and gdb stopped execution.  I've again attached the output of
`bt full', though to my layman's eye it looks, modulo addresses,
essentially identical to the backtrace I with `r -Q'.  I can try some of
the other suggestions given in etc/DEBUG, though I really don't know
what I'm doing so would welcome more targeted suggestions, if possible.

Steve Berman

[Message part 2 (text/plain, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 18 Sep 2023 22:11:31 +0800

Stephen Berman <stephen.berman <at> gmx.net>

> (gdb) up 0
> #0 x_error_quitter (display=0x555555ead980, event=0x7fffffffc950)
>     at /home/steve/src/emacs/emacs-master/src/xterm.c:26905
> 26905	{
> (gdb) p *error
> $1 = {void (const char *, ...)} 0x55555575ae68 <error>
>
> FWIW, I get the same output when I run Emacs in gdb with -xrm
> "emacs.synchronous: true", as requested by Eli.

My apologies, I intended to ask for:

  (gdb) p *event

I need new glasses.  Or hands.

>> In case the error arises from an extension request, please also send
>> the
>> output of the following command:
>>
>>   $ xdpyinfo -ext
>
> How do I know if there was an extension request?  The -ext flag
> requires
> an extension-name as argument.

Sorry, xdpyinfo -ext all.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 18 Sep 2023 17:08:48 +0200

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

On Mon, 18 Sep 2023 22:11:31 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net>
>
>> (gdb) up 0
>> #0 x_error_quitter (display=0x555555ead980, event=0x7fffffffc950)
>>     at /home/steve/src/emacs/emacs-master/src/xterm.c:26905
>> 26905	{
>> (gdb) p *error
>> $1 = {void (const char *, ...)} 0x55555575ae68 <error>
>>
>> FWIW, I get the same output when I run Emacs in gdb with -xrm
>> "emacs.synchronous: true", as requested by Eli.
>
> My apologies, I intended to ask for:
>
>   (gdb) p *event

No problem:

(gdb) r -Q -xrm "emacs.synchronous: true"
[...]
(gdb) frame 0
#0  x_error_quitter (display=0x555555ead980, event=0x7fffffffc930)
    at /home/steve/src/emacs/emacs-master/src/xterm.c:26905
26905	{
(gdb) p *event
$1 = {
  type = 0,
  display = 0x555555ead980,
  resourceid = 62914833,
  serial = 3527,
  error_code = 168 '\250',
  request_code = 151 '\227',
  minor_code = 32 ' '
}

> I need new glasses.  Or hands.
>
>>> In case the error arises from an extension request, please also send
>>> the
>>> output of the following command:
>>>
>>>   $ xdpyinfo -ext
>>
>> How do I know if there was an extension request?  The -ext flag
>> requires
>> an extension-name as argument.
>
> Sorry, xdpyinfo -ext all.

That's a lot of output; attached.

Steve Berman

[Message part 2 (text/plain, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Wed, 20 Sep 2023 11:22:51 +0800

Stephen Berman <stephen.berman <at> gmx.net> writes:

> On Mon, 18 Sep 2023 22:11:31 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net>
>>
>>> (gdb) up 0
>>> #0 x_error_quitter (display=0x555555ead980, event=0x7fffffffc950)
>>>     at /home/steve/src/emacs/emacs-master/src/xterm.c:26905
>>> 26905	{
>>> (gdb) p *error
>>> $1 = {void (const char *, ...)} 0x55555575ae68 <error>
>>>
>>> FWIW, I get the same output when I run Emacs in gdb with -xrm
>>> "emacs.synchronous: true", as requested by Eli.
>>
>> My apologies, I intended to ask for:
>>
>>   (gdb) p *event
>
> No problem:
>
> (gdb) r -Q -xrm "emacs.synchronous: true"
> [...]
> (gdb) frame 0
> #0  x_error_quitter (display=0x555555ead980, event=0x7fffffffc930)
>     at /home/steve/src/emacs/emacs-master/src/xterm.c:26905
> 26905	{
> (gdb) p *event
> $1 = {
>   type = 0,
>   display = 0x555555ead980,
>   resourceid = 62914833,
>   serial = 3527,
>   error_code = 168 '\250',
>   request_code = 151 '\227',
>   minor_code = 32 ' '
> }

Would you please send the backtrace from this as well?  The request code
does not match that of any core request or extension on your display,
and the backtrace you previously enclosed was not produced from an Emacs
running synchronously.

TIA.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sun, 24 Sep 2023 17:12:49 +0200

On Wed, 20 Sep 2023 11:22:51 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Mon, 18 Sep 2023 22:11:31 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net>
>>>
>>>> (gdb) up 0
>>>> #0 x_error_quitter (display=0x555555ead980, event=0x7fffffffc950)
>>>>     at /home/steve/src/emacs/emacs-master/src/xterm.c:26905
>>>> 26905	{
>>>> (gdb) p *error
>>>> $1 = {void (const char *, ...)} 0x55555575ae68 <error>
>>>>
>>>> FWIW, I get the same output when I run Emacs in gdb with -xrm
>>>> "emacs.synchronous: true", as requested by Eli.
>>>
>>> My apologies, I intended to ask for:
>>>
>>>   (gdb) p *event
>>
>> No problem:
>>
>> (gdb) r -Q -xrm "emacs.synchronous: true"
>> [...]
>> (gdb) frame 0
>> #0  x_error_quitter (display=0x555555ead980, event=0x7fffffffc930)
>>     at /home/steve/src/emacs/emacs-master/src/xterm.c:26905
>> 26905	{
>> (gdb) p *event
>> $1 = {
>>   type = 0,
>>   display = 0x555555ead980,
>>   resourceid = 62914833,
>>   serial = 3527,
>>   error_code = 168 '\250',
>>   request_code = 151 '\227',
>>   minor_code = 32 ' '
>> }
>
> Would you please send the backtrace from this as well?  The request code
> does not match that of any core request or extension on your display,
> and the backtrace you previously enclosed was not produced from an Emacs
> running synchronously.

(Sorry for not responding sooner; I was travelling.)  I already posted a
backtrace produced from -Q -xrm "emacs.synchronous: true" in the message
I referred to above, see the attachment to <87a5tjd6bd.fsf <at> gmx.net>
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg01928.html>.
Though as I pointed out in that message, the only apparent differences
from the first backtrace (produced from just -Q) are the specific
numerical values of addresses, struct members, etc.  Just to be sure I
just now repeated the asynchronous run again and got again a
structurally identical backtrace (i.e., differing only in address and
struct member numerical values).

Steve Berman

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 25 Sep 2023 08:30:54 +0800

Stephen Berman <stephen.berman <at> gmx.net> writes:

> (Sorry for not responding sooner; I was travelling.)  I already posted a
> backtrace produced from -Q -xrm "emacs.synchronous: true" in the message
> I referred to above, see the attachment to <87a5tjd6bd.fsf <at> gmx.net>
> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg01928.html>.
> Though as I pointed out in that message, the only apparent differences
> from the first backtrace (produced from just -Q) are the specific
> numerical values of addresses, struct members, etc.  Just to be sure I
> just now repeated the asynchronous run again and got again a
> structurally identical backtrace (i.e., differing only in address and
> struct member numerical values).

That backtrace is erroneous, as starting Emacs with -Q (in contrast to
-q) causes all X resources to be ignored.  Please start Emacs with -q
instead.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 25 Sep 2023 10:47:35 +0200

On Mon, 25 Sep 2023 08:30:54 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> (Sorry for not responding sooner; I was travelling.)  I already posted a
>> backtrace produced from -Q -xrm "emacs.synchronous: true" in the message
>> I referred to above, see the attachment to <87a5tjd6bd.fsf <at> gmx.net>
>> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg01928.html>.
>> Though as I pointed out in that message, the only apparent differences
>> from the first backtrace (produced from just -Q) are the specific
>> numerical values of addresses, struct members, etc.  Just to be sure I
>> just now repeated the asynchronous run again and got again a
>> structurally identical backtrace (i.e., differing only in address and
>> struct member numerical values).
>
> That backtrace is erroneous, as starting Emacs with -Q (in contrast to
> -q) causes all X resources to be ignored.

Oh, sorry, that was stupid of me.

>                                            Please start Emacs with -q
> instead.

Now this is interesting: starting from within gdb with -q -xrm
"emacs.synchronous: true", then doing M-x xwidget-webkit-browse-url,
entering a URL and pressing RET now succeeds, i.e. the web page opens,
no crash.  Same when starting from within gdb with just -xrm
"emacs.synchronous: true", i.e., with my init file running in X
synchronous mode: xwidget-webkit-browse-url does not make Emacs crash.
However, then I start Emacs outside of gdb, i.e. directly from the shell
with -xrm "emacs.synchronous: true", either with or without -q, and
invoke xwidget-webkit-browse-url, then Emacs aborts as before (i.e. same
as when not running in X synchronous mode).  I hope you can make sense
of that.

Steve Berman

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 25 Sep 2023 17:25:43 +0800

Stephen Berman <stephen.berman <at> gmx.net> writes:

> Now this is interesting: starting from within gdb with -q -xrm
> "emacs.synchronous: true", then doing M-x xwidget-webkit-browse-url,
> entering a URL and pressing RET now succeeds, i.e. the web page opens,
> no crash.  Same when starting from within gdb with just -xrm
> "emacs.synchronous: true", i.e., with my init file running in X
> synchronous mode: xwidget-webkit-browse-url does not make Emacs crash.
> However, then I start Emacs outside of gdb, i.e. directly from the shell
> with -xrm "emacs.synchronous: true", either with or without -q, and
> invoke xwidget-webkit-browse-url, then Emacs aborts as before (i.e. same
> as when not running in X synchronous mode).  I hope you can make sense
> of that.

When Emacs aborts, it should print a stack trace.  Provided that your
system is configured correctly, a core file should also be generated.

If either of these two are available, please attempt to derive a stack
trace from them; the procedure for the former case is illustrated within
(emacs)Crashing.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 25 Sep 2023 12:22:19 +0200

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

On Mon, 25 Sep 2023 17:25:43 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> Now this is interesting: starting from within gdb with -q -xrm
>> "emacs.synchronous: true", then doing M-x xwidget-webkit-browse-url,
>> entering a URL and pressing RET now succeeds, i.e. the web page opens,
>> no crash.  Same when starting from within gdb with just -xrm
>> "emacs.synchronous: true", i.e., with my init file running in X
>> synchronous mode: xwidget-webkit-browse-url does not make Emacs crash.
>> However, then I start Emacs outside of gdb, i.e. directly from the shell
>> with -xrm "emacs.synchronous: true", either with or without -q, and
>> invoke xwidget-webkit-browse-url, then Emacs aborts as before (i.e. same
>> as when not running in X synchronous mode).  I hope you can make sense
>> of that.
>
> When Emacs aborts, it should print a stack trace.  Provided that your
> system is configured correctly, a core file should also be generated.
>
> If either of these two are available, please attempt to derive a stack
> trace from them; the procedure for the former case is illustrated within
> (emacs)Crashing.

I have both the stack trace and the core file.

The stack trace is essentially the same as the one at the end of the
backtrace I attached to my OP in this bug, see <87r0mvdccy.fsf <at> gmx.net>
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg01905.html>.
However, using the sed with addr2line as described in (emacs) Crashing
only produces 41 lines like this: ?? ??:0.  Is this because my Emacs
build is out-of-tree?

I've attached the full backtrace produced by running gdb on the core
file (though it starts with some warnings which may call its usefulness
into doubt).

Steve Berman

[Message part 2 (text/plain, attachment)]

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 30 Sep 2023 12:03:43 +0200

On Mon, 25 Sep 2023 12:22:19 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Mon, 25 Sep 2023 17:25:43 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> Now this is interesting: starting from within gdb with -q -xrm
>>> "emacs.synchronous: true", then doing M-x xwidget-webkit-browse-url,
>>> entering a URL and pressing RET now succeeds, i.e. the web page opens,
>>> no crash.  Same when starting from within gdb with just -xrm
>>> "emacs.synchronous: true", i.e., with my init file running in X
>>> synchronous mode: xwidget-webkit-browse-url does not make Emacs crash.
>>> However, then I start Emacs outside of gdb, i.e. directly from the shell
>>> with -xrm "emacs.synchronous: true", either with or without -q, and
>>> invoke xwidget-webkit-browse-url, then Emacs aborts as before (i.e. same
>>> as when not running in X synchronous mode).  I hope you can make sense
>>> of that.
>>
>> When Emacs aborts, it should print a stack trace.  Provided that your
>> system is configured correctly, a core file should also be generated.
>>
>> If either of these two are available, please attempt to derive a stack
>> trace from them; the procedure for the former case is illustrated within
>> (emacs)Crashing.
>
> I have both the stack trace and the core file.
>
> The stack trace is essentially the same as the one at the end of the
> backtrace I attached to my OP in this bug, see <87r0mvdccy.fsf <at> gmx.net>
> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg01905.html>.
> However, using the sed with addr2line as described in (emacs) Crashing
> only produces 41 lines like this: ?? ??:0.  Is this because my Emacs
> build is out-of-tree?
>
> I've attached the full backtrace produced by running gdb on the core
> file (though it starts with some warnings which may call its usefulness
> into doubt).

FWIW, I have updated webkitgtk from 2.41.92 to 2.42.1 and invoking
xwidget-webkit-browse-url still makes Emacs crash.  But with two other
GNU/Linux systems which have webkitgtk-2.40.1, xwidget-webkit-browse-url
invoked in Emacs built from the same commit on master works fine.

Steve Berman

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 30 Sep 2023 19:52:03 +0800

Stephen Berman <stephen.berman <at> gmx.net> writes:

> On Mon, 25 Sep 2023 12:22:19 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> On Mon, 25 Sep 2023 17:25:43 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> Now this is interesting: starting from within gdb with -q -xrm
>>>> "emacs.synchronous: true", then doing M-x xwidget-webkit-browse-url,
>>>> entering a URL and pressing RET now succeeds, i.e. the web page opens,
>>>> no crash.  Same when starting from within gdb with just -xrm
>>>> "emacs.synchronous: true", i.e., with my init file running in X
>>>> synchronous mode: xwidget-webkit-browse-url does not make Emacs crash.
>>>> However, then I start Emacs outside of gdb, i.e. directly from the shell
>>>> with -xrm "emacs.synchronous: true", either with or without -q, and
>>>> invoke xwidget-webkit-browse-url, then Emacs aborts as before (i.e. same
>>>> as when not running in X synchronous mode).  I hope you can make sense
>>>> of that.
>>>
>>> When Emacs aborts, it should print a stack trace.  Provided that your
>>> system is configured correctly, a core file should also be generated.
>>>
>>> If either of these two are available, please attempt to derive a stack
>>> trace from them; the procedure for the former case is illustrated within
>>> (emacs)Crashing.
>>
>> I have both the stack trace and the core file.
>>
>> The stack trace is essentially the same as the one at the end of the
>> backtrace I attached to my OP in this bug, see <87r0mvdccy.fsf <at> gmx.net>
>> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg01905.html>.
>> However, using the sed with addr2line as described in (emacs) Crashing
>> only produces 41 lines like this: ?? ??:0.  Is this because my Emacs
>> build is out-of-tree?
>>
>> I've attached the full backtrace produced by running gdb on the core
>> file (though it starts with some warnings which may call its usefulness
>> into doubt).
>
> FWIW, I have updated webkitgtk from 2.41.92 to 2.42.1 and invoking
> xwidget-webkit-browse-url still makes Emacs crash.  But with two other
> GNU/Linux systems which have webkitgtk-2.40.1, xwidget-webkit-browse-url
> invoked in Emacs built from the same commit on master works fine.
>
> Steve Berman

I believe this is not a problem we can fix: the WebKitGTK developers
have elected to presume that WebViews are always placed within X
windows, and to unconditionally create GLX contexts for such views.

This loses, inasmuch as Emacs places each widget within an offscreen
window, facilitating the duplication of its contents when it is
simultaneously displayed within two Emacs windows.  Please report this
to the WebKitGTK developers.

WebKitGTK is not meant for displaying contents within programs that must
display the same widget in more than one location; that is the metier of
WPE (wpewebkit.org).  Several months ago, I asked for interested
individuals to step forth and undertake writing the code to replace
WebKitGTK by that library, but was met with silence.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 30 Sep 2023 14:09:51 +0200

On Sat, 30 Sep 2023 19:52:03 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Mon, 25 Sep 2023 12:22:19 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>>
>>> On Mon, 25 Sep 2023 17:25:43 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
>>>
>>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>>
>>>>> Now this is interesting: starting from within gdb with -q -xrm
>>>>> "emacs.synchronous: true", then doing M-x xwidget-webkit-browse-url,
>>>>> entering a URL and pressing RET now succeeds, i.e. the web page opens,
>>>>> no crash.  Same when starting from within gdb with just -xrm
>>>>> "emacs.synchronous: true", i.e., with my init file running in X
>>>>> synchronous mode: xwidget-webkit-browse-url does not make Emacs crash.
>>>>> However, then I start Emacs outside of gdb, i.e. directly from the shell
>>>>> with -xrm "emacs.synchronous: true", either with or without -q, and
>>>>> invoke xwidget-webkit-browse-url, then Emacs aborts as before (i.e. same
>>>>> as when not running in X synchronous mode).  I hope you can make sense
>>>>> of that.
>>>>
>>>> When Emacs aborts, it should print a stack trace.  Provided that your
>>>> system is configured correctly, a core file should also be generated.
>>>>
>>>> If either of these two are available, please attempt to derive a stack
>>>> trace from them; the procedure for the former case is illustrated within
>>>> (emacs)Crashing.
>>>
>>> I have both the stack trace and the core file.
>>>
>>> The stack trace is essentially the same as the one at the end of the
>>> backtrace I attached to my OP in this bug, see <87r0mvdccy.fsf <at> gmx.net>
>>> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg01905.html>.
>>> However, using the sed with addr2line as described in (emacs) Crashing
>>> only produces 41 lines like this: ?? ??:0.  Is this because my Emacs
>>> build is out-of-tree?
>>>
>>> I've attached the full backtrace produced by running gdb on the core
>>> file (though it starts with some warnings which may call its usefulness
>>> into doubt).
>>
>> FWIW, I have updated webkitgtk from 2.41.92 to 2.42.1 and invoking
>> xwidget-webkit-browse-url still makes Emacs crash.  But with two other
>> GNU/Linux systems which have webkitgtk-2.40.1, xwidget-webkit-browse-url
>> invoked in Emacs built from the same commit on master works fine.
>>
>> Steve Berman
>
> I believe this is not a problem we can fix: the WebKitGTK developers
> have elected to presume that WebViews are always placed within X
> windows, and to unconditionally create GLX contexts for such views.
>
> This loses, inasmuch as Emacs places each widget within an offscreen
> window, facilitating the duplication of its contents when it is
> simultaneously displayed within two Emacs windows.  Please report this
> to the WebKitGTK developers.

I'll try to do that.  But if they choose not to accommodate Emacs and
there is no solution on the Emacs side, then the --with-xwidgets build
is effectively broken for usual Emacs usage from at least webkitgtk
2.41.92 on, which is unfortunate.  However, as I noted above,
xwidget-webkit-browse-url does work with current webkitgtk when starting
Emacs from within gdb with -q -xrm "emacs.synchronous: true", so maybe
there is a solution on the Emacs side.  Do you know why it works (only)
when Emacs is started this way, in particular, what does starting under
gdb do that makes the difference?

> WebKitGTK is not meant for displaying contents within programs that must
> display the same widget in more than one location; that is the metier of
> WPE (wpewebkit.org).  Several months ago, I asked for interested
> individuals to step forth and undertake writing the code to replace
> WebKitGTK by that library, but was met with silence.

Unfortunately, I lack the competence to undertake that.

Steve Berman

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

From: Ramon Diaz-Uriarte <rdiaz02 <at> gmail.com>
To: 66068 <at> debbugs.gnu.org
Cc: rdiaz02 <at> gmail.com, stephen.berman <at> gmx.net
Subject: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Thu, 07 Dec 2023 11:28:00 +0100

For what is worth, xwidget-webkit-browse-url does not make Emacs 30 (30.0.50) or 29 (29.1.90) abort on my system (Debian) (I just built both a few minutes ago after freshly checking the git repos).

The webkitgtk packages I have are:

libwebkit2gtk-4.0-37:amd64                                  2.42.2-1
libwebkit2gtk-4.0-dev:amd64                                 2.42.2-1
libwebkit2gtk-4.0-doc                                       2.42.2-1
libwebkit2gtk-4.1-0:amd64                                   2.42.2-1

In case it could matter, I am using XMonad as window manager. When 
`M-x xwidget-webkit-browse-url` and I enter the URL at the prompt and press enter, on the terminal from which I did `emacs -Q` I see

-------------------
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
libEGL warning: failed to get driver name for fd -1

libEGL warning: MESA-LOADER: failed to retrieve device information

libEGL warning: failed to get driver name for fd -1
-------------------

But everything seems to work normally.

Best,


Ramon Diaz-Uriarte

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Ramon Diaz-Uriarte <rdiaz02 <at> gmail.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 09 Dec 2023 16:12:03 +0100

On Thu, 07 Dec 2023 11:28:00 +0100 Ramon Diaz-Uriarte <rdiaz02 <at> gmail.com> wrote:

> For what is worth, xwidget-webkit-browse-url does not make Emacs 30 (30.0.50)
> or 29 (29.1.90) abort on my system (Debian) (I just built both a few minutes
> ago after freshly checking the git repos).
>
> The webkitgtk packages I have are:
>
> libwebkit2gtk-4.0-37:amd64                                  2.42.2-1
> libwebkit2gtk-4.0-dev:amd64                                 2.42.2-1
> libwebkit2gtk-4.0-doc                                       2.42.2-1
> libwebkit2gtk-4.1-0:amd64                                   2.42.2-1

This prompted me to update my webkitgtk to 2.42.3, the latest stable
release, then I rebuilt Emacs from the latest commit on master.  But
invoking xwidget-webkit-browse-url stills makes Emacs crash for me.

> In case it could matter, I am using XMonad as window manager. When
> `M-x xwidget-webkit-browse-url` and I enter the URL at the prompt and press
> enter, on the terminal from which I did `emacs -Q` I see
>
> -------------------
> Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want
> WebKit to use a different signal
> libEGL warning: failed to get driver name for fd -1
>
> libEGL warning: MESA-LOADER: failed to retrieve device information
>
> libEGL warning: failed to get driver name for fd -1
> -------------------
>
> But everything seems to work normally.

I get the signal 10 message, but I think that's been emitted for some
time when invoking xwidget-webkit-browse-url and isn't related to the
crash.  I don't get the libEGL warnings, but I do get the following,
which I think I haven't seen previously and seems like it could be
related to the crash (which is perhaps then different from what I
reported in my OP of this bug):

(emacs-master:10722): GLib-CRITICAL **: 15:46:25.356: Source ID 658 was not found when attempting to remove it
X protocol error: GLXBadWindow on protocol request 151
Serial no: 6143
Failing resource ID (if any): 0x2e001fe
Minor code: 32
This is a bug!  Please report this to bug-gnu-emacs <at> gnu.org!

Steve Berman

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Ramon Diaz-Uriarte <rdiaz02 <at> gmail.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 09 Dec 2023 21:39:47 +0100

On Sat, 09 Dec 2023 16:12:03 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Thu, 07 Dec 2023 11:28:00 +0100 Ramon Diaz-Uriarte <rdiaz02 <at> gmail.com> wrote:
>
>> For what is worth, xwidget-webkit-browse-url does not make Emacs 30 (30.0.50)
>> or 29 (29.1.90) abort on my system (Debian) (I just built both a few minutes
>> ago after freshly checking the git repos).
>>
>> The webkitgtk packages I have are:
>>
>> libwebkit2gtk-4.0-37:amd64                                  2.42.2-1
>> libwebkit2gtk-4.0-dev:amd64                                 2.42.2-1
>> libwebkit2gtk-4.0-doc                                       2.42.2-1
>> libwebkit2gtk-4.1-0:amd64                                   2.42.2-1
>
> This prompted me to update my webkitgtk to 2.42.3, the latest stable
> release, then I rebuilt Emacs from the latest commit on master.  But
> invoking xwidget-webkit-browse-url stills makes Emacs crash for me.
>
>> In case it could matter, I am using XMonad as window manager. When
>> `M-x xwidget-webkit-browse-url` and I enter the URL at the prompt and press
>> enter, on the terminal from which I did `emacs -Q` I see
>>
>> -------------------
>> Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want
>> WebKit to use a different signal
>> libEGL warning: failed to get driver name for fd -1
>>
>> libEGL warning: MESA-LOADER: failed to retrieve device information
>>
>> libEGL warning: failed to get driver name for fd -1
>> -------------------
>>
>> But everything seems to work normally.
>
> I get the signal 10 message, but I think that's been emitted for some
> time when invoking xwidget-webkit-browse-url and isn't related to the
> crash.  I don't get the libEGL warnings, but I do get the following,
> which I think I haven't seen previously and seems like it could be
> related to the crash (which is perhaps then different from what I
> reported in my OP of this bug):
>
> (emacs-master:10722): GLib-CRITICAL **: 15:46:25.356: Source ID 658 was not
> found when attempting to remove it
> X protocol error: GLXBadWindow on protocol request 151
> Serial no: 6143
> Failing resource ID (if any): 0x2e001fe
> Minor code: 32
> This is a bug!  Please report this to bug-gnu-emacs <at> gnu.org!

My memory was wrong: in fact, the same output appears at the end of the
GDB backtrace attached to my OP in this bug.  And I just ran the emacs I
built against the latest webkitgtk under gdb, and when I start it with
-Q (or -q), invoking xwidget-webkit-browse-url makes it crash, and the
backtrace appears to be essentially the same as the one in my OP (except
in some of the frames the output is now much less detailed; perhaps
because I'm now building emacs with native compilation?).  And just as I
reported in a previous followup, when I start my fresh build of emacs
with -q -xrm "emacs.synchronous: true" outside of gdb, I also get the
crash, but when I start it under gdb with the same command line
arguments, then invoking xwidget-webkit-browse-url works fine.  I have
no idea why there is this difference, and no one offered an explanation
for it the last time; maybe this time?

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org, rdiaz02 <at> gmail.com
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sun, 10 Dec 2023 07:32:32 +0200

> Cc: 66068 <at> debbugs.gnu.org
> Date: Sat, 09 Dec 2023 21:39:47 +0100
> From:  Stephen Berman via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> My memory was wrong: in fact, the same output appears at the end of the
> GDB backtrace attached to my OP in this bug.  And I just ran the emacs I
> built against the latest webkitgtk under gdb, and when I start it with
> -Q (or -q), invoking xwidget-webkit-browse-url makes it crash, and the
> backtrace appears to be essentially the same as the one in my OP (except
> in some of the frames the output is now much less detailed; perhaps
> because I'm now building emacs with native compilation?).  And just as I
> reported in a previous followup, when I start my fresh build of emacs
> with -q -xrm "emacs.synchronous: true" outside of gdb, I also get the
> crash, but when I start it under gdb with the same command line
> arguments, then invoking xwidget-webkit-browse-url works fine.  I have
> no idea why there is this difference, and no one offered an explanation
> for it the last time; maybe this time?

I don't have an explanation, but I want to point out that it is still
possible to debug these crashes with GDB: by producing a core file and
then invoking GDB on that core file.  There are some restrictions and
disadvantages to what you can do in GDB when debugging a core file as
opposed to a running program, but most of the functionalities will
still work, and might provide valuable insights.

So my suggestion is to get Emacs to crash when you run it with
'-q -xrm "emacs.synchronous: true"', and then debug the core file and
post the findings here.

Thanks.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66068 <at> debbugs.gnu.org, rdiaz02 <at> gmail.com
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sun, 10 Dec 2023 14:36:09 +0100

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

On Sun, 10 Dec 2023 07:32:32 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Cc: 66068 <at> debbugs.gnu.org
>> Date: Sat, 09 Dec 2023 21:39:47 +0100
>> From:  Stephen Berman via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> My memory was wrong: in fact, the same output appears at the end of the
>> GDB backtrace attached to my OP in this bug.  And I just ran the emacs I
>> built against the latest webkitgtk under gdb, and when I start it with
>> -Q (or -q), invoking xwidget-webkit-browse-url makes it crash, and the
>> backtrace appears to be essentially the same as the one in my OP (except
>> in some of the frames the output is now much less detailed; perhaps
>> because I'm now building emacs with native compilation?).  And just as I
>> reported in a previous followup, when I start my fresh build of emacs
>> with -q -xrm "emacs.synchronous: true" outside of gdb, I also get the
>> crash, but when I start it under gdb with the same command line
>> arguments, then invoking xwidget-webkit-browse-url works fine.  I have
>> no idea why there is this difference, and no one offered an explanation
>> for it the last time; maybe this time?
>
> I don't have an explanation, but I want to point out that it is still
> possible to debug these crashes with GDB: by producing a core file and
> then invoking GDB on that core file.  There are some restrictions and
> disadvantages to what you can do in GDB when debugging a core file as
> opposed to a running program, but most of the functionalities will
> still work, and might provide valuable insights.
>
> So my suggestion is to get Emacs to crash when you run it with
> '-q -xrm "emacs.synchronous: true"', and then debug the core file and
> post the findings here.

Upthread Po Lu made the same suggestion and I posted the backtrace, see
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg02461.html>.
For comparison, I've done that again with my current build from master
built against the latest webkitgtk and attached the backtrace.  It looks
to me largely similar to the earlier core backtrace, though in some
frames less detailed, again maybe due to native compilation.  I can try
out any gdb instructions on the core file whose results you want to see.

I would really like to know why xwidget-webkit-browse-url works with -q
-xrm "emacs.synchronous: true" only under gdb and crashes otherwise.
And also why Ramon Diaz-Uriarte does not get a crash: it seems to me
unlikely that it started working with webkitgtk 2.42.2 but stopped again
with 2.42.3 (I cannot readily try with 2.42.2 now).

Steve Berman

[core-backtrace (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>, Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org, rdiaz02 <at> gmail.com
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sun, 10 Dec 2023 17:02:06 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: rdiaz02 <at> gmail.com,  66068 <at> debbugs.gnu.org
> Date: Sun, 10 Dec 2023 14:36:09 +0100
> 
> > So my suggestion is to get Emacs to crash when you run it with
> > '-q -xrm "emacs.synchronous: true"', and then debug the core file and
> > post the findings here.
> 
> Upthread Po Lu made the same suggestion and I posted the backtrace, see
> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg02461.html>.
> For comparison, I've done that again with my current build from master
> built against the latest webkitgtk and attached the backtrace.  It looks
> to me largely similar to the earlier core backtrace, though in some
> frames less detailed, again maybe due to native compilation.  I can try
> out any gdb instructions on the core file whose results you want to see.

The backtrace seems to say that there was some X error:

  X protocol error: GLXBadWindow on protocol request 151
  Serial no: 4286
  Failing resource ID (if any): 0x3c001c5
  Minor code: 32

I guess we now need to understand what window triggered the "bad
window" error and why?

> I would really like to know why xwidget-webkit-browse-url works with -q
> -xrm "emacs.synchronous: true" only under gdb and crashes otherwise.
> And also why Ramon Diaz-Uriarte does not get a crash: it seems to me
> unlikely that it started working with webkitgtk 2.42.2 but stopped again
> with 2.42.3 (I cannot readily try with 2.42.2 now).

Bugs sometimes behave like that.  A different memory configuration or
something.  We might not understand until we debug this issue
completely.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66068 <at> debbugs.gnu.org, rdiaz02 <at> gmail.com,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sun, 10 Dec 2023 23:28:30 +0800

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

> The backtrace seems to say that there was some X error:
>
>   X protocol error: GLXBadWindow on protocol request 151
>   Serial no: 4286
>   Failing resource ID (if any): 0x3c001c5
>   Minor code: 32
>
> I guess we now need to understand what window triggered the "bad
> window" error and why?

I've commented on precisely the same bug in the past; if someone can
unearth that bug number, this bug ought to be merged with it.

It boils down to how the WebKitGTK developers have elected to cease
supporting off-screen windows, by presuming that every window holding a
WebView widget is an X server window eligible for an OpenGL context.
Emacs requires placing these widgets within offscreen windows managed by
GTK, for each xwidget might be displayed in multiple distinct windows,
and its contents must be captured and reproduced within all of them if
that be the case.

To put this another way, WebKitGTK doesn't support displaying a single
widget more than once anymore.  There is another library designed for
such use-cases as that of Emacs, based on the same WebKit library as
WebKitGTK, by the name of WPE.  The solution to this bug, in my
estimation, is rewriting xwidgets for that library... any volunteers?

BTW, please pardon my belated response to this bug.  Time remains scarce
for me.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, rdiaz02 <at> gmail.com
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sun, 10 Dec 2023 16:47:40 +0100

On Sun, 10 Dec 2023 23:28:30 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> The backtrace seems to say that there was some X error:
>>
>>   X protocol error: GLXBadWindow on protocol request 151
>>   Serial no: 4286
>>   Failing resource ID (if any): 0x3c001c5
>>   Minor code: 32
>>
>> I guess we now need to understand what window triggered the "bad
>> window" error and why?
>
> I've commented on precisely the same bug in the past; if someone can
> unearth that bug number, this bug ought to be merged with it.

Nothing to merge, it was this very bug:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-09/msg02680.html

> It boils down to how the WebKitGTK developers have elected to cease
> supporting off-screen windows, by presuming that every window holding a
> WebView widget is an X server window eligible for an OpenGL context.
> Emacs requires placing these widgets within offscreen windows managed by
> GTK, for each xwidget might be displayed in multiple distinct windows,
> and its contents must be captured and reproduced within all of them if
> that be the case.
>
> To put this another way, WebKitGTK doesn't support displaying a single
> widget more than once anymore.  There is another library designed for
> such use-cases as that of Emacs, based on the same WebKit library as
> WebKitGTK, by the name of WPE.  The solution to this bug, in my
> estimation, is rewriting xwidgets for that library... any volunteers?

But again, xwidget-webkit-browse-url does work with -q -xrm
"emacs.synchronous: true" but only when running emacs under gdb.  So if
someone can figure out why and how, I'd think it must be possible to get
it to work when running emacs by itself.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org, rdiaz02 <at> gmail.com, stephen.berman <at> gmx.net
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sun, 10 Dec 2023 17:49:03 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Stephen Berman <stephen.berman <at> gmx.net>,  rdiaz02 <at> gmail.com,
>   66068 <at> debbugs.gnu.org
> Date: Sun, 10 Dec 2023 23:28:30 +0800
> 
> To put this another way, WebKitGTK doesn't support displaying a single
> widget more than once anymore.

Could we work around these problems for now by disallowing the same
widget to be displayed more than once in Emacs?

> There is another library designed for such use-cases as that of
> Emacs, based on the same WebKit library as WebKitGTK, by the name of
> WPE.  The solution to this bug, in my estimation, is rewriting
> xwidgets for that library... any volunteers?

Seconded.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, rdiaz02 <at> gmail.com
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 11 Dec 2023 08:43:57 +0800

Stephen Berman <stephen.berman <at> gmx.net> writes:

> But again, xwidget-webkit-browse-url does work with -q -xrm
> "emacs.synchronous: true" but only when running emacs under gdb.  So
> if someone can figure out why and how, I'd think it must be possible
> to get it to work when running emacs by itself.

This is probably since synchronous mode causes responses to GTK's
invalid requests to be processed in between an error trap installed by
Emacs, likely the "silent" sort recorded by x_ignore_....  As this is
possible solely when synchronous mode is in effect, and even then
unreliable, there's no solution short of that or dismissing GLX errors
completely.

But the latter will induce crashes when a web page attempts to run
WebGL (and such circumstances will only proliferate as WebKitGTK
development continues), and as such, the only long-term fix is a port to
WPE.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, rdiaz02 <at> gmail.com
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 11 Dec 2023 10:55:39 +0100

On Mon, 11 Dec 2023 08:43:57 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> But again, xwidget-webkit-browse-url does work with -q -xrm
>> "emacs.synchronous: true" but only when running emacs under gdb.  So
>> if someone can figure out why and how, I'd think it must be possible
>> to get it to work when running emacs by itself.
>
> This is probably since synchronous mode causes responses to GTK's
> invalid requests to be processed in between an error trap installed by
> Emacs, likely the "silent" sort recorded by x_ignore_....  As this is
> possible solely when synchronous mode is in effect, and even then
> unreliable, there's no solution short of that or dismissing GLX errors
> completely.

Are you saying processing GTK's invalid requests is necessary to prevent
the crash and that only happens (can only happen?) when running Emacs
under GDB?  I don't understand why, but I don't mind if you don't want
to elaborate.

> But the latter will induce crashes when a web page attempts to run
> WebGL (and such circumstances will only proliferate as WebKitGTK
> development continues), and as such, the only long-term fix is a port to
> WPE.

Ok.

Steve Berman

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, rdiaz02 <at> gmail.com
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 11 Dec 2023 18:16:01 +0800

Stephen Berman <stephen.berman <at> gmx.net> writes:

> Are you saying processing GTK's invalid requests is necessary to prevent
> the crash and that only happens (can only happen?) when running Emacs
> under GDB?  I don't understand why, but I don't mind if you don't want
> to elaborate.

I don't understand why it doesn't work outside GDB, but what I said is
the only explanation that makes some sense.

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

From: Ramon Diaz-Uriarte <r.diaz <at> uam.es>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 66068 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, rdiaz02 <at> gmail.com
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Mon, 11 Dec 2023 22:03:02 +0100

On Sun, 10-December-2023, at 14:36:09, Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
> I would really like to know why xwidget-webkit-browse-url works with -q
> -xrm "emacs.synchronous: true" only under gdb and crashes otherwise.
> And also why Ramon Diaz-Uriarte does not get a crash: it seems to me
> unlikely that it started working with webkitgtk 2.42.2 but stopped again
> with 2.42.3 (I cannot readily try with 2.42.2 now).

In my main machine, it does not crash with 2.42.2 and did not crash, either, with 2.42.1. However, I just tried on a different machine (also Debian, also XMonad as window manager), with 2.42.2, and it crashes.

And it crashes for other people too with other versions of Linux, etc:

https://old.reddit.com/r/emacs/comments/17g6npv/xwidgetwebkit_has_started_crashing_emacs_sessions/

So that it does not crash in my main machine might be some happy exception.

Best,


R.


>
> Steve Berman
>
> [2. application/octet-stream; core-backtrace]...

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

From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
To: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs
 abort
Date: Wed, 4 Sep 2024 12:23:28 +0100 (BST)

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

If my understanding of this bug is correct, newer versions of WebKitGTK reliably crash Emacs, and no-one has been in touch with the WebKitGTK developers, so there are no plans to fix that.

If that’s the case, how about this attached patch to disable this feature with problematic versions of the library?

-- 
Peter Oliver

[0001-Disable-xwidgets-with-recent-webkitgtk-versions-Bug-.patch (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Oliver <p.d.oliver <at> mavit.org.uk>,
 Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Thu, 05 Sep 2024 11:14:42 +0300

> Date: Wed, 4 Sep 2024 12:23:28 +0100 (BST)
> From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
> 
> If my understanding of this bug is correct, newer versions of WebKitGTK reliably crash Emacs, and no-one has been in touch with the WebKitGTK developers, so there are no plans to fix that.
> 
> If that’s the case, how about this attached patch to disable this feature with problematic versions of the library?

> * configure.ac: Accept only webkit2gtk-4.* versions less than 2.41.92.
> ---
>  configure.ac | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 28361be4211..1d0ea314f6a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -4511,10 +4511,11 @@ AC_DEFUN
>  if test "$with_xwidgets" != "no"; then
>    if test "$USE_GTK_TOOLKIT" = "GTK3" && test "$window_system" != "none"; then
>      WEBKIT_REQUIRED=2.12
> -    WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED"
> +    WEBKIT_BROKEN=2.41.92
> +    WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED webkit2gtk-4.1 < $WEBKIT_BROKEN"
>      EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
>      if test "$HAVE_WEBKIT" = "no"; then
> -      WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED"
> +      WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED webkit2gtk-4.0 < $WEBKIT_BROKEN"
>        EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
>      fi
>      HAVE_XWIDGETS=$HAVE_WEBKIT
> -- 
> 2.46.0
> 

Po Lu, any comments to the patch?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Oliver <p.d.oliver <at> mavit.org.uk>,
 Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 07 Sep 2024 12:32:02 +0300

> Date: Wed, 4 Sep 2024 12:23:28 +0100 (BST)
> From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
> 
> If my understanding of this bug is correct, newer versions of WebKitGTK reliably crash Emacs, and no-one has been in touch with the WebKitGTK developers, so there are no plans to fix that.
> 
> If that’s the case, how about this attached patch to disable this feature with problematic versions of the library?
> 
> From 262ea1bb8c47f703819f2df4d920a1f15f2c35b9 Mon Sep 17 00:00:00 2001
> From: Peter Oliver <git <at> mavit.org.uk>
> Date: Wed, 4 Sep 2024 12:12:50 +0100
> Subject: [PATCH] Disable xwidgets with recent webkitgtk versions (Bug#66068)
> 
> * configure.ac: Accept only webkit2gtk-4.* versions less than 2.41.92.
> ---
>  configure.ac | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 28361be4211..1d0ea314f6a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -4511,10 +4511,11 @@ AC_DEFUN
>  if test "$with_xwidgets" != "no"; then
>    if test "$USE_GTK_TOOLKIT" = "GTK3" && test "$window_system" != "none"; then
>      WEBKIT_REQUIRED=2.12
> -    WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED"
> +    WEBKIT_BROKEN=2.41.92
> +    WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED webkit2gtk-4.1 < $WEBKIT_BROKEN"
>      EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
>      if test "$HAVE_WEBKIT" = "no"; then
> -      WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED"
> +      WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED webkit2gtk-4.0 < $WEBKIT_BROKEN"
>        EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
>      fi
>      HAVE_XWIDGETS=$HAVE_WEBKIT
> -- 
> 2.46.0
> 

Po Lu, any objections to this patch?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org, p.d.oliver <at> mavit.org.uk
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 14 Sep 2024 10:45:34 +0300

Ping! Po Lu, could you please respond?

> Cc: 66068 <at> debbugs.gnu.org
> Date: Sat, 07 Sep 2024 12:32:02 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Wed, 4 Sep 2024 12:23:28 +0100 (BST)
> > From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
> > 
> > If my understanding of this bug is correct, newer versions of WebKitGTK reliably crash Emacs, and no-one has been in touch with the WebKitGTK developers, so there are no plans to fix that.
> > 
> > If that’s the case, how about this attached patch to disable this feature with problematic versions of the library?
> > 
> > From 262ea1bb8c47f703819f2df4d920a1f15f2c35b9 Mon Sep 17 00:00:00 2001
> > From: Peter Oliver <git <at> mavit.org.uk>
> > Date: Wed, 4 Sep 2024 12:12:50 +0100
> > Subject: [PATCH] Disable xwidgets with recent webkitgtk versions (Bug#66068)
> > 
> > * configure.ac: Accept only webkit2gtk-4.* versions less than 2.41.92.
> > ---
> >  configure.ac | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 28361be4211..1d0ea314f6a 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -4511,10 +4511,11 @@ AC_DEFUN
> >  if test "$with_xwidgets" != "no"; then
> >    if test "$USE_GTK_TOOLKIT" = "GTK3" && test "$window_system" != "none"; then
> >      WEBKIT_REQUIRED=2.12
> > -    WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED"
> > +    WEBKIT_BROKEN=2.41.92
> > +    WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED webkit2gtk-4.1 < $WEBKIT_BROKEN"
> >      EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
> >      if test "$HAVE_WEBKIT" = "no"; then
> > -      WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED"
> > +      WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED webkit2gtk-4.0 < $WEBKIT_BROKEN"
> >        EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
> >      fi
> >      HAVE_XWIDGETS=$HAVE_WEBKIT
> > -- 
> > 2.46.0
> > 
> 
> Po Lu, any objections to this patch?
> 
> 
> 
> 

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66068 <at> debbugs.gnu.org, p.d.oliver <at> mavit.org.uk
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 14 Sep 2024 20:11:51 +0800

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

> Ping! Po Lu, could you please respond?
>
>> Cc: 66068 <at> debbugs.gnu.org
>> Date: Sat, 07 Sep 2024 12:32:02 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>> > Date: Wed, 4 Sep 2024 12:23:28 +0100 (BST)
>> > From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
>> > 
>> > If my understanding of this bug is correct, newer versions of WebKitGTK reliably crash Emacs, and no-one has been in touch with the WebKitGTK developers, so there are no plans to fix that.
>> > 
>> > If that’s the case, how about this attached patch to disable this feature with problematic versions of the library?
>> > 
>> > From 262ea1bb8c47f703819f2df4d920a1f15f2c35b9 Mon Sep 17 00:00:00 2001
>> > From: Peter Oliver <git <at> mavit.org.uk>
>> > Date: Wed, 4 Sep 2024 12:12:50 +0100
>> > Subject: [PATCH] Disable xwidgets with recent webkitgtk versions (Bug#66068)
>> > 
>> > * configure.ac: Accept only webkit2gtk-4.* versions less than 2.41.92.
>> > ---
>> >  configure.ac | 5 +++--
>> >  1 file changed, 3 insertions(+), 2 deletions(-)
>> > 
>> > diff --git a/configure.ac b/configure.ac
>> > index 28361be4211..1d0ea314f6a 100644
>> > --- a/configure.ac
>> > +++ b/configure.ac
>> > @@ -4511,10 +4511,11 @@ AC_DEFUN
>> >  if test "$with_xwidgets" != "no"; then
>> >    if test "$USE_GTK_TOOLKIT" = "GTK3" && test "$window_system" != "none"; then
>> >      WEBKIT_REQUIRED=2.12
>> > -    WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED"
>> > +    WEBKIT_BROKEN=2.41.92
>> > +    WEBKIT_MODULES="webkit2gtk-4.1 >= $WEBKIT_REQUIRED webkit2gtk-4.1 < $WEBKIT_BROKEN"
>> >      EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
>> >      if test "$HAVE_WEBKIT" = "no"; then
>> > -      WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED"
>> > +      WEBKIT_MODULES="webkit2gtk-4.0 >= $WEBKIT_REQUIRED webkit2gtk-4.0 < $WEBKIT_BROKEN"
>> >        EMACS_CHECK_MODULES([WEBKIT], [$WEBKIT_MODULES])
>> >      fi
>> >      HAVE_XWIDGETS=$HAVE_WEBKIT
>> > -- 
>> > 2.46.0
>> > 
>> 
>> Po Lu, any objections to this patch?

IMHO if recent WebKitGTK releases are to be rejected, xwidgets should
also be disabled on Mac OS, till they are available on up-to-date free
systems again.  But I have no objections to this patch, strictly
speaking.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 66068 <at> debbugs.gnu.org, p.d.oliver <at> mavit.org.uk
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 14 Sep 2024 07:21:50 -0700

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> IMHO if recent WebKitGTK releases are to be rejected, xwidgets should
> also be disabled on Mac OS, till they are available on up-to-date free
> systems again.

The feature is still there if you just use the right version of
WebKitGTK.  Not ideal, but there *is* a work-around.

FWIW, I see no reason to start disabling features on non-free operating
systems due to bugs on free ones.  It's better to just make sure any
bugs are fixed, and move on with our lives.

> But I have no objections to this patch, strictly speaking.

BTW, I didn't see mentioned anywhere in this thread if this bug was
reported to the WebKitGTK maintainers?

Message #112 received at 66068-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068-done <at> debbugs.gnu.org, p.d.oliver <at> mavit.org.uk
Subject: Re: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 21 Sep 2024 12:01:36 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: p.d.oliver <at> mavit.org.uk,  66068 <at> debbugs.gnu.org
> Date: Sat, 14 Sep 2024 20:11:51 +0800
> 
> IMHO if recent WebKitGTK releases are to be rejected, xwidgets should
> also be disabled on Mac OS, till they are available on up-to-date free
> systems again.  But I have no objections to this patch, strictly
> speaking.

OK, so I installed this on the emacs-30 branch, and I'm therefore
closing this bug.

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

From: Doug Maxey <emacs-bugs <at> maxeygroup.tech>
To: 66068 <at> debbugs.gnu.org
Subject: bug#66068: removing the WebKit when webkit2gtk3-2.42.5-1.el9.x86_64
 will not alllow RL9 to configure
Date: Sat, 21 Sep 2024 16:45:06 -0500

With today's tree emacs-30.0.91-54-gc1f2501f, I cannot find a
combination that allows building the X version, either Lucid or GTK3.

The installed version of webkit is webkit2gtk3-2.42.5-1.el9.x86_64.

I even turned off cairo and xwidgets with 
--without-cairo
--without-xwidgets

but no joy on make bootstrap.
---
$ make bootstrap
...
checking for cairo >= 1.8.0... yes
checking for cairo-xcb >= 1.8.0... yes
checking for webkit2gtk-4.1 >= 2.12 webkit2gtk-4.1 < 2.41.92... no
checking for webkit2gtk-4.0 >= 2.12 webkit2gtk-4.0 < 2.41.92... no
configure: error: xwidgets requested but WebKitGTK+ or WebKit framework
not found.
make: *** [Makefile:586: config.status] Error 1
---

-- 
Doug Maxey <emacs-bugs <at> maxeygroup.tech>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Doug Maxey <emacs-bugs <at> maxeygroup.tech>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: removing the WebKit when
 webkit2gtk3-2.42.5-1.el9.x86_64 will not alllow RL9 to configure
Date: Sun, 22 Sep 2024 08:05:44 +0300

> From: Doug Maxey <emacs-bugs <at> maxeygroup.tech>
> Date: Sat, 21 Sep 2024 16:45:06 -0500
> 
> With today's tree emacs-30.0.91-54-gc1f2501f, I cannot find a
> combination that allows building the X version, either Lucid or GTK3.
> 
> The installed version of webkit is webkit2gtk3-2.42.5-1.el9.x86_64.
> 
> I even turned off cairo and xwidgets with 
> --without-cairo
> --without-xwidgets
> 
> but no joy on make bootstrap.
> ---
> $ make bootstrap
> ...
> checking for cairo >= 1.8.0... yes
> checking for cairo-xcb >= 1.8.0... yes
> checking for webkit2gtk-4.1 >= 2.12 webkit2gtk-4.1 < 2.41.92... no
> checking for webkit2gtk-4.0 >= 2.12 webkit2gtk-4.0 < 2.41.92... no
> configure: error: xwidgets requested but WebKitGTK+ or WebKit framework
> not found.
> make: *** [Makefile:586: config.status] Error 1
> ---

Please post the config.log file obtained by running the configure
script after the following commands:

 $ make extraclean
 $ git clean -fdx
 $ git pull
 $ ./autogen.sh
 $ ./configure [...]

where [...] are your usual configure options, but without anything
related to xwidgets (and please show the exact configure options you
use, as your report above doesn't).

The xwidgets option is off by default, so if you reconfigure Emacs
correctly, you should have a build without them (since your webkit2gtk
version is not one of those which can be safely used with Emacs).  The
output of the configure script above seems to indicate that somehow
the configure script was invoked with "--with-xwidgets" option,
because otherwise the "checking for webkit2gtk-4.1" part was not
supposed to have been done.  E.g., on my GNU/Linux system, invoking
the configure script without "--with-xwidgets" option goes straight
from cairo to freetype2 testing, bypassing the webkit2gtk-4.0 test:

  checking for cairo >= 1.8.0... yes
  checking for freetype2... yes
  checking for fontconfig >= 2.2.0... yes

So something in your case is still telling the configure script to
build with xwidgets.  "make bootstrap" re-runs the configure script
with the same options you used last time, so doing that will not
necessarily fix the problem.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Doug Maxey <emacs-bugs <at> maxeygroup.tech>
Cc: 66068 <at> debbugs.gnu.org
Subject: Re: bug#66068: removing the WebKit when
 webkit2gtk3-2.42.5-1.el9.x86_64 will not alllow RL9 to configure
Date: Mon, 23 Sep 2024 14:14:58 +0300

> From: Doug Maxey <emacs-bugs <at> maxeygroup.tech>
> Date: Sun, 22 Sep 2024 21:14:06 -0500
> 
> On Sun, 2024-09-22 at 08:05 +0300, Eli Zaretskii wrote:
> > 
> > ...
> >  $ make extraclean
> >  $ git clean -fdx
> >  $ git pull
> >  $ ./autogen.sh
> >  $ ./configure [...]
> > 
> > where [...] are your usual configure options, but without anything
> > related to xwidgets (and please show the exact configure options you
> > use, as your report above doesn't).
> > 
> > The xwidgets option is off by default, so if you reconfigure Emacs
> > correctly, you should have a build without them (since your
> > webkit2gtk
> > version is not one of those which can be safely used with Emacs). 
> > The
> > output of the configure script above seems to indicate that somehow
> > the configure script was invoked with "--with-xwidgets" option,
> > because otherwise the "checking for webkit2gtk-4.1" part was not
> > supposed to have been done.  E.g., on my GNU/Linux system, invoking
> > the configure script without "--with-xwidgets" option goes straight
> > from cairo to freetype2 testing, bypassing the webkit2gtk-4.0 test:
> > 
> >   checking for cairo >= 1.8.0... yes
> >   checking for freetype2... yes
> >   checking for fontconfig >= 2.2.0... yes
> > 
> > So something in your case is still telling the configure script to
> > build with xwidgets.  "make bootstrap" re-runs the configure script
> > with the same options you used last time, so doing that will not
> > necessarily fix the problem.
> 
> Thank you, the instructions above did fix the issue.
> 
> For the record, my current configure options are
> --prefix=/opt/emacs --with-cairo-xcb --with-imagemagick \
> --with-tree-sitter --with-x --with-x-toolkit=gtk3
> 
> The instance above was with no flags for bootstrap, normally I use
> make bootstrap $configure
> which is all the above options.
> 
> But I missed that bootstrap cached them.

Thanks for telling us, but please in the future use Reply All to keep
the bug tracker on the CC list.

Previous Next

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