3.59 KB, text/plain
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 pct. 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.
http://crash-stats.mozilla.com/report/list?query_search=signature&query_type=exact&query=js_ValueToNumber&date=05%2F11%2F2010%2016%3A41%3A58&range_value=1&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=js_ValueToNumber gets a list of recent crashes. attachment shows the distribution of the top 5 frames on the stack.
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.)
(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?
shaver: afaik someone would have to look at .dump files. Stack locals should be available, but it's time consuming. It's doable....
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.
This isn't happening any more with this signature - no crashes in the past two months for anything other than an ancient version https://crash-stats.mozilla.com/search/?product=Firefox&signature=~js_ValueToNumber&date=%3E2016-05-01&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports