Causes argb32_image_mark to try to access bogus addresses such as 0xbdf7ded8. Similar to bug 455976, but not fixed by the patch in that bug.

No crash on my up-to-date Linux debug build, but I do get 4 copies of this warning message: nsBlockReflowContext: Block(div)(0)@0xad4777f8 metrics=408695144,1320!

Nominating for blocking1.9.1 since this looks [sg:critical?] and has a fairly simple testcase.

Still happens for me. Probably Mac-specific, since argb32_image_mark is deep in Apple's CoreGraphics code.

Still won't block on it; I have no idea what to do to fix it. I have a simplified C++-only testcase that I /think/ tickles the same bug (valgrind complains in the same space, but only once) that I sent off to apple.. they said "we can't reproduce, we don't think this is a bug". The testcase doesn't do anything specific, just sets up a clip and fills a rectangle, so there isn't a code pattern that we can avoid. I'm still working on this though; need to create a better testcase for them, I guess. The valgrind runs show that it is most likely a bug in their code and not in ours, though I'm still leaving the possibility open that it's in ours.. I just have no idea where if so..

I can't reproduce this anymore. I'm on 10.5.6

Likewise, I can't reproduce this on mozilla-1.9.1 tip or mozilla-central tip (or Firefox 3.0.8, but that's unsurprising since it's in moz-border-image). 10.5.6 -> WORKSFORME? Or would we consider a patch that only targeted older versions of Mac (assuming that this was a CoreGraphics fix?)

It looks like I can reproduce this on a nightly from Oct 6 2008. So it looks like we've accidentally fixed it somehow. It would probably be good to figure out how we fixed it.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090422 Minefield/3.6a1pre WFM