565194 - crashes at [@ js_ValueToNumber ]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[chris hofmann]

Attachment: 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.

Comment 1

[chris hofmann]

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.

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

[chris hofmann]

(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

[timeless]

shaver: afaik someone would have to look at .dump files. Stack locals should be available, but it's time consuming. It's doable....

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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!

Comment 6

[Daniel Einspanjer [:dre] [:deinspanjer]]

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.

Comment 7

[Wayne Mery (:wsmwk)]

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