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 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 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.
>>
>> Erik
>>
>>
>> On Tue, Sep 22, 2009 at 11:11 AM, Avi Drissman <a...@google.com> wrote:
>> > 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
>> > too
>> > much effort and I'm swamped. If you have some spare time...
>> >
>> > Avi
>> >
>> > On Tue, Sep 22, 2009 at 11:56 AM, Erik Kay <erik...@chromium.org> wrote:
>> >>
>> >> 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 need to find a way to avoid the memory stomping.
>> >> I'm nervous about adding this to the upstream suppression list. I
>> >> think that's OK to do for memory leaks, or for memory errors where
>> >> it's been demonstrated that the result of the error is benign (like
>> >> the UMRs in parts of Microsoft's STL implementation), but it doesn't
>> >> seem like this fits into that case.
>> >>
>> >> Erik
>> >>
>> >>
>> >> 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 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, 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 down that ends up in sseCGSFill8by1, which
>> >> >> > looks
>> >> >> > like
>> >> >> > it
>> >> >> > sometimes scribbles off the end of some buffer. I have no idea
>> >> >> > what
>> >> >> > we
>> >> >> > could
>> >> >> > be doing wrong to cause it nor what we could be doing to affect it
>> >> >> > at
>> >> >> > all. I
>> >> >> > want to just dup one to the other and mark both as
>> >> >> > CANNOTFIXBADAPPLECODE^WWontFix. Any objections?
>> >> >> >
>> >> >> > Avi
>> >> >> >
>> >> >> > >
>> >> >> >
>> >> >
>> >> >
>> >> > >> >> >
>> >> >
>> >
>> >
>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
