So I got a reply from Apple saying this should be fixed in Snow Leopard. Is
it closable? Certainly keep it in the suppression list until we upgrade the
bots.
Avi
On Wed, Sep 23, 2009 at 12:46 AM, Erik Kay erik...@chromium.org wrote:
I didn't say it would be easy. ;-) I also wouldn't be
I'd say when we verify and remove the suppression, it's closable.
From a triage perspective, I think it's fine to lower priority, etc.
Erik
On Fri, Oct 2, 2009 at 2:11 PM, Avi Drissman a...@google.com wrote:
So I got a reply from Apple saying this should be fixed in Snow Leopard. Is
it
I'd suspect an alignment / positioning bug for what you're seeing.
Often rect fill algorithms have several paths with different loop
unrolling tricks based on the size and position of the rect. I agree
with Evan that it may be worth tracking this down a bit more. Even if
it's not our bug, we
If this is caught in the unit tests ~1/30 times, then it's happening despite
the window positionings and view positionings being the same. There's
multiple layers of indirection in there (two context types, four libraries)
all totally closed source. Tracking it down feels like it would take way
I didn't say it would be easy. ;-) I also wouldn't be surprised if
window position varied across unit test runs.
I think my main point here wasn't to drop everything you're doing to
track this down. I'm just saying that it's a dangerous bug to throw
into the supression list and forget about.
Could it possibly be related to passing a zero-sized rect in somewhere?
On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman a...@google.com wrote:
crbug.com/18189
crbug.com/18539
I got the first because it involved the status bubble; I got the second
because I got the first.
NSRectFill(). Deep
I have no evidence to confirm/deny that. Even so it deserves an upstreaming.
I'll look at it but why would it show up 1/30 times?
Avi
On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin e...@chromium.org wrote:
Could it possibly be related to passing a zero-sized rect in somewhere?
On Mon, Sep 21,
No idea! I was just suggesting that if it's possible to work around
it, you'd have less memory getting stomped. :)
On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman a...@google.com wrote:
I have no evidence to confirm/deny that. Even so it deserves an upstreaming.
I'll look at it but why would
