Note: There are a few cases of duplicates in user autocompletion which are being worked on.

crash js::analyze::ScriptAnalysis::printTypes

RESOLVED FIXED in mozilla10



JavaScript Engine
6 years ago
6 years ago


(Reporter: morac, Assigned: bhackett)


Windows XP

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
This bug was filed from the Socorro interface and is 
report bp-f584f1d0-a3bd-40e0-a407-743bb2111028 .

This crash occurred shortly after I disabled the Roboform 7.6.1 add-on and then re-enabled it in the nightly loads.  Roboform uses bootstrap.js so it disables and enables without restarting.

I've been disabling and enabling Roboform a lot today and this is the first time I saw Minefield crash because of it.

Comment 1

6 years ago
This is now happening consistently.  I noticed that Minefield updated itself pretty much right before this so my guess is that it has something to do with the new load.

I tried another restartless add-on and that didn't crash so it must be a compatibility issue between Roboform and the latest Minefield load.
Brian, would you mind taking a look at the stacks to see if you can tell what's going on here?

Comment 3

6 years ago
This is a forced crash under TypeFailure.  The only time that is hit in release builds is when TI finds an opcode in a script which it doesn't know how to analyze.  From looking at the stack, that seems to be the case here.  I just compared the analyzed opcodes and the entire set of opcodes, and nothing in the diff looks like it should be possible.  Michael, can you try starting the browser from a command line window and see if anything is printed when it crashes?

Comment 4

6 years ago
When running under Windows, the output is only dumped to the console window (when using the -console parameter).  It's not dumped to the command line.  The console window closes on a crash, making it extremely difficult to get any data out of it.  

I did see something output to the console window, but because the window goes away a second later that's not very useful.  The only way I could figure out to see the data was take a screen shot immediately on the crash.  That took several tries to get the timing correct.  Really there should be a real console output on Windows (is there a bug for that?)

Anyway once I got it I could see the output was:

"Unknown bytecode 8b at #0:00102"

This is with Roboform 7.6.2 under Minefield 2011-10-28.

By the way I tried this on my home PC that was running Minefield 2011-10-20 and it worked fine until it upgraded to 2011-10-24 at which point it always crashes.

Comment 5

6 years ago
Awesome, thanks a lot.  This opcode is JSOP_ARGCNT, which is only emitted when TI is disabled (so TI does not expect to analyze it).  This and another similar opcode (ARGSUB) should really be removed entirely, which would fix this crash.

What I'm worried about though is what this extension is doing that triggered this behavior.  TI was disabled when compiling the script and enabled when executing it.  A couple possibilities I can see:

- The script is parsed and executed in two different compartments.  This would be really bad and there are tons of assertions watching for this (including OPT asserts I think), so I doubt this is happening.

- The script is parsed in one compartment, then XDR'ed and de-XDR'ed in a different compartment with TI enabled.  This is probably what's happening; in principle this behavior shouldn't be a problem but that hasn't had any testing at all.

Comment 6

6 years ago
Created attachment 570524 [details] [diff] [review]
patch (1b4d0987b18d)

Remove ARGSUB, ARGCNT opcodes (will also need an XDR version bump).
Assignee: general → bhackett1024
Attachment #570524 - Flags: review?(dvander)
Attachment #570524 - Flags: review?(dvander) → review+

Comment 7

6 years ago

Comment 8

6 years ago
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10

Comment 9

6 years ago
Well I'm not seeing the crash anymore, but it looks like something changed in Roboform 7.6.2 which stopped the crashing since I was still running the 10-31 load when I tested, so I'm not able to verify that the fix works.
You need to log in before you can comment on or make changes to this bug.