Summary: | PPC Only: svg/custom/mask-excessive-malloc.svg crashes on trunk | ||
---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> |
Component: | SVG | Assignee: | 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
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. |