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
-~----------~----~----~----~------~----~------~--~---
