Bug 254325 – REGRESSION(261993@main): Reddit crashes in MiniBrowser

• Component: JavaScriptCore
• Status: RESOLVED DUPLICATE

[Kdwk]

In the latest WebKitGTK MiniBrowser (locally compiled), visiting reddit.com crashes the WebProcess -- "** (MiniBrowser:17): WARNING **: 04:56:38.751: WebProcess CRASHED"

[Michael Catanzaro]

Backtrace?

[Kdwk]

Created attachment 465552 [details]
Backtrace for crashing WebProcess

Would this be good?

[Michael Catanzaro]

No, because you didn't take that with gdb or install any debuginfo.

[Kdwk]

Well looks like coredumpctl gdb isn’t working for me… are you able to reproduce it on your end?0

[Michael Catanzaro]

Uh, I can reproduce the crash, but my backtrace is 115 frames of nothing:

#0  0x00007f6fc021f2f7 in ?? ()
#1  0x000000000000000a in ?? ()
#2  0x00007f6f970b7960 in ?? ()
#3  0x00007f843a400000 in ?? ()
#4  0x000000019087b8e0 in ?? ()
#5  0x00007f6f90e48380 in ?? ()
#6  0x00007f843a904800 in ?? ()
#7  0x00007f6f90e31d00 in ?? ()
#8  0x00007f6f970b7c80 in ?? ()
#9  0x00007f6f90d2b740 in ?? ()
#10 0x00007f844e153fc0 in ?? ()

If I run 'thread apply all bt' then I see I have good debuginfo for every thread except the thread that is crashing, so there's nothing wrong with debuginfo. So now we know why building with -g didn't seem to work for you.

I've never seen a crash like this before. I wonder if the stack is corrupted here? I'm not sure what we can do to resolve it because:

(gdb) disassemble
No function contains program counter for selected frame.

Even at the assembly language level, we have no clue where it is crashing. We've just got nothing. I think there's a fairly high chance that something is wrong with JSC, but without a backtrace there's no way for me to prove it.

In the off chance that this might be useful:

(gdb) info registers
rax            0xa                 10
rbx            0x7f844e153fc0      140206222426048
rcx            0x7f6e00005980      140110423153024
rdx            0x7f6f90e4c160      140117149008224
rsi            0x7f6f970b7ce0      140117252209888
rdi            0x7f6f90e4c160      140117149008224
rbp            0x7ffef6de4970      0x7ffef6de4970
rsp            0x7ffef6de4900      0x7ffef6de4900
r8             0x7f6e00005980      140110423153024
r9             0x7f6f953d58f0      140117221923056
r10            0xa                 10
r11            0x0                 0
r12            0x7f6f9efd4210      140117385495056
r13            0x7f6f950b2480      140117218632832
r14            0xfffe000000000000  -562949953421312
r15            0xfffe000000000002  -562949953421310
rip            0x7f6fc021f2f7      0x7f6fc021f2f7
eflags         0x10246             [ PF ZF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

[Fujii Hironori]

You can confirm if it's a JIT bug by disabling JIT.
export JSC_useJIT=0
https://trac.webkit.org/wiki/EnvironmentVariables

[Michael Catanzaro]

Looks like 2.40.0 is OK, so this problem is introduced recently.

[Michael Catanzaro]

(In reply to Fujii Hironori from comment #6)
> You can confirm if it's a JIT bug by disabling JIT.
> export JSC_useJIT=0
> https://trac.webkit.org/wiki/EnvironmentVariables

Good idea. The crash actually does go away with that environment variable set, so something bad must have landed in JSC. Changing component.

This should be bisectable, so I'll try to narrow it down.

[Michael Catanzaro]

*** This bug has been marked as a duplicate of bug 254633 ***

[Michael Catanzaro]

*** This bug has been marked as a duplicate of bug 254752 ***