72694 2011-11-18 00:26:33 -0800 [Qt] fast/canvas/canvas-lineWidth.html timeouts intermittently on 64 bit 2012-05-22 10:27:29 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) All All RESOLVED FIXED Qt, QtTriaged P1 Major --- 79668 1 ossy rafael.lobo cmarcelo darin eric ggaren kling ossy rafael.lobo reed webkit-sed oldest_to_newest 505566 0 ossy 2011-11-18 00:26:33 -0800 $ Tools/Scripts/old-run-webkit-tests fast/canvas/canvas-lineWidth.html --iterations 100 --singly 54 test cases (54%) succeeded 46 test cases (46%) timed out But it works fine on 32 bit. 508326 1 116405 rafael.lobo 2011-11-23 13:15:25 -0800 Created attachment 116405 test modified to debug why length has such a big value (or negative) 508327 2 rafael.lobo 2011-11-23 13:16:38 -0800 I've spent a bit of time on this, so I'll share my findings - but I didn't find a solution yet. Timeouts on this test happens because the length of an image data is returning a very large number (random)... when it returns a negative value (I suppose it is because of some overflow), then the for inside compareRows that will check every pixel at the image will just not run. Now trying to understand why this length is getting this strange value, I've decided to stop this for inside the function and not execute it at all. Then I've printed out the length in both calls of compareRows and they're being printed correctly. Then instead of doing that for, I've decided to put a for that does nothing, just iterate N times. And for my surprise, the length get corrupted in the second call when N >= 985. Even more weird, if I print the length before using compareRows in the second time then it'll show the correct length... it just happens when it goes inside the function. I've also attached the modified version of this test that I was using to debug. My output for this debug: typeof(ctx) = object # comparing data... size1=240000 # comparing data... size2=240000 comparing data... size0=240000 comparing data... size1=240000 ## typeof(ctx) = object ## comparing data... size1=240000 ## comparing data... size2=240000 # comparing data... size1=623014176 # comparing data... size2=623014176 comparing data... size0=623014176 comparing data... size1=623014176 514110 3 eric 2011-12-02 14:01:20 -0800 This appears to time out on all platforms. The test should be skipped/disabled. 514836 4 rafael.lobo 2011-12-04 19:20:01 -0800 (In reply to comment #3) > This appears to time out on all platforms. The test should be skipped/disabled. I've imagined that... the issue would just disappear depending on what context (inside a function or not) the data comparison is done, this bothers me. It could be slightly modified to pass... instead of creating a function to avoid code repetition and compare the image data, we could avoid creating that function. This approach would probably solve it but would also hide this issue that is potentially something big... I'm sorry I couldn't investigate more about it. 628441 5 cmarcelo 2012-05-19 10:09:03 -0700 (In reply to comment #0) > $ Tools/Scripts/old-run-webkit-tests fast/canvas/canvas-lineWidth.html --iterations 100 --singly For the record: this doesn't timeout for me neither in Qt on Mac Lion (64 bits) and Apple port on Mac Lion. 628924 6 ossy 2012-05-21 03:14:28 -0700 (In reply to comment #5) > (In reply to comment #0) > > $ Tools/Scripts/old-run-webkit-tests fast/canvas/canvas-lineWidth.html --iterations 100 --singly > > For the record: this doesn't timeout for me neither in Qt on Mac Lion (64 bits) and Apple port on Mac Lion. It passes on Qt Linux now ... 630517 7 rafael.lobo 2012-05-22 10:27:29 -0700 It looks like someone has unskipped it already, then I will close this bug. 116405 2011-11-23 13:15:25 -0800 2011-11-23 13:15:25 -0800 test modified to debug why length has such a big value (or negative) canvas-lineWidth.js application/javascript 1648 rafael.lobo Ly8gQ29tcGFyZSBzZWN0aW9ucyBvZiBhIDxjYW52YXM+IHRvIGFzc2VydCB0aGV5IGFyZSBpZGVu dGljYWwuCmZ1bmN0aW9uIGNvbXBhcmVSb3dzKGN0eCwgeTAsIHkxLCB3aWR0aCwgaGVpZ2h0KSB7 CiAgICBkZWJ1ZygnIyBjb21wYXJpbmcgZGF0YS4uLiBzaXplMT0nICsgY3R4LmdldEltYWdlRGF0 YSgwLCB5MCwgd2lkdGgsIGhlaWdodCkuZGF0YS5sZW5ndGgpOwogICAgZGVidWcoJyMgY29tcGFy aW5nIGRhdGEuLi4gc2l6ZTI9JyArIGN0eC5nZXRJbWFnZURhdGEoMCwgeTEsIHdpZHRoLCBoZWln aHQpLmRhdGEubGVuZ3RoKTsKCiAgICB2YXIgZGF0YTAgPSBjdHguZ2V0SW1hZ2VEYXRhKDAsIHkw LCB3aWR0aCwgaGVpZ2h0KS5kYXRhOwogICAgdmFyIGRhdGExID0gY3R4LmdldEltYWdlRGF0YSgw LCB5MSwgd2lkdGgsIGhlaWdodCkuZGF0YTsKCiAgICBkZWJ1ZygnY29tcGFyaW5nIGRhdGEuLi4g c2l6ZTA9JyArIGRhdGEwLmxlbmd0aCk7CiAgICBkZWJ1ZygnY29tcGFyaW5nIGRhdGEuLi4gc2l6 ZTE9JyArIGRhdGExLmxlbmd0aCk7CiAgICBmb3IgKHZhciBpID0gMDsgaSA8IDk4NTsgKytpKTsK ICAgIHJldHVybjsKfQoKZGVzY3JpcHRpb24oIlRlc3QgdGhlIGRlZmF1bHQgbGluZVdpZHRoIGlz IGNvbnNpc3RlbnQuIik7CgpjdHggPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgiY2FudmFzIiku Z2V0Q29udGV4dCgiMmQiKTsKY3R4LnN0cm9rZVN0eWxlID0gJ2JsdWUnOwoKZm9yICh2YXIgaiA9 IDA7IGogPCAzOyArK2opIHsKICAgIGN0eC5iZWdpblBhdGgoKTsKICAgIGZvciAodmFyIGkgPSAw OyBpIDwgNjA7ICsraSkgewogICAgICAgIHZhciB4ID0gaSAqIDEwOwogICAgICAgIHZhciB5ID0g aiAqIDEwMCArIDMwICsgKGkgJSAxNSk7CiAgICAgICAgaWYgKGkgPT0gMCkgewogICAgICAgICAg ICBjdHgubW92ZVRvKHgsIHkpOwogICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgIGN0eC5saW5l VG8oeCwgeSk7CiAgICAgICAgfQogICAgfQogICAgY3R4LnN0cm9rZSgpOwoKICAgIGlmIChqID09 IDApIHsKICAgICAgICBzaG91bGRCZSgiY3R4LmxpbmVXaWR0aCIsICIxIik7CiAgICAgICAgY3R4 LmxpbmVXaWR0aCA9IGN0eC5saW5lV2lkdGg7CiAgICAgICAgc2hvdWxkQmUoImN0eC5saW5lV2lk dGgiLCAiMSIpOwogICAgfSBlbHNlIHsKICAgICAgICBzaG91bGRCZSgiY3R4LmxpbmVXaWR0aCIs ICIxIik7CiAgICAgICAgY3R4LmxpbmVXaWR0aCA9IDE7CiAgICAgICAgc2hvdWxkQmUoImN0eC5s aW5lV2lkdGgiLCAiMSIpOwogICAgfQp9CgovLyBNYWtlIHN1cmUgdGhhdCBhbGwgcm93cyBhcmUg aWRlbnRpY2FsLgpkZWJ1ZygndHlwZW9mKGN0eCkgPSAnICsgdHlwZW9mKGN0eCkpOwpjb21wYXJl Um93cyhjdHgsIDAsIDEwMCwgNjAwLCAxMDApOwpkZWJ1ZygnIyMgdHlwZW9mKGN0eCkgPSAnICsg dHlwZW9mKGN0eCkpOwpkZWJ1ZygnIyMgY29tcGFyaW5nIGRhdGEuLi4gc2l6ZTE9JyArIGN0eC5n ZXRJbWFnZURhdGEoMCwgMCwgNjAwLCAxMDApLmRhdGEubGVuZ3RoKTsKZGVidWcoJyMjIGNvbXBh cmluZyBkYXRhLi4uIHNpemUyPScgKyBjdHguZ2V0SW1hZ2VEYXRhKDAsIDIwMCwgNjAwLCAxMDAp LmRhdGEubGVuZ3RoKTsKY29tcGFyZVJvd3MoY3R4LCAwLCAyMDAsIDYwMCwgMTAwKTsKCg==