Closed Bug 624800 Opened 14 years ago Closed 14 years ago

Crash in [@ js::ExecuteTree]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: johnath, Unassigned)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(1 file)

js::executetree crashes for jan 09 and listing of addons from those reports
55.25 KB, text/plain
Details
Seeing a fair bit of crashiness in ExecuteTree under RecordLoopEdge. Examples from today: http://crash-stats.mozilla.com/report/index/ffdb7e22-dffb-4781-b237-2dade2110111 http://crash-stats.mozilla.com/report/index/9df34341-43b4-4434-8492-88c0f2110111 Might be a dupe of bug 571626, but that's resolved so maybe not.
Nominating since we're on the lookout for crashes after compartment gc.
blocking2.0: --- → ?
We are always on the lookout for crashes. This bug has nothing to do with the recent change to enable compartment-wise GC, as far as I can tell. There's no hint of it. A point I've been making about compartment-wise GC: it is built on the full GC we already do, which marks and sweeps everything and knows about compartments. The change we made is to do strictly less marking and sweeping. It's "conservative" in this sense: without a global GC, references from outside a compartment into it are taken to be roots and marked. This means with code factored to share the mark and sweep paths among global and per-compartment GC, there should not be premature free bugs. Any such are already in the system. We had a pre-existing bug when we enabled compartment-wise GC, in the phase structure of the compartment sweeping code. That was fixed. Other such bugs could exist and bite; any bug could (can't prove a negative). But looking at crashes is required no matter what, and compartment-wise GC suspicion isn't going to add or subtract from that effort. /be
This is mostly a 64-bit Mac crash, that appears to be in tracejit code. In Socorro, the earliest builds with this signature are Dec 15, and it's been bouncing up and down since then. It seems that Socorro doesn't keep around as much old data as it used to. Is this true? How do I know if Dec 15 is the earliest build with this crash or if it is the earliest build for which we have data? Without knowing the answer to that question, it's hard to say what to do with this. Minusing based on the fact that it's not that high volume + we have almost no information to do anything about it, unless someone happens to know something.
blocking2.0: ? → -
This horrible thing has been crashing constantly for a long time. Only way to get it to stop and do any web browsing is javascript.options.methodjit.content;false. Maybe lots of other people have made it false too which is why reporting is not high volume. It sure is high volume crashing when methodjit.content = true.
kiwiplant: can you link some of your crashes from about:crashes? thanks.
The first 3 reports are for flashplayer. Sorry. I should not have included them here.
Its interesting that you had a alot of addons installed when you were hitting the js::executetree crashes, then no addons installed when hitting the flash crashes. were you viewing the same sites or doing similar things with the browser when you hit both of those kind of crashes? Attachment also shows that a high pct. of people hitting this have lots of addons installed.
kiwiplant: could you try bisecting your add-ons, and seeing if you can narrow down which one might be buggy, or even tripping a bug in Firefox? Ones with native components are good ones to look at first, often.
Many of the add-ons were disabled. I removed the disabled ones for now. I've tried bisecting before and it still crashed just as much with none at all installed. Is disabling as good as removing for testing?
Can you link a crash report from running with no add-ons? Would like to see if it's the same. Thanks a lot for your help, we'd really like to get to the bottom of this, but even in an office full of 64-bit OS X users, we haven't been able to reproduce so far.
(In reply to comment #0) > Seeing a fair bit of crashiness in ExecuteTree under RecordLoopEdge. Examples > from today: > > http://crash-stats.mozilla.com/report/index/ffdb7e22-dffb-4781-b237-2dade2110111 > http://crash-stats.mozilla.com/report/index/9df34341-43b4-4434-8492-88c0f2110111 I wonder if the following is related. It pretty much matches the stack in the first URL. It also matches some of the stacks in comment 6. What it says to me is we have an uninitialised value use in tracer generated code, and that uninitialised value comes from a stack allocation within the tracer-generated code itself. "???" means unlabelled code, jit-generated, iow. If I had reasonable STRs I'd put them here :-) This is M-C of about 12 hours ago, on x64-linux, running my daily working workload with 87 tabs. I'll see if I can narrow it down somehow. Conditional jump or move depends on uninitialised value(s) at 0x23C5F8D1: ??? by 0x67145A1: js::ExecuteTree(JSContext*, js::TreeFragment*, unsigned int&, js::VMSideExit**, js::VMSideExit**) (jstracer.cpp:6456) by 0x67292CB: js::TraceRecorder::attemptTreeCall(js::TreeFragment*, unsigned int&) (jstracer.cpp:6046) by 0x672964C: js::TraceRecorder::recordLoopEdge(JSContext*, js::TraceRecorder*, unsigned int&) (jstracer.cpp:6007) by 0x6732A02: js::RecordLoopEdge(JSContext*, unsigned int&) (jstracer.cpp:7000) by 0x67DF71E: js::Interpret(JSContext*, JSStackFrame*, unsigned int, JSInterpMode) (jsinterp.cpp:3502) by 0x671CE27: js::RecordTracePoint(JSContext*, unsigned int&, bool*, bool) (jstracer.cpp:16545) by 0x671D251: js::MonitorTracePoint(JSContext*, unsigned int&, bool*, void**, unsigned int*) (jstracer.cpp:16701) by 0x67A15EE: RunTracer(js::VMFrame&, js::mjit::ic::TraceICInfo&) (InvokeHelpers.cpp:974) by 0x2232B037: ??? by 0x67480B7: js::mjit::EnterMethodJIT(JSContext*, JSStackFrame*, void*, js::Value*) (MethodJIT.cpp:748) by 0x674834C: js::mjit::JaegerShot(JSContext*) (MethodJIT.cpp:774) Uninitialised value was created by a stack allocation at 0x23C5F7BC: ??? followed by 2 others essentially identical
(In reply to comment #12) > I wonder if the following is related. It pretty much matches the > stack in the first URL. It also matches some of the stacks in > comment 6. I filed this as bug 625333, including the relevant chunk of tracer generated code.
It is #11 top crasher on Mac OS X in 4.0b10 over the last week. Here are some comments: "REAL PROBLEM with about:blank generating many tabs, now showing mailto: in each. Absolutely filthy Trojan that I can't get rid of. Please help me!" "Opening up a new link" "multiple tabs open, just loading two pages at once" "Selecting Kotaku articles to view in separate tabs" "I tried to click on a link."
blocking2.0: - → ?
Keywords: crash
This is nearly impossible to investigate at this point: The crash is in jitcode and Mac minidumps don't load in a debugger. The breakpad dump tool currently doesn't disassmble x64 code either. We can try to take a whack at it with a separate disassembler, but there's no way it can block release.
blocking2.0: ? → -
Severity: normal → critical
Target Milestone: --- → mozilla2.0b11
This crash or something similar is now happening to Windows users now too. Not just Mac and Linux any more. Today it is crashing almost exactly every 11 minutes. Firefox is totally unusable. There is no apparent pattern. Sometimes dies when the browser is just sitting there, sometimes when it has focus, mouse clicking, or typing. Started noticing ExecuteTree crashes started about 6 months ago when there was a switch to a new javascript engine. Some crash reports are showing up as different things today, but the crash interval is every 11 minutes. These 8 are from today between 2:37 and 4:02 PM http://crash-stats.mozilla.com/report/index/bp-d20b2e2f-c53a-4587-8894-200652110212 http://crash-stats.mozilla.com/report/index/bp-8576a2f4-44ab-40da-ba8c-d4b602110212 http://crash-stats.mozilla.com/report/index/bp-5721c73b-d2bf-4983-b18a-c5c4a2110212 http://crash-stats.mozilla.com/report/index/bp-5fa09f68-124a-4b41-aacc-d45ea2110212 http://crash-stats.mozilla.com/report/index/bp-2a09314b-d8b3-4beb-9b27-ce0472110212 http://crash-stats.mozilla.com/report/index/bp-2a09314b-d8b3-4beb-9b27-ce0472110212 http://crash-stats.mozilla.com/report/index/bp-47e38f36-93d2-4d23-b90e-5f3632110212 http://crash-stats.mozilla.com/report/index/bp-dd4c8d4d-e947-4357-bd06-7cb942110212
dmandelin: if we have windows minidumps, do we have hope?
kiwiplant: could you tell us about what pages you have open? If you open Firefox to a blank page (close all tabs but one, go to about:blank, quit firefox, start it back up) and let it sit for 11 mins, does it still crash?
Every 11 minutes -- could it have something to do bug 617656?
Target Milestone: mozilla2.0b11 → ---
(In reply to comment #16) > This crash or something similar is now happening to Windows users now too. Not > just Mac and Linux any more. Today it is crashing almost exactly every 11 > minutes. Firefox is totally unusable. There is no apparent pattern. Sometimes > dies when the browser is just sitting there, sometimes when it has focus, mouse > clicking, or typing. > > Started noticing ExecuteTree crashes started about 6 months ago when there was > a switch to a new javascript engine. > > Some crash reports are showing up as different things today, but the crash > interval is every 11 minutes. These 8 are from today between 2:37 and 4:02 PM > http://crash-stats.mozilla.com/report/index/bp-d20b2e2f-c53a-4587-8894-200652110212 > http://crash-stats.mozilla.com/report/index/bp-8576a2f4-44ab-40da-ba8c-d4b602110212 > http://crash-stats.mozilla.com/report/index/bp-5721c73b-d2bf-4983-b18a-c5c4a2110212 > http://crash-stats.mozilla.com/report/index/bp-5fa09f68-124a-4b41-aacc-d45ea2110212 > http://crash-stats.mozilla.com/report/index/bp-2a09314b-d8b3-4beb-9b27-ce0472110212 > http://crash-stats.mozilla.com/report/index/bp-2a09314b-d8b3-4beb-9b27-ce0472110212 > http://crash-stats.mozilla.com/report/index/bp-47e38f36-93d2-4d23-b90e-5f3632110212 > http://crash-stats.mozilla.com/report/index/bp-dd4c8d4d-e947-4357-bd06-7cb942110212 There are several different crash signatures in there. These are all happening at 11-minute intervals? I think Sync used to cause problems at 5-minute intervals back when it was doing unsafe multithreaded things. Might there be an add-on in play?
(In reply to comment #19) > Every 11 minutes -- could it have something to do bug 617656? Nick's observation seems worth investigating further. /be
(In reply to comment #21) > (In reply to comment #19) > > Every 11 minutes -- could it have something to do bug 617656? > > Nick's observation seems worth investigating further. Most of the crashes linked above are in tracejit code--I don't think that can be affected by bug 617656.
What is the deal with this bug? It is the only one that I've been getting consistently (and persistently) since I switched to the Firefox 4 line back in August. I have a feeling that a single site is causing it, at least for me. (There must be some errant piece of JS code somewhere.) The problem is, I can't realistically track it down, because I have hundreds of tabs open when it happens. I thought perhaps Panorama may have been the culprit, because it only seems to happen after I open Panorama for the first time. But I've used Panorama for days without a problem, with the hundreds of tabs safely sequestered in about:sessionrestore. (Unless maybe the issue has to do with minimized tab groups, which I didn't use while my old session was on hold.) Another thought I had was that it had something to do with the amount of memory that Firefox uses. I have Patrick Walton's Memory Meter Jetpack installed and it seems to top 2 GB before anything crashes. (I have 4 GB of memory on this iMac.) I thought that issues with that number were generally Windows-only, but maybe I'm mistaken. Hopefully someone more familiar with the JS code can use this information to narrow down the possibilities of what is causing this crash, because it is the single most annoying thing I have to deal with while running my normal session in Firefox 4. I have a feeling that all of these things are really just related to each other, but maybe something will spark a thought that could help. Good luck!
Gordon, how often do you get this crash? Right now, it's really hard to investigate because there are no STR, and the stack dumps Breakpad generates seem pretty much useless. But, if you get can get it often, I can give you some instructions on how to get more detailed information. Launch a new instance of Firefox from Terminal like so: > ulimit -c unlimited > /Path/to/Firefox/Contents/MacOS/firefox The first line will ensure that any crashed application launched from that terminal will place a full memory dump in /cores/. If we can get that far, we can probably run some GDB commands.
It is #3 top crasher on Mac OS X in 4.0. Here are 4.0 correlations by extensions: 46% (39/85) vs. 2% (44/2632) jid0-0PGffAcVvhUBieFYkRVVc5w6lIU@jetpack 29% (25/85) vs. 9% (246/2632) {e4a8a97b-f2ed-450b-b12d-ee082ba24781} (Greasemonkey, https://addons.mozilla.org/addon/748) 18% (15/85) vs. 2% (50/2632) {46551EC9-40F0-4e47-8E18-8E5CF550CFB8} (Stylish, https://addons.mozilla.org/addon/2108) 38% (32/85) vs. 23% (606/2632) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865) 18% (15/85) vs. 5% (136/2632) {AE93811A-5C9A-4d34-8462-F7B864FC4696} (StumbleUpon, https://addons.mozilla.org/addon/138) 11% (9/85) vs. 3% (92/2632) support@lastpass.com (LastPass Password Manager, https://addons.mozilla.org/addon/8542)
Keywords: topcrash
Bug 638627 comment 6 would seem to indicate that the cause is known and that this is fixed-in-tracemonkey (but not on m-c).
I think I hit this on 4.0: https://crash-stats.mozilla.com/report/index/db768148-aeb7-4f53-af4e-ed2392110325, which would be consistent with it being fixed in tracemonkey, but not trunk.
signature also returned a link to bug 584565. "when f.length is resolved at record time, we can fail to emit a shape guard" Wonder if this is something similar?
I was running a debug build under gdb for the past two days in the hope that I get this crash under gdb, but Firefox never crashed, so I gave up.
Ehsan: bug 638627 was merged to m-c on Mar 29; if you have that cset, then it makes sense that it would be fixed.
(In reply to comment #31) > Ehsan: bug 638627 was merged to m-c on Mar 29; if you have that cset, then it > makes sense that it would be fixed. I do have that cset. I hope that means that this bug is fixed, but let's leave it open for now until we get more data from the crash stats.
I had an uptime of several days with nearly a hundred tabs before I saw this crash. I wish I had an inkling of what I was doing before it happened.
For over two weeks now, I've been consistently getting this crash once (and only once) a day. I wonder if it is some sort of scheduled task that triggers this. Any known overlap regarding installed extension for the people who experience this crash?
(In reply to comment #34) > For over two weeks now, I've been consistently getting this crash once (and > only once) a day. I wonder if it is some sort of scheduled task that triggers > this. > > Any known overlap regarding installed extension for the people who experience > this crash? I don't have any information: the correlation reports are empty: https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0&query_search=signature&query_type=startswith&query=js%3A%3AExecuteTree&reason_type=contains&date=04%2F25%2F2011%2018%3A10%3A20&range_value=2&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=js%3A%3AExecuteTree You could try setting either of javascript.options.tracejit.chrome javascript.options.tracejit.content to |false|. That should prevent this crash. If you can tell us which fixes it (or both, or neither, on the off chance that's what happens), it could help.
I'll do that, hopefully it'll help to narrow this down just a tiny little bit. After today's timely crash (4:30pm, boom), I misclicked and did not restore my session, so all tabs are gone. If it was in one of the websites I frequent, then this might not reappear. Either way, I'll set either to false for a day, then reactivate and make sure the bug is still present. I'll report back when it's done in a few days.
Re: comment 35: Today's setting was ...chrome = false, crash occurred a few minutes ago while browsing Flickr. Now setting chrome=true and content=false to see if the bug persists tomorrow.
Crash also occurred with ...content=false. Here are three examples: 1) both true: http://crash-stats.mozilla.com/report/index/bp-f2b9db83-0301-4638-bac2-aaafa2110424 2) tracejit.chrome=false: https://crash-stats.mozilla.com/report/index/89b3e4d2-9ae8-4177-83f2-711572110426 3) tracejit.content=false: https://crash-stats.mozilla.com/report/index/bd1efd1e-45c9-4c82-98d1-7937f2110428 It seems that option 2 crashes elsewhere in the code than the other two. Another bit of data that might be interesting is that I do not need to be interacting with any website for this crash to occur.
(In reply to comment #38) oh, what happened to that URL. Here you go again. > 1) both true: > http://crash-stats.mozilla.com/report/index/bp-f2b9db83-0301-4638-bac2-aaafa2110424
(In reply to comment #40) > BUGZILLA, Y U NO accept my URL Filed bug 653754 on the bugzilla bug. To actually get to the friggin URL ;) use this short URL for now: http://mzl.la/l1hF8j
Noticed that prior to js::ExecuteTree crashes that any javascript functions that rely on timing such as the setTimeout() function, become slow and the time intervals erratic. Not sure if that helps, but I've now also submitted over 30 crash reports from this bug as well. Hopefully you can track this down soon as Firefox 3 could be left open for weeks with no issue or crashes, Firefox 4 is crashing at least once a day due to this bug. Thanks.
This is killing WebQA's automation -- I'll try to find out, if I can, a pattern, and then report back.
Crash Signature: [@ js::ExecuteTree]
Builds with TM still crash, but I think we can close unless there is some security risk.
Probably not worth it, going to close now.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: