Closed Bug 459869 Opened 16 years ago Closed 15 years ago

TM: (x86_64) Crash in js_FillPropertyCache when running mootools slickspeed benchmark

Categories

(Core :: JavaScript Engine, defect, P2)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.9.1b2

People

(Reporter: Swatinem, Assigned: dvander)

References

(
URL
)

Details

(Keywords: crash) 

Running the mootools slickspeed test, Firefox crashes with Prototype 1.6.0.2 "body" selector test.

0x00007fc6556de79f in js_FillPropertyCache (cx=0x7fc63f186400, 
    obj=0x7fc636c189c0, kshape=25319, scopeIndex=0, protoIndex=1, 
    pobj=0x7fc63a6a4f00, sprop=0x7fc63a6138e0, entryp=0x7fff5e0d03d0)
    at /mnt/data/Coding/mozilla-central/js/src/jsinterp.cpp:203
203	                if (VALUE_IS_FUNCTION(cx, v)) {
(gdb) p *cx
$1 = {links = {next = 0x7fc63f187000, prev = 0x7fc63f174800}, 
  operationCount = 17602514, xmlSettingFlags = 0 '\0', padding = 0 '\0', 
  display = {0x0, 0x7fff5e0d0c60, 0x7fc63c148400, 0x0 <repeats 13 times>}, 
  version = 0, options = 3080, localeCallbacks = 0x7fc644e776e0, 
  resolvingTable = 0x7fc63eb44eb0, rval2 = 0, rval2set = 0 '\0', 
  generatingError = 0 '\0', insideGCMarkCallback = 0 '\0', throwing = 0 '\0', 
  exception = 140489300857408, stackLimit = 140734770783356, 
  scriptStackQuota = 104837082, runtime = 0x7fc648c18000, stackPool = {
    first = {next = 0x7fc63c148000, base = 140489438815488, 
      limit = 140489438815488, avail = 140489438815488}, 
    current = 0x7fc63c148000, arenasize = 8192, mask = 7, 
    quotap = 0x7fc63f1864d0}, fp = 0x7fff5e0d0c60, tempPool = {first = {
      next = 0x0, base = 140489438815560, limit = 140489438815560, 
      avail = 140489438815560}, current = 0x7fc63f186528, arenasize = 1024, 
    mask = 7, quotap = 0x7fc63f1864d0}, globalObject = 0x7fc63f19d540, 
  weakRoots = {newborn = {0x7fc63a7fbf40, 0x7fc648cbf860, 0x7fc636c13550, 0x0, 
      0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, lastAtom = 140489360165316, 
    lastInternalResult = 140489298883892}, regExpStatics = {
    input = 0x7fc636c13500, multiline = 0, parenCount = 3, moreLength = 0, 
    parens = {{length = 4, chars = 0x7fc636ec3c40}, {length = 4, 
        chars = 0x7fc636ec3c40}, {length = 0, chars = 0x7fc636ec3c48}, {
        length = 0, chars = 0x0}, {length = 0, chars = 0x0}, {length = 0, 
        chars = 0x0}, {length = 0, chars = 0x0}, {length = 0, chars = 0x0}, {
        length = 0, chars = 0x0}}, moreParens = 0x0, lastMatch = {length = 4, 
      chars = 0x7fc636ec3c40}, lastParen = {length = 0, 
      chars = 0x7fc636ec3c48}, leftContext = {length = 0, 
      chars = 0x7fc636ec3c40}, rightContext = {length = 0, 
      chars = 0x7fc636ec3c48}}, sharpObjectMap = {depth = 0, sharpgen = 0, 
    table = 0x0}, argumentFormatMap = 0x7fc63eb05620, lastMessage = 0x0, 
  tracefp = 0x0, 
  errorReporter = 0x7fc6444fd8fa <NS_ScriptErrorReporter(JSContext*, char const*, JSErrorReport*)>, operationCallbackIsSet = 1, operationLimit = 20480000, 
  operationCallback = 0x7fc6444fbff4 <nsJSContext::DOMOperationCallback(JSContext*)>, interpLevel = 2, data = 0x7fc63f15a980, data2 = 0x7fc63eb50640, 
  dormantFrameChain = 0x0, thread = 0x7fc648c99000, requestDepth = 1, 
  outstandingRequests = 1, titleToShare = 0x0, lockedSealedTitle = 0x0, 
  threadLinks = {next = 0x7fc63f187348, prev = 0x7fc63f174b48}, 
  stackHeaders = 0x7fc63c148500, localRootStack = 0x0, tempValueRooters = 0x0, 
  gcLocalFreeLists = 0x7fc648c5efa0, doubleFreeList = 0x7fc648cbf870, 
  debugHooks = 0x7fc648c18250, securityCallbacks = 0x0, regexpPool = {first = {
      next = 0x7fc636c04000, base = 140489438816176, limit = 140489438816176, 
      avail = 140489438816176}, current = 0x7fc636c04000, arenasize = 12248, 
    mask = 7, quotap = 0x7fc63f1864d0}, resolveFlags = 65535}
(gdb) p v
$2 = 979909808
(gdb) bt
#0  0x00007fc6556de79f in js_FillPropertyCache (cx=0x7fc63f186400, 
    obj=0x7fc636c189c0, kshape=25319, scopeIndex=0, protoIndex=1, 
    pobj=0x7fc63a6a4f00, sprop=0x7fc63a6138e0, entryp=0x7fff5e0d03d0)
    at /mnt/data/Coding/mozilla-central/js/src/jsinterp.cpp:203
#1  0x00007fc6556f1756 in js_GetPropertyHelper (cx=0x7fc63f186400, 
    obj=0x7fc636c189c0, id=140489360163652, vp=0x7fff5e0d08b8, 
    entryp=0x7fff5e0d03d0)
    at /mnt/data/Coding/mozilla-central/js/src/jsobj.cpp:3827
#2  0x00007fc6556b2c75 in js_Interpret (cx=0x7fc63f186400)
    at /mnt/data/Coding/mozilla-central/js/src/jsinterp.cpp:4389
#3  0x00007fc6556dd150 in js_Invoke (cx=0x7fc63f186400, argc=1, 
    vp=0x7fc63c148510, flags=0)
    at /mnt/data/Coding/mozilla-central/js/src/jsinterp.cpp:1324
#4  0x00007fc6556955fe in js_fun_apply (cx=0x7fc63f186400, argc=1, 
    vp=0x7fc63c1484e0)
    at /mnt/data/Coding/mozilla-central/js/src/jsfun.cpp:1732
#5  0x00007fc6556b7216 in js_Interpret (cx=0x7fc63f186400)
    at /mnt/data/Coding/mozilla-central/js/src/jsinterp.cpp:4994
#6  0x00007fc6556dd150 in js_Invoke (cx=0x7fc63f186400, argc=1, 
    vp=0x7fc63c148038, flags=0)
    at /mnt/data/Coding/mozilla-central/js/src/jsinterp.cpp:1324
#7  0x00007fc6556dda0a in js_InternalInvoke (cx=0x7fc63f186400, 
    obj=0x7fc63c5fe940, fval=140489425635328, flags=0, argc=1, 
    argv=0x7fc63722dd30, rval=0x7fff5e0d35d8)
    at /mnt/data/Coding/mozilla-central/js/src/jsinterp.cpp:1381
#8  0x00007fc65564572b in JS_CallFunctionValue (cx=0x7fc63f186400, 
    obj=0x7fc63c5fe940, fval=140489425635328, argc=1, argv=0x7fc63722dd30, 
    rval=0x7fff5e0d35d8)
    at /mnt/data/Coding/mozilla-central/js/src/jsapi.cpp:5146
#9  0x00007fc6444f9eae in nsJSContext::CallEventHandler (this=0x7fc63f15a980, 
    aTarget=0x7fc63c10b000, aScope=0x7fc63c5fe940, aHandler=0x7fc63e4f4800, 
    aargv=0x7fc636c0f248, arv=0x7fff5e0d3740)
    at /mnt/data/Coding/mozilla-central/dom/src/base/nsJSEnvironment.cpp:2012
#10 0x00007fc6445248e4 in nsGlobalWindow::RunTimeout (this=0x7fc63c10b000, 
    aTimeout=0x7fc636dff940)
    at /mnt/data/Coding/mozilla-central/dom/src/base/nsGlobalWindow.cpp:7658
#11 0x00007fc644524dfc in nsGlobalWindow::TimerCallback (
    aTimer=0x7fc636dff9a0, aClosure=0x7fc636dff940)
    at /mnt/data/Coding/mozilla-central/dom/src/base/nsGlobalWindow.cpp:7990
#12 0x00007fc65518256c in nsTimerImpl::Fire (this=0x7fc636dff9a0)
    at /mnt/data/Coding/mozilla-central/xpcom/threads/nsTimerImpl.cpp:420
#13 0x00007fc65518278a in nsTimerEvent::Run (this=0x7fc636df03d0)
    at /mnt/data/Coding/mozilla-central/xpcom/threads/nsTimerImpl.cpp:512
#14 0x00007fc65517c516 in nsThread::ProcessNextEvent (this=0x7fc64d2eb1f0, 
    mayWait=1, result=0x7fff5e0d39ec)
    at /mnt/data/Coding/mozilla-central/xpcom/threads/nsThread.cpp:510
#15 0x00007fc65510c9f2 in NS_ProcessNextEvent_P (thread=0x7fc64d2eb1f0, 
    mayWait=1) at nsThreadUtils.cpp:227
#16 0x00007fc647235954 in nsBaseAppShell::Run (this=0x7fc64d2fd8d0)
    at /mnt/data/Coding/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:170
#17 0x00007fc6461417dc in nsAppStartup::Run (this=0x7fc648c980b0)
    at /mnt/data/Coding/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:182
#18 0x00007fc655a6ab93 in XRE_main (argc=4, argv=0x7fff5e0d42e8, 
    aAppData=0x7fc64d21f080)
    at /mnt/data/Coding/mozilla-central/toolkit/xre/nsAppRunner.cpp:3263
#19 0x0000000000401ff8 in main (argc=4, argv=0x7fff5e0d42e8)
    at /mnt/data/Coding/mozilla-central/browser/app/nsBrowserApp.cpp:156
Is this bug specific to 64bit linux?
Well I'm only building and testing on 64bit linux. I can't confirm if this bug is also valid for 32bit systems or for 64bit windows. On what platform are you seeing this bug?
I'm actually in WinXP 32bit and I don't see the crash
Yes, then it is specific to 64bit (linux).
As you might know, building tracemonkey on 64bit systems is disabled in the makefile so far. I'm tracking all the bugs I see when enabling tracemonkey on 64bit in bug 457879.
This bug is only about a 64-bit portability problem in SpiderMonkey.

/be
Assignee: general → brendan
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1b2
David, I'll need your help on this one since you have the 64-bit Linux box within reach.

/be
Arpad, is this still reproducing on the latest tracemonkey nightlies?

/be
I haven't been able to build the amd64 version for quite some time.
NativeAMD64.h seems to be off track with the other files and produces a lot of compile errors.
I am a bad owner for this. David, can you help?

/be
Assignee: brendan → danderson
I'm hitting this in a case fairly often in current trunk build on a 32 bit system:
http://crash-stats.mozilla.com/report/index/af9b6e97-20a4-4919-8053-988752090316?p=1
Actually, I'm hitting this all the time. Perhaps I'm getting this because of the timer changes that are causing a lot of crashes lately? Maybe I should file a new bug for that?
Flags: blocking1.9.2?
(In reply to comment #11)
> Perhaps I'm getting this because of
> the timer changes that are causing a lot of crashes lately?
Are causing or did cause? I'm not aware of any non-fixed crashes.
Btw, if you see any timer crashes, CC also bent.

> Maybe I should file
> a new bug for that?
Your stack trace looks like this bug. Perhaps something in TM changed.
I also crash in 1.9.1.
Flags: blocking1.9.1?
Keywords: 64bit
we shouldn't be shipping the JIT on x86_64. blocking-
Flags: blocking1.9.1? → blocking1.9.1-
Like I said, I'm seeing this with a normal computer, not with x86_64. Does that change things?
Flags: blocking1.9.1- → blocking1.9.1?
Summary: TM: (x86_64) Crash in js_FillPropertyCache when running mootools slickspeed benchmark → TM: Crash in js_FillPropertyCache when running mootools slickspeed benchmark
(In reply to comment #15)
> Like I said, I'm seeing this with a normal computer, not with x86_64. Does that
> change things?

Don't morph an x86_64 bug. File a new one. bugzilla basics...
Summary: TM: Crash in js_FillPropertyCache when running mootools slickspeed benchmark → TM: (x86_64) Crash in js_FillPropertyCache when running mootools slickspeed benchmark
Flags: blocking1.9.1? → blocking1.9.1-
See comment 5: "This bug is only about a 64-bit portability problem in SpiderMonkey."
Well, comment 12 more or less suggested to stay in this bug...
(In reply to comment #18)
> Well, comment 12 more or less suggested to stay in this bug...
In that case my mistake. sorry.
Ok, filed bug 484042.
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
I'm unable to reproduce the crash with the new x64 backend.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.