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

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66068 <at> debbugs.gnu.org
Subject: 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

Previous Next

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