Bug 279285 – JSC::IndexingHeader::preCapacity: SIGSEGV on RISC-V when built with GCC and -O2

• Component: JavaScriptCore
• Status: NEW

[Michael Orlitzky]

Created attachment 472483 [details]
libjavascriptcoregtk-btfull.txt

These crashes happen all the time:

[Fri Sep  6 16:52:08 2024] [T16948] WebKitWebProces[16948]: unhandled signal 11 code 0x1 at 0x0000003fd0800004 in libjavascriptcoregtk-6.0.so.1.2.7[3ff2e00000+dd2000]

Today I was finally able to get a backtrace... after about 6 hours of struggling -- this should be a lot easier:

#0  0x0000003ff34b446e in JSC::IndexingHeader::preCapacity (this=0x3fe2700000, structure=<optimized out>) at /var/lib/portage/tmp/portage/net-libs/webkit-gtk-2.44.3-r600/work/webkitgtk-2.44.3/Source/JavaScriptCore/runtime/IndexingHeaderInlines.h:36
No locals.
#1  JSC::Butterfly::createOrGrowPropertyStorage (oldButterfly=0x3fe2700008, vm=..., intendedOwner=0x3fe1855480, structure=<optimized out>, oldPropertyCapacity=4, newPropertyCapacity=8) at /var/lib/portage/tmp/portage/net-libs/webkit-gtk-2.44.3-r600/work/webkitgtk-2.44.3/Source/JavaScriptCore/runtime/ButterflyInlines.h:138
        preCapacity = <optimized out>
        indexingPayloadSizeInBytes = <optimized out>
        hasIndexingHeader = <optimized out>
        result = <optimized out>
        __PRETTY_FUNCTION__ = <optimized out>
        preCapacity = <optimized out>
        indexingPayloadSizeInBytes = <optimized out>
        hasIndexingHeader = <optimized out>
        result = <optimized out>

[Michael Orlitzky]

When this happens I always get a second WebKitWebProcess crash afterwards, this one from libGLESv2, in the GLContext destructor. It's probably related to the JSC crash, but just in case it is of independent interest:

#0  0x0000003fb2f8ab8a in glBindFramebuffer (target=36160, framebuffer=<optimized out>) at /var/lib/portage/tmp/portage/media-libs/libglvnd-1.7.0/work/libglvnd-v1.7.0-.lp64d/src/generate/g_glapi_mapi_glesv2_tmp.h:11906
        _tbl = 0x0
        _func = <error reading variable _func (Cannot access memory at address 0x220)>
#1  0x0000003fbd55230a in WebCore::GLContext::~GLContext (this=this@entry=0x3fb4964000, __in_chrg=<optimized out>) at /var/lib/portage/tmp/portage/net-libs/webkit-gtk-2.44.3-r600/work/webkitgtk-2.44.3/Source/WebCore/platform/graphics/egl/GLContext.cpp:401
        display = 0x3fb4d19550
        display = <optimized out>
#2  0x0000003fbd522758 in std::default_delete<WebCore::GLContext>::operator() (this=<optimized out>, __ptr=0x3fb4964000) at /usr/lib/gcc/riscv64-unknown-linux-musl/14/include/g++-v14/bits/unique_ptr.h:93
No locals.

[Radar WebKit Bug Importer]

<rdar://problem/135976943>

[Mark Lam]

What are the reproduction steps for manifesting this crash?
What is the website or payload that makes it crash?
Do you have an isolated test case?

[Michael Orlitzky]

It would never be that easy.

First, I think it only happens with -O2, and not -O1. (I haven't tried -O3 yet). I've been running an -O1 build pretty much since I opened this bug, and haven't had a JSC crash since. I'm now rebuilding 2.44.4 at -O2 again to make sure that the crashes come back.

The crashes are "random," but consistent. I have a feeling that they tend to happen more often on javascript-heavy websites like github.com, and sites that have google analytics / recaptcha.

It has happened several times on e.g.

  https://github.com/sophgo/bootloader-riscv/blob/master/scripts/envsetup.sh

but if I restart epiphany and go back to that URL, it's fine... for a while.

[Michael Orlitzky]

The libGLESv2 thing is a red herring by the way. Those segfaults happen even when I close my browser normally (I opened a new bug for them).

[Mark Lam]

Michael, do you by any chance have a Mac?  If so, are you able to reproduce this on a Mac in Safari or MiniBrowser?

I don't work on Epiphany.  So, if this is an Epiphany / GTK only issue, then I'll have to leave it to the GTK folks.

[Michael Orlitzky]

No, Linux, sorry. I don't think it has anything to do with epiphany/GTK but I can't prove it.

[Mark Lam]

Michael C, are you seeing such crashes on Epiphany?

[Michael Orlitzky]

Probably the path of least resistance is for me to hit Ctrl-C on that 2.44.4 build and hack -DENABLE_MINIBROWSER into the cmake invocation. I hate to lose eight hours of compile time, but at least it's the weekend.

[Michael Catanzaro]

No, I've never seen this before.

(Even if it was somehow platform-specific, which seems unlikely, WebKitGTK maintainers don't know how to help with JSC issues anyway.)

The backtrace looks good though.

[Michael Orlitzky]

MiniBrowser is trying its best to stop me, stating "The URL can't be shown" whenever I type in a URL manually, but the first URL passed to it on the CLI always works:

  * The crashes are back with -O2
  * They happen in MiniBrowser, too
  * The backtrace looks about the same

[Michael Catanzaro]

So the crashes only happen when building with -O2 and not with -O1? That's interesting.

Out of curiosity, what happens if you build with Clang rather than GCC?

[Michael Orlitzky]

(In reply to Michael Catanzaro from comment #12)
> So the crashes only happen when building with -O2 and not with -O1? That's
> interesting.
> 
> Out of curiosity, what happens if you build with Clang rather than GCC?

I'll keep using it, but I think the JSC crashes are gone.

[Mark Lam]

(In reply to Michael Orlitzky from comment #13)
> (In reply to Michael Catanzaro from comment #12)
> > So the crashes only happen when building with -O2 and not with -O1? That's
> > interesting.
> > 
> > Out of curiosity, what happens if you build with Clang rather than GCC?
> 
> I'll keep using it, but I think the JSC crashes are gone.

Just to clarify, are you saying the crashes only manifests with GCC, and does not manifest with Clang?

[Michael Orlitzky]

(In reply to Mark Lam from comment #14)
> 
> Just to clarify, are you saying the crashes only manifests with GCC, and
> does not manifest with Clang?

Correct. Clang v18.1.8 and GCC v14.2.0.

[Michael Catanzaro]

And specifically only at -O2 optimization level, so that narrows things down significantly. It could be a GCC bug, or it could be undefined behavior in JSC.

Since almost all distros build with GCC and -O2, yet only you are complaining, it might also occur only in combination with one of the other compiler flags you use.

[Michael Orlitzky]

(In reply to Michael Catanzaro from comment #16)
> And specifically only at -O2 optimization level, so that narrows things down
> significantly. It could be a GCC bug, or it could be undefined behavior in
> JSC.
> 
> Since almost all distros build with GCC and -O2, yet only you are
> complaining, it might also occur only in combination with one of the other
> compiler flags you use.

My CFLAGS are "-O2 -pipe -mabi=lp64d -march=rv64gc -mtune=thead-c906" which should be unexciting except maybe for the -mtune=thead-c906. AFAIK it only provides a few optimization hints:

https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573305.html

I've just upgraded to gcc-14.2.1 and was planning to re-try; I could drop the -mtune at the same time.

I think the most likely explanation is that few people are using RISC-V, and fewer of those are using epiphany, and fewer of those are building their own, and fewer of those are using the latest versions of everything, and fewer of those would be willing to spend a few days rebuilding webkit to debug if it crashes. We may be down to {me}.

[Michael Catanzaro]

You didn't mention you were using RISC-V until comment #17. Yeah, that's indeed more likely.

[Michael Orlitzky]

One other thing that might be relevant is that I have to build with -DENABLE_JIT=OFF to work around bug 271371.

[Mark Lam]

AFAIK, the RISC V port is not an officially supported port.  For example, there are no EWS bots for it.  I don't even know who the maintainers are.  Looks like Zan Dobersek according to git blame.

Zan, have you seen this RISC V + GCC only crash before?

[Michael Orlitzky]

The crashes persist with gcc-14.2.1 and without the -mtune in my C(XX)FLAGS.