Closed Bug 553948 Opened 10 years ago Closed 10 years ago

Crash [@ js_ValueToNumber ] with putImageData

Categories

(Core :: Canvas: 2D, defect, critical)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- ?
status1.9.1 --- ?

People

(Reporter: humph, Assigned: vlad)

References

()

Details

(Keywords: crash, testcase, Whiteboard: [sg:critical][critsmash:resolved])

Crash Data

Attachments

(1 file)

Similar to bug 553938, but not identical:

var canvas = document.getElementById('c');
var ctx = canvas.getContext('2d');
var imgData = {data: new Array(10*10*4), width: 10, height: 10};

imgData.data[0] = 0;
ctx.putImageData(imgData, 0, 0);

Attached a test case (click "Crash Me").  See also http://crash-stats.mozilla.com/report/index/5861cc9c-92a8-43fc-8ffc-f46792100321
This is the "If imgData.data[0] = 0 had happened" case from bug 553938 comment 3.  Fixing that bug should fix this.
Group: core-security
Depends on: 553938
Hmm, I think this is actually the same as bug 543682 -- that array is full of holes, and those are escaping into the normal jsval world.  It's fixed on tracemonkey.
Not sure if this is actually exploitable, but once we get 543682 on trunk it won't matter.
Whiteboard: [sg:critical]
Is this already fixed? A tracemonkey -> mozilla-central merge happened yesterday.
Assignee: nobody → vladimir
Keywords: testcase
I no longer see a crash with the attached testcase using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100419 Minefield/3.7a5pre.
Whiteboard: [sg:critical] → [sg:critical][critsmash:investigating]
marcia to go back and test on the 3.6.x and 3.5.x branches.
status1.9.1: --- → ?
status1.9.2: --- → ?
Summary: Crash [@ js_ValueToNumber ] → Crash [@ js_ValueToNumber ] with putImageData
No crash using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100503 Firefox/3.6.4 but I get this error in the console: 

Error: uncaught exception: [Exception... "An invalid or illegal string was specified"  code: "12" nsresult: "0x8053000c (NS_ERROR_DOM_SYNTAX_ERR)"  location: "https://bug553948.bugzilla.mozilla.org/attachment.cgi?id=433842&t=2egYT1GldS Line: 17"]

Also no crash with test case using : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 and similar error in console.
E
Resolving for now since we can't reproduce.  Feel free to open back up if we see this show up in crash stats.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
still 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
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
chofmann: are those the same stack as here, with putImageData?  That seems pretty high, given the relative paucity of canvas use in the wild.
ok, I guess comment 9 goes with the real old bug 223166 or other bug(s) that we should open up about js_ValueToNumber crashes.

In that sample of 31 reports from yesterday there are no reports with putImageData on the stack.

there quite a variation in the stacks with this signature with some of the stacks looking like this

   6 times
     js_ValueToNumber 
     js_Interpret 
     js_Invoke 
     js_InternalInvoke 
     JS_CallFunctionValue nsJSContext::CallEventHandler(nsISupports *,void *,void *,nsIArray *,nsIVariant * *) 

   3 times
     js_ValueToNumber 
     js_Interpret 
     js_Invoke 
     js_fun_apply 
     js_Interpret 
     js_Invoke
 
   3 times 
     js_ValueToNumber 
     js_Interpret 
     UserCallWinProcCheckWow 
     js_Interpret 
     js_Interpret 
     StringDuplicateW 

and then a long tail of different stacks with the top 5 frames each looking different.

given the landing mentioned in comment 4, and fixing of bug 550351 its probably time to mark this fixed and maybe open up?
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
bug 565194 for the other stacks.
Whiteboard: [sg:critical][critsmash:investigating] → [sg:critical][critsmash:resolved]
Crash Signature: [@ js_ValueToNumber ]
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.