It was in the suppression list already, just shifted around. The original bug isn't closed; it's marked as upstream, though I don't know if that's a significant difference :)
Feel free to play with it; I have some pixel tests to stare down. Avi On Wed, Sep 23, 2009 at 12:46 AM, Erik Kay <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
