OK, thanks. How did you track it down?
Kind Regards, Sam. On Sat, Feb 28, 2009 at 1:14 AM, Dennis Kasprzyk <[email protected]> wrote: > Was a bug in the compare function. Fixed it in > 59423aaf7e71cdd1fb52267065304a27394de2f7 > > Dennis > > Am Freitag 27 Februar 2009 05:23:33 schrieb Sam Spilsbury: >> Hi, >> >> Some of you might be aware that there is a critical bug in the >> compiz++ version of scale where if scale was initiated with more than >> 10 windows, compiz would go into an infinite loop, using 99% CPU and >> requiring that the user puts their system in single-user mode to get >> rid of compiz. >> >> I have tracked down the bug to a problem in findBestSlots () function >> in PrivateScaleScreen where the line 'if (d0 + d < sw->priv->distance) >> ...' meant that some windows were never assigned a slot ID number. >> This in turn meant that fillInWindows would fail to return false >> because two slots had the same ID number (0). This in turn meant that >> the 'do { .... } while (priv->fillInWindows ())' would become >> infinite. >> >> In order to fix this, I had to remove that if statement and assign an >> ID number to all windows that should be scaled. There are no >> regressions so far and scale appears to work with more than 200 >> windows open. sw->distance has been kept, but I don't see much of a >> reason for it, other than the compareWindowsDistance function. >> >> The patch is attached. Obviously, I would classify it as a workaround >> as that if statement was probably there for a reason (undocumented >> however), however if we can't fix this bug it would be a major >> stability regression once users move to compiz++. >> >> Kind Regards, >> >> Sam. > > > _______________________________________________ > Dev mailing list > [email protected] > http://lists.compiz-fusion.org/mailman/listinfo/dev > -- Sam Spilsbury _______________________________________________ Dev mailing list [email protected] http://lists.compiz-fusion.org/mailman/listinfo/dev
