Open Bug 1105342 Opened 10 years ago Updated 1 year ago

crash in js::jit::BaselineScript::icEntryFromPCOffset(unsigned int)

Categories

(Core :: JavaScript Engine, defect)

All
macOS
defect

Tracking

()

Tracking Status
firefox47 --- affected
firefox48 --- affected
firefox49 --- affected
firefox-esr45 --- affected
firefox50 --- affected
firefox51 --- affected
firefox52 --- wontfix
firefox54 --- affected

People

(Reporter: BenWa, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, testcase-wanted, Whiteboard: qa-not-actionable)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-d1d8247c-00ee-4b17-84c6-43ef42141126.
=============================================================

I saw this on reddit:
http://www.reddit.com/r/firefox/comments/2ngnid/firefox_constantly_crashes_on_os_x_mavericks_2013/

But there seems to be a lot of volume on this crash in general. I'd suggest reaching out there since the user can reproduce the issue.

ni?djvj since it's baseline.
Flags: needinfo?(kvijayan)
This signature currently sits at #39 on crash-stats for Firefox 33.1 @ 0.34%. Here is some further information from crash-stats to help with debugging.

Comments:
* a couple mentions iBoss Security Threat Console
* a couple mentions of composing email in Yahoo/Gmail
* a couple mentions of watching video
* one mention of entering a signature on a DotLoop purchase

URLs:
* Top URL is facebook.com with 99 reports
* 2nd URL is amctheatres.com with 45 reports

Addons:
* 22% of the reports have Adblock Plus installed

Firefox Versions:
* 61% of the reports are with Firefox 33.1
* reports go back to Firefox 29, include Fennec/Seamonkey

Platform/Architecture:
* 56% of the reports are on Windows 7
* 14% of the reports are on Windows 8.1
*  9% of the reports are on Windows XP
*  7% of the reports are on Linux
*  3% of the reports are on Mac OS 10.9
* 86% of the reports are on 32-bit systems

Plugins:
* Flash is only report once, unlikely a factor

Uptime:
* 52% of the reports happen after more than one hour
* 77% of the reports happen after more than 15 minutes

Devices:
* 14% of the reports happen with a Motorola MB860 (the most reported device)
* the rest are scattered across numerous devices

Graphics Adapters:
* Intel GPUs are reported in most of the crashes

Top Modules for 33.1 on Windows:
* 100% nssckbi.dll
* 100% nssdbm3.dll
* 100% softokn3.dll
* 100% freebl3.dll
* 100% rasadhlp.dll
* 100% browsercomps.dll
* 100% winrnr.dll
* 100% ntmarta.dll
* 100% winsta.dll
* 100% mswsock.dll
* 100% dnsapi.dll
I got this crash today on inbound in Linux x86_64

Program received signal SIGSEGV, Segmentation fault.
js::jit::BaselineScript::icEntryFromPCOffset (this=<optimized out>, pcOffset=pcOffset@entry=64) at /home/hub/source/mozilla/src/js/src/jit/BaselineJIT.cpp:585
585	    MOZ_CRASH("Invalid PC offset for IC entry.");
Missing separate debuginfos, use: debuginfo-install flac-libs-1.3.1-1.fc21.x86_64 gsm-1.0.13-12.fc21.x86_64 json-c-0.12-5.fc21.x86_64 libattr-2.4.47-9.fc21.x86_64 libcap-2.24-7.fc21.x86_64
(gdb) where
#0  0x00007ffff57c78c8 in js::jit::BaselineScript::icEntryFromPCOffset(unsigned int) (this=<optimized out>, pcOffset=pcOffset@entry=64)
    at /home/hub/source/mozilla/src/js/src/jit/BaselineJIT.cpp:585
#1  0x00007ffff581ccff in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, uint32_t, JS::Value*, JS::MutableHandleValue) (this=<synthetic pointer>)
    at /home/hub/source/mozilla/src/js/src/jit/BaselineDebugModeOSR.h:56
#2  0x00007ffff581ccff in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, uint32_t, JS::Value*, JS::MutableHandleValue) (cx=0x7ffff7d98990, frame=0x7ffffffeee90, stub_=0x7fffd9cfb820, argc=1, vp=0x7ffffffeee40, res=...) at /home/hub/source/mozilla/src/js/src/jit/BaselineIC.cpp:9301
#3  0x00007ffff7f064d0 in  ()
#4  0x00007fffe73a9830 in  ()
#5  0x00007ffffffeedf8 in  ()
#6  0x00007ffff7d989c8 in  ()
Python Exception <type 'exceptions.OverflowError'> long too big to convert: 
#7  0xffffffffffffffff in  ()#8  0x00007ffff7b6e740 in js::jit::DoCallFallbackInfo () at /home/hub/source/mozilla/src/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so
#9  0x00007fffe7350a00 in  ()
#10 0x00007fffe8d12f54 in  ()
#11 0x0000000000000482 in  ()
#12 0x00007ffffffeee90 in  ()
#13 0x00007fffd9cfb820 in  ()
#14 0x0000000000000001 in  ()
#15 0x00007ffffffeee40 in  ()
Python Exception <type 'exceptions.OverflowError'> long too big to convert: 
Python Exception <type 'exceptions.OverflowError'> long too big to convert: 
Python Exception <type 'exceptions.OverflowError'> long too big to convert: 
#16 0xffffffffffffffff in  ()#17 0xffffffffffffffff in  ()#18 0xffffffffffffffff in  ()#19 0x00007ffffffeeed0 in  ()
#20 0x00007fffd9cfb820 in  ()
#21 0x00007fffe0d9aedc in  ()
#22 0x0000000000000601 in  ()
Python Exception <type 'exceptions.OverflowError'> long too big to convert: 
Python Exception <type 'exceptions.OverflowError'> long too big to convert: 
Python Exception <type 'exceptions.OverflowError'> long too big to convert: 
Python Exception <type 'exceptions.OverflowError'> long too big to convert: 
#23 0xffffffffffffffff in  ()#24 0xffffffffffffffff in  ()#25 0xffffffffffffffff in  ()#26 0xffffffffffffffff in  ()#27 0x00007ffff599ee27 in js::CloneFunctionObject(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>, js::gc::AllocKind, js::NewObjectKind) (this=0x7fffca548588) at /home/hub/source/mozilla/src/js/src/gc/Barrier.h:452
#28 0x00007ffff599ee27 in js::CloneFunctionObject(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>, js::gc::AllocKind, js::NewObjectKind) (v=0xfffc7fffca548580, this=0x7fffca548588)
    at /home/hub/source/mozilla/src/js/src/gc/Barrier.h:531
#29 0x00007ffff599ee27 in js::CloneFunctionObject(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>, js::gc::AllocKind, js::NewObjectKind) (newType=0xfffc7fffca548580, this=0x7fffca548580) at /home/hub/source/mozilla/src/js/src/jsobjinlines.h:118
#30 0x00007ffff599ee27 in js::CloneFunctionObject(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>, js::gc::AllocKind, js::NewObjectKind) (cx=0x0, fun=..., parent=..., allocKind=<optimized out>, newKindArg=js::GenericObject) at /home/hub/source/mozilla/src/js/src/jsfun.cpp:2101
If you think it is a different one, let me know I'll file a new bug.
I believe I also hit this bug on Firefox 39 running on Fedora 21 x86-64. Was browsing facebook with a few tabs open (and NoScript only allowing facebook's content).

r10: 0x0000000000000000
r11: 0x0000000000000028
r12: 0x0000000000000058
r13: 0x0000000000000000
r14: 0x00007fa2e1ff47c0
r15: 0x0000000000000001
r8: 0x00007fa3585d4840
r9: 0x0000000000000025
rax: 0x00000000000000b8
rbp: 0x00007ffd3bc6e140
rbx: 0x00007ffd3bc6e000
rcx: 0x0000000000000000
rdi: 0x0000000000000000
rdx: 0x00000000000000b8
rip: 0x00007fa357e682f0
rsi: 0x0000000000000025
rsp: 0x00007ffd3bc6dd18

libxul.so@0x23be2f0 js::jit::BaselineScript::icEntryFromPCOffset(unsigned int)
   0x00000000023be2f0 <+0>:	mov    0x7c(%rdi),%r9d
   0x00000000023be2f4 <+4>:	mov    %r9,%rdx
libxul.so@0x2412ab1 js::jit::BailoutIonToBaseline(JSContext*, js::jit::JitActivation*, js::jit::JitFrameIterator&, bool, js::jit::BaselineBailoutInfo**, js::jit::ExceptionBailoutInfo const*)
libxul.so@0x2b2a83f ????
libxul.so@0x2442122 js::jit::JitContext::~JitContext
libxul.so@0x23ba47b js::jit::MacroAssembler::~MacroAssembler
libxul.so@0x2495c63 js::jit::GetPropertyIC::tryAttachNative(JSContext*, JS::Handle<JSScript*>, js::jit::IonScript*, JS::Handle<JSObject*>, JS::Handle<js::PropertyName*>, void*, bool*)

It appears it's calling icEntryFromPCOffset on a null BaselineScript object?
This is going to be hard to work on without a reproducible case.  The |icEntryFromPCOffset| code maps a bytecode offset to an Inline Cache table entry for baseline.

This crash occurs because that mapping is failing.  Either we're getting a bad pc, or there is some bug in the mapping code that is failing to map the PC even though it should.

Leaving needinfo on for this so it remains on my dashboard.
Crash Signature: [@ js::jit::BaselineScript::icEntryFromPCOffset(unsigned int)] → [@ js::jit::BaselineScript::icEntryFromPCOffset(unsigned int)] [@ js::jit::BaselineScript::icEntryFromPCOffset]
Crash volume for signature 'js::jit::BaselineScript::icEntryFromPCOffset':
 - nightly (version 50): 1 crash from 2016-06-06.
 - aurora  (version 49): 7 crashes from 2016-06-07.
 - beta    (version 48): 57 crashes from 2016-06-06.
 - release (version 47): 164 crashes from 2016-05-31.
 - esr     (version 45): 130 crashes from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          0          1          0          0          0          0          0
 - aurora           1          1          0          2          2          1          0
 - beta             9         13         12          4          5          8          1
 - release         28         16         23         23         30         24          6
 - esr             12         10         12         11         19         20          9

Affected platforms: Windows, Mac OS X, Linux
I would leave the bug open and keep an eye on it.  I need to find a free week or so to try really hard to repro it, and it might still not repro.  I have some higher prio bugs/crashes to fix and follow up on ATM.
Flags: needinfo?(kvijayan)
Actually, I'm going to needinfo? jan on this, since he may have time to take a look at it.
Flags: needinfo?(jdemooij)
I looked a bit into this but I've no idea what's going on. URLs look pretty random as well. I've a large number of other requests atm but I added it to my TODO list.
Flags: needinfo?(jdemooij)
Crash volume for signature 'js::jit::BaselineScript::icEntryFromPCOffset':
 - nightly (version 51): 1 crash from 2016-08-01.
 - aurora  (version 50): 0 crashes from 2016-08-01.
 - beta    (version 49): 69 crashes from 2016-08-02.
 - release (version 48): 32 crashes from 2016-07-25.
 - esr     (version 45): 223 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       0       0       0
 - aurora        0       0       0
 - beta         25      20       6
 - release      13       7       8
 - esr          21      27      25

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly #727
 - aurora
 - beta    #588      #367
 - release #1565     #737
 - esr     #254
Crash volume for signature 'js::jit::BaselineScript::icEntryFromPCOffset':
 - nightly (version 54): 2 crashes from 2017-01-23.
 - aurora  (version 53): 0 crashes from 2017-01-23.
 - beta    (version 52): 28 crashes from 2017-01-23.
 - release (version 51): 55 crashes from 2017-01-16.
 - esr     (version 45): 743 crashes from 2016-08-03.

Crash volume on the last weeks (Week N is from 01-30 to 02-05):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0
 - aurora        0
 - beta         16
 - release      36       0
 - esr          28      40      29      45      26      22      29

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly #308
 - aurora
 - beta    #502      #256
 - release #697      #400
 - esr     #350
Too late for firefox 52, mass-wontfix.
Whiteboard: qa-not-actionable
Severity: critical → S2

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3
Crash Signature: [@ js::jit::BaselineScript::icEntryFromPCOffset(unsigned int)] [@ js::jit::BaselineScript::icEntryFromPCOffset] → [@ js::jit::BaselineScript::icEntryFromPCOffset] [@ js::jit::BaselineScript::icEntryFromPCOffset]
You need to log in before you can comment on or make changes to this bug.