We've replaced our perf. bot by a Lion machine. Since then, Dromaeo/jslib-modify-jquery.html has been crashing: http://build.webkit.org/builders/Chromium%20Mac%20Release%20%28Perf%29/builds/3710/steps/perf-test/logs/stdio Unfortunately the stack trace is useless and I don't have access to a Lion machine. DumpRenderTree(7178,0xac0ba2c0) malloc: *** mmap(size=15654912) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug 1 0xeabc44 2 0xeabacc 3 0xea4879 4 0xea7a69 5 0xeab094 6 0x707d33 7 0x707bd3 8 0x707902 9 0x6a2a4e 10 0xeb1e78 11 0xeb1e1c 12 0xe92e2d 13 0xe92c92 14 0x11355d7 15 0xcd3f2c 16 0xcd3e06 17 0x1719a81 18 0x37528a 19 0x3752c6 20 0x375451 21 0x356e5d 22 0x357241 23 0x33c505 24 0x9040513f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 25 0x90404af6 __CFRunLoopDoSources0 26 0x9042e9c8 __CFRunLoopRun 27 0x9042e1dc CFRunLoopRunSpecific 28 0x9042e088 CFRunLoopRunInMode 29 0x9bf4c723 RunCurrentEventLoopInMode 30 0x9bf53a8b ReceiveNextEventCommon 31 0x9bf538fa BlockUntilNextEventMatchingListInMode 0 DumpRenderTree 0x0034462a DumpRenderTree + 2795050 1 DumpRenderTree 0x00365d21 DumpRenderTree + 2932001 2 libsystem_c.dylib 0x9158d59b _sigtramp + 43 3 ??? 0xffffffff 0x0 + 4294967295 4 DumpRenderTree 0x00eabc44 DumpRenderTree + 14752836 5 DumpRenderTree 0x00eabacc DumpRenderTree + 14752460 6 DumpRenderTree 0x00ea4879 DumpRenderTree + 14723193 7 DumpRenderTree 0x00ea7a69 DumpRenderTree + 14735977 8 DumpRenderTree 0x00eab094 DumpRenderTree + 14749844 9 DumpRenderTree 0x00707d33 DumpRenderTree + 6741299 10 DumpRenderTree 0x00707bd3 DumpRenderTree + 6740947 11 DumpRenderTree 0x00707902 DumpRenderTree + 6740226 12 DumpRenderTree 0x006a2a4e DumpRenderTree + 6326862 13 DumpRenderTree 0x00eb1e78 DumpRenderTree + 14777976 14 DumpRenderTree 0x00eb1e1c DumpRenderTree + 14777884 15 DumpRenderTree 0x00e92e2d DumpRenderTree + 14650925 16 DumpRenderTree 0x00e92c92 DumpRenderTree + 14650514 17 DumpRenderTree 0x011355d7 DumpRenderTree + 17413591 18 DumpRenderTree 0x00cd3f2c DumpRenderTree + 12820268 19 DumpRenderTree 0x00cd3e06 DumpRenderTree + 12819974 20 DumpRenderTree 0x01719a81 DumpRenderTree + 23591553 21 DumpRenderTree 0x0037528a DumpRenderTree + 2994826 22 DumpRenderTree 0x003752c6 DumpRenderTree + 2994886 23 DumpRenderTree 0x00375451 DumpRenderTree + 2995281 24 DumpRenderTree 0x00356e5d DumpRenderTree + 2870877 25 DumpRenderTree 0x00357241 DumpRenderTree + 2871873 26 DumpRenderTree 0x0033c505 DumpRenderTree + 2761989 27 CoreFoundation 0x9040513f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15 28 CoreFoundation 0x90404af6 __CFRunLoopDoSources0 + 246 29 CoreFoundation 0x9042e9c8 __CFRunLoopRun + 1112 30 CoreFoundation 0x9042e1dc CFRunLoopRunSpecific + 332 31 CoreFoundation 0x9042e088 CFRunLoopRunInMode + 120 32 HIToolbox 0x9bf4c723 RunCurrentEventLoopInMode + 318 33 HIToolbox 0x9bf53a8b ReceiveNextEventCommon + 381 34 HIToolbox 0x9bf538fa BlockUntilNextEventMatchingListInMode + 88 35 AppKit 0x978740d8 _DPSNextEvent + 678 36 AppKit 0x97873942 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 113 37 AppKit 0x9786fcb1 -[NSApplication run] + 911 38 DumpRenderTree 0x0033c917 DumpRenderTree + 2763031 39 DumpRenderTree 0x0033c42c DumpRenderTree + 2761772 40 DumpRenderTree 0x003568bf DumpRenderTree + 2869439 41 DumpRenderTree 0x003560ed DumpRenderTree + 2867437 42 DumpRenderTree 0x001f5bc3 DumpRenderTree + 1424323 43 DumpRenderTree 0x000d0785 DumpRenderTree + 223109 44 DumpRenderTree 0x000cd241 DumpRenderTree + 209473 45 DumpRenderTree 0x000af701 DumpRenderTree + 87809 46 DumpRenderTree 0x000aeff5 DumpRenderTree + 86005 47 DumpRenderTree 0x000a5d06 DumpRenderTree + 48390 ax: 0, bx: fecc0, cx: 2860, dx: 1e00 di: fe18f000, si: 0, bp: c0095e88, sp: c0095e80, ss: 23, flags: 10246 ip: 14330a, cs: 1b, ds: 23, es: 23, fs: 0, gs: f
The failure doesn't happen when running just that test out of the Dromaeo suite, with either a Debug or Release build. However, one interesting data point is that the DRT process's memory consumption skyrockets during the test execution (gathered via 'top' and watching RPRVT). By the time the test was done running it was consuming some 2.7 GB. I think there is probably a resource leak and the test just happens to randomly run out of memory at that point.
I was able to reproduce it on Chromium/Linux. It consumes 4.2GB of memory. I'll look into it next week. Does this a regression?
It isn't known at this point whether it's a regression. As mentioned above, an easy side-by-side comparison would be to compare the behavior of Safari's DRT / WKTR port to Chromium's DRT.
FWIW this is also crashing on Windows, see bug 90598.
*** This bug has been marked as a duplicate of bug 95376 ***