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