bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort


From: Po Lu
Subject: bug#66068: 30.0.50; xwidget-webkit-browse-url makes Emacs abort
Date: Sat, 30 Sep 2023 19:52:03 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

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

> On Mon, 25 Sep 2023 12:22:19 +0200 Stephen Berman <stephen.berman@gmx.net> 
> wrote:
>
>> On Mon, 25 Sep 2023 17:25:43 +0800 Po Lu <luangruo@yahoo.com> wrote:
>>
>>> Stephen Berman <stephen.berman@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@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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]