Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Hi Alberto, Sebastian,

Sebastian Krzyszkowiak wrote on Thu, Sep 29, 2022 at 06:15:56PM +0200:
> the patch that sets setAllowsServerPreconnect does not fix the
> original issue, however, this one does:
> https://github.com/WebKit/WebKit/pull/4790
> 
> With this applied on top of your recent backport of 2.38.0, WebKit
> becomes somewhat usable on arm64 in bullseye. It still crashes on some
> pages (such as Twitter), but in a different way (somewhere in JSC)
> which probably deserves a separate issue.

Thank you for finding this other PR -- I can confirm that fixes the
original issue which crashed almost immediately on any page, and also
confirm there are leftover crashes with a clang build on this patch.

Here's the backtrace I get:
(gdb) bt
#0  codeBlock () at ../Source/JavaScriptCore/interpreter/RegisterInlines.h:41
#1  codeBlock () at ../Source/JavaScriptCore/interpreter/CallFrameInlines.h:62
#2  operationArithNegateProfiledOptimize () at ../Source/JavaScriptCore/jit/JITOperations.cpp:3361
#3  0x0000ffff74148358 in ?? ()
#4  0x0000ffff2ed44080 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

unfortunately it looks like gdb doesn't manage to unwind it properly (or
indeed corrupted), so that might be difficult to debug.

Since gcc build appears to fix the issue I think that's the way to go
for bullseye, at least until we understand where that makes a
difference...

Sebastian Krzyszkowiak wrote on Fri, Sep 30, 2022 at 01:01:55PM +0200:
> I can still see some backtraces showing up in logs due to preconnect
> attempts, so applying PR 4790 will likely still be a good idea, but it
> doesn't bring down the whole process anymore.

I agree on principle; out of curiousity where did you see these logs?
I do not see anything on stdout/stderr with the gcc build, but I would
assume this to be logged elsewhere or perhaps only if some magic env var
is set?

Thanks,
-- 
Dominique