crashes at [@ js_ValueToNumber ]




9 years ago
3 years ago


(Reporter: chofmann, Unassigned)



Mac OS X

Firefox Tracking Flags

(Not tracked)


(crash signature)


(1 attachment)



9 years ago
Created attachment 444784 [details]
distributon of top 5 frames on js-ValueToNumber on 2010 05 10

spotted while looking at bug 553948

variety of stacks with the signature "js_ValueToNumber" are seen in low volume on major releases with several million users.

checking --- js_ValueToNumber 20100510-crashdata.csv
found in: 3.6.3 3.5.9 3.6 3.6b4
release total-crashes
              js_ValueToNumber crashes
all     378690  31      8.18612e-05
3.6.3   261522  16      6.11803e-05
3.5.9   33340   9       0.000269946
3.6     14860   5       0.000336474
3.6b4   934     1       0.00107066

os breakdown
js_ValueToNumberTotal 31
Win5.1  0.74
Win6.0  0.10
Win6.1  0.13

we can use this a tracking bug or place holder to watch for changes in volume.

for some reason the web interface for soccoro won't return reports for a search on this signature right now, but I'll file a bug to get that fixed.
Can we get a report of what the values are that are being passed to js_ValueToNumber for those crashes?  The second parameter, v, is what we really want I think.

(Note: js_ValueToNumber went away entirely in m-c, so there we'll see different crashes, labelled ValueToNumber.)

Comment 3

9 years ago
(In reply to comment #2)
> Can we get a report of what the values are that are being passed to
> js_ValueToNumber for those crashes?  The second parameter, v, is what we really
> want I think.

I scrapped these from the raw dumps via the web interface.  are those values in the jsonz files?   bsmedberg, any way for you to look for that data on your couchdb set up, or daniel would this be available under the test hadoop set up you have?

Comment 4

9 years ago
shaver: afaik someone would have to look at .dump files. Stack locals should be available, but it's time consuming. It's doable....
Severity: normal → critical
Keywords: crash
I would expect that the arguments would be on the stack here, yeah.  I was asking for someone to run a tool to extract it, not to go through 350K minidumps themselves!
Right now, the production HBase cluster has the original json and the raw dump file for all these crash reports stored.  It does not have any processed metadata associated with them yet though.

It would be easy for us to take a list of crash report IDs and retrieve the dump files and put them somewhere.

It would be possible for us to write a job that would go through the list of crash report IDs, and make a TCP connection to a daemon that performed this custom inspection.  Most likely, this would involve having someone work up some code that performed the stack local argument retrieval within the context of the daemonized minidump stackwalk program that supports a remote symbol server.
Crash Signature: [@ js_ValueToNumber ]
Assignee: general → nobody
This isn't happening any more with this signature - no crashes in the past two months for anything other than an ancient version
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.