Bug 234004 - Crash issue observed in JIT operationOptimize method
Summary: Crash issue observed in JIT operationOptimize method
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: Other
Hardware: Other Linux
: P1 Blocker
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-12-08 07:17 PST by Bharanitharan
Modified: 2022-02-13 04:16 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bharanitharan 2021-12-08 07:17:20 PST
We have faced the crash issue in JIT compiler while continuous playback the OnDemand content we have used webkit v1.16.5 in ARM platform, the caller stack of the crash pointer API name is operationOptimize .We could not able to debug this issue due to continuously hit the callback from different caller. We suspect any CFLAGS need to be additionally added for that ?
Kindly provide the solution for this issue.
Comment 1 Radar WebKit Bug Importer 2021-12-15 08:07:37 PST
<rdar://problem/86523188>
Comment 2 Smoley 2022-01-18 10:38:12 PST
Thanks for filing, can you please provide a test case or a crash log?
Comment 3 Bharanitharan 2022-02-10 09:28:50 PST
#1 We have observed crash issue while performed the continuous playback(around 20mins) in an ondemand application.
#2 The exception raised from JIT optimization, points the exact caller stack as operationOptimize().
#3 We are currently using the Webkit v2.16.5 in ARM 32Bit architecture and using DFG_JIT instead of FTL_JIT.
#4 We could not able to trace it further due to optimization callback continuously triggered from different caller. So could anyone support me to narrow down the root cause for this issue.
Comment 4 Bharanitharan 2022-02-10 09:30:05 PST
(In reply to Smoley from comment #2)
> Thanks for filing, can you please provide a test case or a crash log?

Ok, Thanks for your kind reply, I will share it by tomorrow.
Comment 5 Yusuke Suzuki 2022-02-10 10:09:04 PST
OK, this is an issue in ARMv7 32bit (note that this is maintained by Igalia since Apple does not use 32bit JIT).
Comment 6 Bharanitharan 2022-02-11 06:33:48 PST
(In reply to Yusuke Suzuki from comment #5)
> OK, this is an issue in ARMv7 32bit (note that this is maintained by Igalia
> since Apple does not use 32bit JIT).

From your comment, we understood this issue is specific to ARMv7 32Bit architecture? Whether there is any resolution for this issue? Please kindly help.
Comment 7 Yusuke Suzuki 2022-02-11 10:11:31 PST
(In reply to Bharanitharan from comment #6)
> (In reply to Yusuke Suzuki from comment #5)
> > OK, this is an issue in ARMv7 32bit (note that this is maintained by Igalia
> > since Apple does not use 32bit JIT).
> 
> From your comment, we understood this issue is specific to ARMv7 32Bit
> architecture? Whether there is any resolution for this issue? Please kindly
> help.

I mean, Igalia folks can look into it.
Comment 8 Bharanitharan 2022-02-13 04:16:55 PST
(In reply to Bharanitharan from comment #4)
> (In reply to Smoley from comment #2)
> > Thanks for filing, can you please provide a test case or a crash log?
> 
> Ok, Thanks for your kind reply, I will share it by tomorrow.


We have attached the crash log for your reference:
In crash issue observed case we have faced the below prints are continuously running so could you please help to find the root cause of this issue.

JITInlines.h 157> Entry appendCallWithExceptionCheck
AssemblyHelpers.cpp 389> Entry emitExceptionCheck 
AssemblyHelpers.cpp 319> Entry callExceptionFuzz

Crash Log:
+++++++++++
Thread 18 "WebkitBrowser" received signal SIGSEGV, Segmentation fault
[Switching to LWP1802]

0x8a073860 in  ?? ()

(gdb) bt
#0  0x8a073860	in ?? ()
#1  0x019d4df0	in operationOptimize()
#2  0xfffffffa	in ?? ()

Backtrace Stopped : Previous frame identical to this frame (Corrupt stack?)