Crashes both a local debug build (Safari or DRT) and r26041 nightly. Works fine in r25809 trunk nightly. I'm testing on a G4; Rob says this doesn't happen on an MBP. Crash log: Thread 0 Crashed: 0 com.apple.CoreGraphics 0x9058f1b8 W8_image_mark + 1784 Thread 1: 0 libSystem.B.dylib 0x9002c3c8 semaphore_wait_signal_trap + 8 1 libSystem.B.dylib 0x90030eac pthread_cond_wait + 480 2 com.apple.WebCore 0x012fca80 WebCore::IconDatabase::syncThreadMainLoop() + 320 3 com.apple.WebCore 0x012fcc68 WebCore::IconDatabase::iconDatabaseSyncThread() + 424 4 libSystem.B.dylib 0x9002bd08 _pthread_body + 96 Thread 2: 0 libSystem.B.dylib 0x9000b348 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000b29c mach_msg + 60 2 com.apple.CoreFoundation 0x907ddba8 __CFRunLoopRun + 832 3 com.apple.CoreFoundation 0x907dd4ac CFRunLoopRunSpecific + 268 4 com.apple.Foundation 0x92c097e8 +[NSURLCache _diskCacheSyncLoop:] + 152 5 com.apple.Foundation 0x92be11a0 forkThreadForFunction + 108 6 libSystem.B.dylib 0x9002bd08 _pthread_body + 96 Thread 3: 0 libSystem.B.dylib 0x9000b348 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000b29c mach_msg + 60 2 com.apple.CoreFoundation 0x907ddba8 __CFRunLoopRun + 832 3 com.apple.CoreFoundation 0x907dd4ac CFRunLoopRunSpecific + 268 4 com.apple.Foundation 0x92c086a8 +[NSURLConnection(NSURLConnectionInternal) _resourceLoadLoop:] + 264 5 com.apple.Foundation 0x92be11a0 forkThreadForFunction + 108 6 libSystem.B.dylib 0x9002bd08 _pthread_body + 96 Thread 4: 0 libSystem.B.dylib 0x9002c3c8 semaphore_wait_signal_trap + 8 1 libSystem.B.dylib 0x90030eac pthread_cond_wait + 480 2 com.apple.Foundation 0x92be830c -[NSConditionLock lockWhenCondition:] + 68 3 com.apple.Syndication 0x9b63142c -[AsyncDB _run:] + 192 4 com.apple.Foundation 0x92be11a0 forkThreadForFunction + 108 5 libSystem.B.dylib 0x9002bd08 _pthread_body + 96 Thread 5: 0 libSystem.B.dylib 0x9001f88c select + 12 1 com.apple.CoreFoundation 0x907f0434 __CFSocketManager + 472 2 libSystem.B.dylib 0x9002bd08 _pthread_body + 96 Thread 0 crashed with PPC Thread State 64: srr0: 0x000000009058f1b8 srr1: 0x000000000000d030 vrsave: 0x0000000000000000 cr: 0x84242424 xer: 0x0000000000000004 lr: 0x000000009058ecc8 ctr: 0x000000007fffece3 r0: 0x0000000000000020 r1: 0x00000000bfffb350 r2: 0x0000000000000044 r3: 0x0000000000000001 r4: 0x00000000c0000010 r5: 0x00000000bfffd9d8 r6: 0x000000007fffffff r7: 0x0000000090715d34 r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x000000000000006b r12: 0x0000000090592c9c r13: 0x0000000000000000 r14: 0x00000000000000ff r15: 0x0000000000008000 r16: 0x0000000000008000 r17: 0x0000000000000000 r18: 0x0000000000000000 r19: 0x0000000000000000 r20: 0x000000007fffffff r21: 0x00000000bfffb580 r22: 0x000000007fffffff r23: 0x0000000000000000 r24: 0x0000000000000000 r25: 0x0000000001b0f30c r26: 0x0000000000000000 r27: 0x0000000000000000 r28: 0x0000000006659048 r29: 0x0000000000000044 r30: 0x00000000bfffb380 r31: 0x000000009058eacc
That's wild. I would first try a clean-build just to make sure. I've seen GCC produce bad webcore binaries before which crash in all sorts of random places.
I've done a clean build a couple of days ago, after switching to feature branch.
*** Bug 15500 has been marked as a duplicate of this bug. ***
This affects trunk now that we've merged. The PowerPC build slaves are seeing this 100% of the time, but the Intel slaves are yet to hit it.
I don't have a PPC machine to test with. :( I can't reproduce this with my Intel machine. At least not under a normal run or MallocScribble (gmalloc takes half a day to run this test).
One possibility is that: CGContextRef cgContext = CGBitmapContextCreate(imageBuffer, size.width(), size.height(), 8, bytesPerRow, colorSpace, grayScale ? kCGImageAlphaNone : kCGImageAlphaPremultipliedLast); in ImageBuffer::create() could be crashing (or smashing memory) instead of failing gracefully like it does on Intel. I'm not even sure we're hitting that line (depends on how much memory you have available), but someone trying to debug this on PPC should see if guarding that call against really large values fixes the problem. (In which case this would definitely be a CG bug, code guards should be added to WebKit and this bug moved into Radar.)
Next guess: It's possible that the mask being huge is causing: RenderSVGContainer* maskContainer = new (arena) RenderSVGContainer(this); to have huge bounds, which is somehow angering CG via rendering tree redraw commands. I think this is rather unlikely however due to two reasons: 1. That content is never drawn during normal paint time (and thus perhaps should not layout normally either, not sure). 2. If it was due to renderer bounds, we should be seeing similar crashes due to extra large divs on PPC. (However SVG doesn't properly clip invalidation regions, so it's possible we're trying to invalidate a region larger than the screen and thus given CG kittens). Another possibility. It's possible that the malloc actually succeeds on PPC (on whatever hardware this was tested on), and that the CGContext create says it succeeds even though it created a bad context. That could cause us to crash at any sort of later time. Why we'd end up with no stack trace? no clue.
Bug should be fixed, by #15556. *** This bug has been marked as a duplicate of 15556 ***