Bug 278230 – REGRESSION(280197@main): [GTK] Crash using 2.44.3 on NVIDIA

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Óscar]

After an update of webkit from version 2.44.2 to 2.44.3 webkit-dependent applications (like Cinny) show a blank window. If you try to open these applications directly in epiphany (e.g. https://app.cinny.in/) it shows a sad face with an oops message.

[Adrian Perez]

After some back and forth testing with some help from Oscar, we have
found that reverting 280197@main  (bug #271477) solves the problem
and makes things work again.

[Carlos Garcia Campos]

Could you provide the output of webkit://gpu?

[Óscar]

Yes, of course, no problem, I attach it as `webkit_gpu.json`.

[Óscar]

Created attachment 472197 [details]
The content of accessing with epiphany to webkit://gpu

[Carlos Garcia Campos]

hmm, this is weird, with gtk 4.14 it should be using be the GdkDmabufTextureBuilder API, I don't understand why building the texture a bit later makes it fail. There's an error message when gdk_dmabuf_texture_builder_build fails, do you see any message in stderr?

[Óscar]

Nothing special, it just says:

(epiphany:17467): epiphany-WARNING **: 10:08:43.779: Web process crashed

And it shows the page that reads:

Oops!

Something went wrong while displaying this page. Please reload or visit a different page to continue.

And if I press reload it says the same thing again by console:

(epiphany:17467): epiphany-WARNING **: 10:09:46.496: Web process crashed

[Carlos Garcia Campos]

Ah, so it's not that we don't render anything, it's that th web process is crashing? Then we need a backtrace of the web process.

[Óscar]

Created attachment 472219 [details]
WebKitWebProcess coredump

[Óscar]

I attach the coredump to see if it is valid for you.

I noticed that the ArchLinux version webkitgtk-6.0-2.44.3-3 works for me. As far as I see in that version applies this patch https://gitlab.archlinux.org/archlinux/packaging/packages/webkitgtk-6.0/-/commit/6cfd95a18b6b809b6df709429a846ce0ee5b7b6d#6d4b9cb60e84aaccad0e74c87b9ee1973b19b434 that reverts the commit 279c9d7963182cc35cf4e0bfebe87df2d83eaef8. I comment it in case it sheds more light on the problem.

[Óscar]

Created attachment 472220 [details]
WebKitWebProcess coredump but in txt mode

Output of:
coredumpctl gdb PID
thread apply all bt

[Michael Catanzaro]

(In reply to Óscar from comment #9)
> I attach the coredump to see if it is valid for you.

Please don't. It's only useful on your computer.

(In reply to Óscar from comment #10)
> Created attachment 472220 [details]
> WebKitWebProcess coredump but in txt mode
> 
> Output of:
> coredumpctl gdb PID
> thread apply all bt

This is what we need, except we need you to install debuginfo first. See these instructions: https://handbook.gnome.org/issues/stack-traces.html

That said, the best we can hope for is to see frames 4 and 5:

Thread 1 (Thread 0x763dc0c006c0 (LWP 34)):
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x0000763e7d2a5463 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78
#2  0x0000763e7d24c120 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x0000763e7d2334c3 in __GI_abort () at abort.c:79
#4  0x0000763e7b307846 in ?? ()
#5  0x0000763dc0bf62f0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I wonder why the stack is corrupted.

[Óscar]

Created attachment 472223 [details]
WebKitWebProcess new coredump

New coredump where I believe the stack is not corrupted.

[Óscar]

Created attachment 472224 [details]
WebKitWebProcess new coredump bt full

Now running

coredumpctl gdb PID
bt full

I don't know if it will be worth much, it seems to say a lot less.

[Michael Catanzaro]

Unfortunately the backtrace is useless. All I can see is something is wrong in JavaScriptCore. We might need to reassign this bug to the JSC component.

Can you please check to be sure the bug is truly caused by NVIDIA graphics? That sounded plausible at first, but now that it looks like a problem in JSC rather than a graphics problem, it seems weirder.

[Michael Catanzaro]

And I can see you did install debuginfo for /usr/lib/libjavascriptcoregtk-6.0.so.1 using debuginfod (thanks) so you did everything properly. JSC is just complicated; I treat it as a magic black box that only JSC developers know how to debug....

[Michael Catanzaro]

(In reply to Adrian Perez from comment #1)
> After some back and forth testing with some help from Oscar, we have
> found that reverting 280197@main  (bug #271477) solves the problem
> and makes things work again.

Um, wait, I forgot we already tracked down the regression commit. Clearly this change has nothing to do with JavaScriptCore. I don't understand the backtrace.

Hello, the issue is still present in Fedora 40 with Gnome 46.4

[Adrian Perez]

@Óscar, I think you have tried 2.46.x and that works now for you.
Could you confirm? Thanks!

[Óscar]

@Adrian Yes, I have not had any more problems of this kind, I think that the bug can be closed.

Thank you all for your help!