Bug 15396

Summary: PPC Only: svg/custom/mask-excessive-malloc.svg crashes on trunk
Product: WebKit Reporter: Alexey Proskuryakov <ap>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: mrowe
Priority: P1 Keywords: NeedsReduction
Version: 523.x (Safari 3)   
Hardware: Mac (PowerPC)   
OS: OS X 10.4   

Description Alexey Proskuryakov 2007-10-06 03:15:38 PDT
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
Comment 1 Eric Seidel (no email) 2007-10-06 10:57:19 PDT
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.
Comment 2 Alexey Proskuryakov 2007-10-07 01:19:09 PDT
I've done a clean build a couple of days ago, after switching to feature branch.
Comment 3 Alexey Proskuryakov 2007-10-13 23:55:58 PDT
*** Bug 15500 has been marked as a duplicate of this bug. ***
Comment 4 Mark Rowe (bdash) 2007-10-14 00:00:09 PDT
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.
Comment 5 Eric Seidel (no email) 2007-10-14 22:28:05 PDT
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).
Comment 6 Eric Seidel (no email) 2007-10-14 22:49:22 PDT
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.)
Comment 7 Eric Seidel (no email) 2007-10-14 22:54:14 PDT
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.
Comment 8 Nikolas Zimmermann 2007-10-18 07:19:20 PDT
Bug should be fixed, by #15556.

*** This bug has been marked as a duplicate of 15556 ***