79555 2012-02-24 20:34:08 -0800 JSString::resolveRope() should report extra memory cost to heap 2012-06-22 11:04:40 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) All All RESOLVED FIXED P2 Major --- 1 yong.li.webkit webkit-unassigned barraclough ggaren loki msaboff oliver ossy pnormand pvarga webkit.review.bot zherczeg oldest_to_newest 564847 0 yong.li.webkit 2012-02-24 20:34:08 -0800 JSString::resolveRope() should report extra memory cost to heap, otherwise, it can silently boost memory usage but never trigger a GC. Patch is forthcoming 564848 1 128845 yong.li.webkit 2012-02-24 20:42:15 -0800 Created attachment 128845 the patch 565693 2 yong.li.webkit 2012-02-27 08:57:06 -0800 BTW, I know the fibers will be cleared when rope is resolved. However the fibers are also JSString. Even they are the only owners of the string buffers, those string buffers won't be released until next GC. So it is even more necessary to notify heap for the new memory cost. 565976 3 ggaren 2012-02-27 14:15:51 -0800 This looks correct to me, but I'd like to see performance results before saying r+. 565992 4 129102 yong.li.webkit 2012-02-27 14:51:30 -0800 Created attachment 129102 a test case (just load it in Safari) A test case that shows how bad this issue can be. 565995 5 129102 yong.li.webkit 2012-02-27 14:54:56 -0800 Comment on attachment 129102 a test case (just load it in Safari) sorry this isn't right 565999 6 ggaren 2012-02-27 15:03:02 -0800 What I meant was performance results from running Tools/Scripts/bencher. 566063 7 msaboff 2012-02-27 16:07:09 -0800 I ran bencher with the change: VMs tested: "Baseline" at /Volumes/Data/src/webkit.baseline/WebKitBuild/Release/jsc (r109029) "With79555" at /Volumes/Data/src/webkit/WebKitBuild/Release/jsc (r109029) Collected 12 samples per benchmark/VM, with 4 VM invocations per benchmark. Emitted a call to gc() between sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds. Baseline With79555 SunSpider: 3d-cube 5.8065+-0.0636 5.7976+-0.0348 3d-morph 9.7651+-0.0655 9.7475+-0.0584 3d-raytrace 7.8058+-0.0845 7.7804+-0.1359 access-binary-trees 1.6814+-0.0083 ? 1.6891+-0.0117 ? access-fannkuch 7.4542+-0.0378 ? 7.4615+-0.0387 ? access-nbody 3.8650+-0.0121 ? 3.8658+-0.0083 ? access-nsieve 3.4944+-0.0348 ? 3.4945+-0.0369 ? bitops-3bit-bits-in-byte 1.2890+-0.0116 1.2827+-0.0024 bitops-bits-in-byte 5.2574+-0.0148 ? 5.2639+-0.0279 ? bitops-bitwise-and 3.3042+-0.0109 3.3022+-0.0062 bitops-nsieve-bits 3.3366+-0.0121 3.3241+-0.0027 controlflow-recursive 2.3364+-0.0095 ? 2.3375+-0.0161 ? crypto-aes 7.5264+-0.0598 ? 7.5782+-0.0733 ? crypto-md5 2.8876+-0.0368 2.8643+-0.0226 crypto-sha1 2.4409+-0.0311 2.4334+-0.0269 date-format-tofte 11.0680+-0.1543 10.8679+-0.0523 might be 1.0184x faster date-format-xparb 10.3282+-0.1265 ! 10.8125+-0.2257 ! definitely 1.0469x slower math-cordic 7.5014+-0.0586 ? 7.5187+-0.0581 ? math-partial-sums 10.5861+-0.0533 ? 10.5951+-0.0332 ? math-spectral-norm 2.6737+-0.0134 2.6717+-0.0041 regexp-dna 8.9740+-0.0569 ? 9.0282+-0.0640 ? string-base64 4.3738+-0.0134 ? 4.3838+-0.0200 ? string-fasta 7.2748+-0.0436 ? 7.2940+-0.0623 ? string-tagcloud 12.8811+-0.0680 ! 13.0507+-0.0959 ! definitely 1.0132x slower string-unpack-code 22.0923+-0.1550 21.9631+-0.1851 string-validate-input 6.5372+-0.0665 6.4888+-0.0790 <arithmetic> * 6.6362+-0.0224 ? 6.6499+-0.0168 ? might be 1.0021x slower <geometric> 5.3565+-0.0173 ? 5.3622+-0.0106 ? might be 1.0011x slower <harmonic> 4.2590+-0.0164 4.2576+-0.0088 might be 1.0003x faster Baseline With79555 V8: crypto 75.2921+-0.2420 75.1662+-0.2582 deltablue 159.3357+-1.0798 158.7000+-0.7260 earley-boyer 99.7900+-0.4689 ? 100.4316+-0.6263 ? raytrace 52.0263+-0.3561 ? 52.2842+-0.5627 ? regexp 101.9057+-0.4743 ? 102.1308+-0.4548 ? richards 145.3947+-1.1873 144.3771+-1.0141 splay 59.5547+-0.2939 59.2430+-0.2968 <arithmetic> 99.0427+-0.2055 98.9047+-0.1527 might be 1.0014x faster <geometric> * 91.8010+-0.1860 91.7429+-0.1588 might be 1.0006x faster <harmonic> 85.0683+-0.1982 85.0617+-0.1961 might be 1.0001x faster Baseline With79555 Kraken: ai-astar 809.4562+-13.3802 ? 821.8329+-11.7089 ? might be 1.0153x slower audio-beat-detection 192.9189+-2.0074 ^ 190.4819+-0.3250 ^ definitely 1.0128x faster audio-dft 291.9583+-4.6616 289.0048+-2.0882 might be 1.0102x faster audio-fft 116.8073+-0.1773 ? 116.8932+-0.6872 ? audio-oscillator 301.8988+-1.1253 301.6176+-1.3546 imaging-darkroom 293.9836+-6.5322 ? 296.2939+-6.6740 ? imaging-desaturate 237.5340+-0.2004 ^ 237.1890+-0.1405 ^ definitely 1.0015x faster imaging-gaussian-blur 455.1080+-0.1737 ? 455.4429+-0.3213 ? json-parse-financial 64.0643+-0.1497 ^ 63.2265+-0.2037 ^ definitely 1.0133x faster json-stringify-tinderbox 76.9872+-0.4034 ? 77.1329+-0.3894 ? stanford-crypto-aes 104.1311+-0.9987 102.9684+-0.6176 might be 1.0113x faster stanford-crypto-ccm 100.6942+-0.6070 100.4644+-0.6231 stanford-crypto-pbkdf2 200.0193+-0.7368 ? 200.7508+-0.6206 ? stanford-crypto-sha256-iterative 90.7559+-0.4278 90.5753+-0.2473 <arithmetic> * 238.3083+-1.0552 ? 238.8482+-0.9982 ? might be 1.0023x slower <geometric> 183.1813+-0.5011 182.8738+-0.3854 might be 1.0017x faster <harmonic> 146.3076+-0.3062 ^ 145.7417+-0.2077 ^ definitely 1.0039x faster Baseline With79555 All benchmarks: <arithmetic> 89.4076+-0.3439 ? 89.5554+-0.2991 ? might be 1.0017x slower <geometric> 23.4206+-0.0635 23.4204+-0.0390 might be 1.0000x faster <harmonic> 7.4808+-0.0283 7.4781+-0.0153 might be 1.0004x faster Baseline With79555 Geomean of preferred means: <scaled-result> 52.5575+-0.1566 ? 52.6220+-0.1053 ? might be 1.0012x slower It appears that there is a slight slowdown in sun spider.string-tagcloud (~1%). I verified there was a slowdown for tagclound os ~1% using run-sunspider harness. Overall this has a .1% impact on sun spider or all three tests, within the noise band. 566618 8 yong.li.webkit 2012-02-28 06:49:20 -0800 I was just going to do it this morning, but already see the performance results :). Thanks a lot! 566685 9 128845 webkit.review.bot 2012-02-28 08:02:22 -0800 Comment on attachment 128845 the patch Clearing flags on attachment: 128845 Committed r109105: <http://trac.webkit.org/changeset/109105> 566686 10 webkit.review.bot 2012-02-28 08:02:29 -0800 All reviewed patches have been landed. Closing bug. 567007 11 ossy 2012-02-28 13:07:24 -0800 Reopen, because it broke fast/events/dispatch-message-string-data.html on Qt and on GTK: --- /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-expected.txt +++ /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-actual.txt @@ -1,4 +1,5 @@ This is a test for https://bugs.webkit.org/show_bug.cgi?id=71229 (V8MessageEvent::dataAccessorGetter does not return a reference to its caller). If it succeeds, DONE will appear below. If it fails, you should see messages containing unexpected strings that were received and/or a renderer crash. DONE +Expected '818', Got: 'HelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHello818' 567106 12 yong.li.webkit 2012-02-28 14:33:25 -0800 (In reply to comment #11) > Reopen, because it broke fast/events/dispatch-message-string-data.html on Qt and on GTK: > > --- /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-expected.txt > +++ /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-actual.txt > @@ -1,4 +1,5 @@ > This is a test for https://bugs.webkit.org/show_bug.cgi?id=71229 (V8MessageEvent::dataAccessorGetter does not return a reference to its caller). If it succeeds, DONE will appear below. If it fails, you should see messages containing unexpected strings that were received and/or a renderer crash. > > DONE > +Expected '818', Got: This must be an existing issue but triggered by this patch. heap->reportExtraMemoryCost(n) shouldn't be problem no matter how much n is. 567119 13 yong.li.webkit 2012-02-28 14:45:16 -0800 (In reply to comment #11) > Reopen, because it broke fast/events/dispatch-message-string-data.html on Qt and on GTK: > > --- /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-expected.txt > +++ /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-actual.txt > @@ -1,4 +1,5 @@ > This is a test for https://bugs.webkit.org/show_bug.cgi?id=71229 (V8MessageEvent::dataAccessorGetter does not return a reference to its caller). If it succeeds, DONE will appear below. If it fails, you should see messages containing unexpected strings that were received and/or a renderer crash. > > DONE > +Expected '818', Got: 'Hello... It is 1024 "Hello"s + 808. The JS: var kPrefix = "Hello"; for (var i = 0; i < 10; ++i) kPrefix += kPrefix; 2^10 = 1024 if (message_event.data !== kPrefix + num.toString()) { log("Expected '" + num + "', Got: '" + message_event.data + "'"); } So the message_event.data seems right. what's "!=="? is it a supported operator in JS? 567122 14 yong.li.webkit 2012-02-28 14:48:16 -0800 Never mind. if (message_event.data !== kPrefix + num.toString()) { Probably "kPrefix + num.toString()" got GC'ed... 567238 15 ggaren 2012-02-28 17:03:04 -0800 > This must be an existing issue but triggered by this patch. Not necessarily. For example, you may have introduced a garbage collection at a time when your string is in an invalid state. If you don't have any immediate debugging leads, I think the best next step is to roll the patch out and rework it. 567474 16 ossy 2012-02-29 00:51:58 -0800 I skipped it on Qt to paint the bot green - http://trac.webkit.org/changeset/109202 . Please unskip it once the bug is fixed. 567585 17 yong.li.webkit 2012-02-29 07:10:00 -0800 (In reply to comment #15) > > This must be an existing issue but triggered by this patch. > > Not necessarily. For example, you may have introduced a garbage collection at a time when your string is in an invalid state. > > If you don't have any immediate debugging leads, I think the best next step is to roll the patch out and rework it. If that is true, it is a serious problem. I'll try to fix it today. I'm not against rolling it out if it is necessary. 567731 18 yong.li.webkit 2012-02-29 10:52:27 -0800 (In reply to comment #16) > I skipped it on Qt to paint the bot green - http://trac.webkit.org/changeset/109202 . Please unskip it once the bug is fixed. Thanks, Csaba. However I cannot reproduce the problem even by reporting 64MB memory cost which for sure triggers a GC. This might be port-specific issue. I'll try to make a qt build, but probably it will take me some time. Do you know any qt/gtk webkit developer available to help investigating this issue? 568803 19 yong.li.webkit 2012-03-01 11:58:32 -0800 (In reply to comment #11) > Reopen, because it broke fast/events/dispatch-message-string-data.html on Qt and on GTK: > > --- /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-expected.txt > +++ /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-actual.txt > @@ -1,4 +1,5 @@ > This is a test for https://bugs.webkit.org/show_bug.cgi?id=71229 (V8MessageEvent::dataAccessorGetter does not return a reference to its caller). If it succeeds, DONE will appear below. If it fails, you should see messages containing unexpected strings that were received and/or a renderer crash. > > DONE > +Expected '818', Got: .. Csaba, finally we got Qt 5.0 webkit release build on ubuntu (32-bit), but it passed the test, even after I made it reportExtraCost(64*1024*1024). Given that the issue cannot be produced on either ubuntu 32-bit or QNX, I tend to suggest it is a platform/port specific GC issue, probably something related to stack walking code, and probably related to 64-bit linux. 569331 20 pnormand 2012-03-01 23:45:42 -0800 The very same failure happens on GTK bots as well. 569525 21 ossy 2012-03-02 04:13:45 -0800 (In reply to comment #19) > (In reply to comment #11) > > Reopen, because it broke fast/events/dispatch-message-string-data.html on Qt and on GTK: > > > > --- /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-expected.txt > > +++ /ramdisk/qt-linux-64-release/build/layout-test-results/fast/events/dispatch-message-string-data-actual.txt > > @@ -1,4 +1,5 @@ > > This is a test for https://bugs.webkit.org/show_bug.cgi?id=71229 (V8MessageEvent::dataAccessorGetter does not return a reference to its caller). If it succeeds, DONE will appear below. If it fails, you should see messages containing unexpected strings that were received and/or a renderer crash. > > > > DONE > > +Expected '818', Got: > .. > > Csaba, finally we got Qt 5.0 webkit release build on ubuntu (32-bit), but it passed the test, even after I made it reportExtraCost(64*1024*1024). Given that the issue cannot be produced on either ubuntu 32-bit or QNX, I tend to suggest it is a platform/port specific GC issue, probably something related to stack walking code, and probably related to 64-bit linux. Sorry, I didn't realize that this test fails only on 64 bit (Qt, GTK too), but pass on 32 bit. And tested with Qt 4.8.0. But I think it should fail with Qt 5 on 64 bit too. I'll check it later. 569659 22 yong.li.webkit 2012-03-02 08:19:14 -0800 (In reply to comment #20) > The very same failure happens on GTK bots as well. Is it also 64-bit linux? There isn't difference between QT and GTK in JS engine as long as the OS and CPU are same. I tried the instructions of building GTK port. But it fails "due to non buildable" gdk-pixbuf and other libs. Any idea? 569666 23 pnormand 2012-03-02 08:32:31 -0800 (In reply to comment #22) > (In reply to comment #20) > > The very same failure happens on GTK bots as well. > > Is it also 64-bit linux? There isn't difference between QT and GTK in JS engine as long as the OS and CPU are same. I tried the instructions of building GTK port. But it fails "due to non buildable" gdk-pixbuf and other libs. Any idea? Yes, I think it was only happening on the 2 64-bit GTK bots. For your build issues maybe we can discuss on IRC? My nickname is philn-tp. 569816 24 yong.li.webkit 2012-03-02 11:53:11 -0800 Actually reporting 64MB cost doesn't always trigger GC. We modified reportExtraMemoryCostSlowCase() to always do a GC instead. And we cannot see any problem on Mac 64-bit (Safari), Linux 32-bit (Qt) and QNX. (Many thanks to Jacky Jiang's help for making qtwebkit build on linux and safari build on Mac.) 643538 25 yong.li.webkit 2012-06-07 07:30:08 -0700 Can someone who (In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #20) > > > The very same failure happens on GTK bots as well. > > > > Is it also 64-bit linux? There isn't difference between QT and GTK in JS engine as long as the OS and CPU are same. I tried the instructions of building GTK port. But it fails "due to non buildable" gdk-pixbuf and other libs. Any idea? > > Yes, I think it was only happening on the 2 64-bit GTK bots. > For your build issues maybe we can discuss on IRC? My nickname is philn-tp. Is this problem still happening? There seems to be a pthread mutex issue on some 64bit linux, which I think can lead to any kind of weird crash. https://bugs.webkit.org/show_bug.cgi?id=88419 Could you try this change (suggested by Joe)? > As a quick hack, try changing "PlatformMutex m_mutex;" in > ThreadingPrimitives.h to "WTF_ALIGNED(PlatformMutex, m_mutex, 64);" 128845 2012-02-24 20:42:15 -0800 2012-02-28 08:02:22 -0800 the patch 79555.patch text/plain 2086 yong.li.webkit ZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cgYi9Tb3VyY2UvSmF2 YVNjcmlwdENvcmUvQ2hhbmdlTG9nCmluZGV4IDQzMTRmMTIuLmM2Mzk4MTkgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL0phdmFTY3JpcHRD b3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE4IEBACisyMDEyLTAyLTI0ICBZb25nIExpICA8eW9s aUByaW0uY29tPgorCisgICAgICAgIEpTU3RyaW5nOjpyZXNvbHZlUm9wZSgpIHNob3VsZCByZXBv cnQgZXh0cmEgbWVtb3J5IGNvc3QgdG8gdGhlIGhlYXAuCisgICAgICAgIGh0dHBzOi8vYnVncy53 ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD03OTU1NQorCisgICAgICAgIFJldmlld2VkIGJ5IE5P Qk9EWSAoT09QUyEpLgorCisgICAgICAgIEF0IHRoZSB0aW1lIGEgSlNTdHJpbmcgaXMgY29uc3Ry dWN0ZWQgd2l0aCBmaWJlcnMsIGl0IGRvZXNuJ3QgcmVwb3J0CisgICAgICAgIGV4dHJhIG1lbW9y eSBjb3N0LCB3aGljaCBpcyByZWFzb25hYmxlIGJlY2F1c2UgaXQgaGFzbid0IGFsbG9jYXRlCisg ICAgICAgIG5ldyBtZW1vcnkuIEhvd2V2ZXIgd2hlbiB0aGUgcm9wZSBpcyByZXNvbHZlZCwgaXQg c2hvdWxkIHJlcG9ydCBtZW9yeQorICAgICAgICBjb3N0IGZvciB0aGUgbmV3IGJ1ZmZlci4KKwor ICAgICAgICAqIHJ1bnRpbWUvSlNTdHJpbmcuY3BwOgorICAgICAgICAoSlNDOjpKU1N0cmluZzo6 cmVzb2x2ZVJvcGUpOgorCiAyMDEyLTAyLTI0ICBGaWxpcCBQaXpsbyAgPGZwaXpsb0BhcHBsZS5j b20+CiAKICAgICAgICAgREZHIHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSB2YXJpYWJsZXMgZ2V0 dGluZyBjYXB0dXJlZApkaWZmIC0tZ2l0IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL3J1bnRpbWUv SlNTdHJpbmcuY3BwIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL3J1bnRpbWUvSlNTdHJpbmcuY3Bw CmluZGV4IGNmYTdkMDMuLmU4NGNlMzYgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29y ZS9ydW50aW1lL0pTU3RyaW5nLmNwcAorKysgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvcnVudGlt ZS9KU1N0cmluZy5jcHAKQEAgLTY1LDkgKzY1LDEwIEBAIHZvaWQgSlNTdHJpbmc6OnJlc29sdmVS b3BlKEV4ZWNTdGF0ZSogZXhlYykgY29uc3QKIAogICAgIGlmIChpczhCaXQoKSkgewogICAgICAg ICBMQ2hhciogYnVmZmVyOwotICAgICAgICBpZiAoUmVmUHRyPFN0cmluZ0ltcGw+IG5ld0ltcGwg PSBTdHJpbmdJbXBsOjp0cnlDcmVhdGVVbmluaXRpYWxpemVkKG1fbGVuZ3RoLCBidWZmZXIpKQor ICAgICAgICBpZiAoUmVmUHRyPFN0cmluZ0ltcGw+IG5ld0ltcGwgPSBTdHJpbmdJbXBsOjp0cnlD cmVhdGVVbmluaXRpYWxpemVkKG1fbGVuZ3RoLCBidWZmZXIpKSB7CisgICAgICAgICAgICBIZWFw OjpoZWFwKHRoaXMpLT5yZXBvcnRFeHRyYU1lbW9yeUNvc3QobmV3SW1wbC0+Y29zdCgpKTsKICAg ICAgICAgICAgIG1fdmFsdWUgPSBuZXdJbXBsLnJlbGVhc2UoKTsKLSAgICAgICAgZWxzZSB7Cisg ICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICBvdXRPZk1lbW9yeShleGVjKTsKICAgICAgICAg ICAgIHJldHVybjsKICAgICAgICAgfQpAQCAtOTIsOSArOTMsMTAgQEAgdm9pZCBKU1N0cmluZzo6 cmVzb2x2ZVJvcGUoRXhlY1N0YXRlKiBleGVjKSBjb25zdAogICAgIH0KIAogICAgIFVDaGFyKiBi dWZmZXI7Ci0gICAgaWYgKFJlZlB0cjxTdHJpbmdJbXBsPiBuZXdJbXBsID0gU3RyaW5nSW1wbDo6 dHJ5Q3JlYXRlVW5pbml0aWFsaXplZChtX2xlbmd0aCwgYnVmZmVyKSkKKyAgICBpZiAoUmVmUHRy PFN0cmluZ0ltcGw+IG5ld0ltcGwgPSBTdHJpbmdJbXBsOjp0cnlDcmVhdGVVbmluaXRpYWxpemVk KG1fbGVuZ3RoLCBidWZmZXIpKSB7CisgICAgICAgIEhlYXA6OmhlYXAodGhpcyktPnJlcG9ydEV4 dHJhTWVtb3J5Q29zdChuZXdJbXBsLT5jb3N0KCkpOwogICAgICAgICBtX3ZhbHVlID0gbmV3SW1w bC5yZWxlYXNlKCk7Ci0gICAgZWxzZSB7CisgICAgfSBlbHNlIHsKICAgICAgICAgb3V0T2ZNZW1v cnkoZXhlYyk7CiAgICAgICAgIHJldHVybjsKICAgICB9Cg== 129102 2012-02-27 14:51:30 -0800 2012-02-27 14:54:56 -0800 a test case (just load it in Safari) creatstrings.html text/html 407 yong.li.webkit PGh0bWw+Cjxib2R5Pgo8cCBpZD0ibnVtYmVyIj48L3A+CjxzY3JpcHQ+CnZhciBzMSA9ICJhYWFh YSI7CndoaWxlIChzMS5sZW5ndGggPCAxMDI0KQogICAgczEgKz0gczE7CnZhciBzMiA9IHMxOwpm dW5jdGlvbiBtYWtlTmV3U3RyaW5nKCkKewogICAgdmFyIHN0YXJ0ID0gbmV3IERhdGUoKTsKICAg IGRvIHsKICAgICAgICBzMiA9IHMxICsgczI7CiAgICAgICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5 SWQoIm51bWJlciIpLmlubmVySFRNTCA9IHMyLnN1YnN0cmluZygyMCwgMzApOwogICAgfSB3aGls ZSAobmV3IERhdGUoKSAtIHN0YXJ0IDwgNTAwMCk7CiAgICBzZXRUaW1lb3V0KG1ha2VOZXdTdHJp bmcsIDApOwp9CnNldFRpbWVvdXQobWFrZU5ld1N0cmluZywgMCk7Cjwvc2NyaXB0Pgo8L2JvZHk+ CjwvaHRtbD4=