| Summary: | REGRESSION(261993@main): Reddit crashes in MiniBrowser | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Kdwk <kdwkleung> | ||||
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED DUPLICATE | ||||||
| Severity: | Normal | CC: | bugs-noreply, Hironori.Fujii, mcatanzaro | ||||
| Priority: | P2 | ||||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
|
Description
Kdwk
2023-03-23 04:58:49 PDT
Backtrace? Created attachment 465552 [details]
Backtrace for crashing WebProcess
Would this be good?
No, because you didn't take that with gdb or install any debuginfo. Well looks like coredumpctl gdb isn’t working for me… are you able to reproduce it on your end?0 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 You can confirm if it's a JIT bug by disabling JIT. export JSC_useJIT=0 https://trac.webkit.org/wiki/EnvironmentVariables Looks like 2.40.0 is OK, so this problem is introduced recently. (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. *** This bug has been marked as a duplicate of bug 254633 *** *** This bug has been marked as a duplicate of bug 254752 *** |