Re: [FusionDev] [SCALE] Temporary fix for infinite loop
Hi, 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++. Can you try to track down what happens in the C version of scale in this scenario? The code you're talking about exists since quite some time in the C version, so something must be different in the C++ version. Regards, Danny ___ Dev mailing list Dev@lists.compiz-fusion.org http://lists.compiz-fusion.org/mailman/listinfo/dev
Re: [FusionDev] [SCALE] Temporary fix for infinite loop
On Fri, Feb 27, 2009 at 6:08 PM, Danny Baumann dannybaum...@web.de wrote: Hi, 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++. Can you try to track down what happens in the C version of scale in this scenario? The code you're talking about exists since quite some time in the C version, so something must be different in the C++ version. Sure, I'm not quite so sure about why the code existed in the scale plugin, clearly preventing any window that should be scaled from getting an ID number more than 0 would _always_ through compiz into an infinite loop due to the way fillInWindows works. I guess we can say that this was some kind of disaster waiting to happen... Kind Regards, Sam. Regards, Danny ___ Dev mailing list Dev@lists.compiz-fusion.org http://lists.compiz-fusion.org/mailman/listinfo/dev -- Sam Spilsbury ___ Dev mailing list Dev@lists.compiz-fusion.org http://lists.compiz-fusion.org/mailman/listinfo/dev
Re: [FusionDev] [SCALE] Temporary fix for infinite loop
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 Dev@lists.compiz-fusion.org http://lists.compiz-fusion.org/mailman/listinfo/dev
Re: [FusionDev] [SCALE] Temporary fix for infinite loop
OK, thanks. How did you track it down? Kind Regards, Sam. On Sat, Feb 28, 2009 at 1:14 AM, Dennis Kasprzyk onest...@compiz-fusion.org 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 Dev@lists.compiz-fusion.org http://lists.compiz-fusion.org/mailman/listinfo/dev -- Sam Spilsbury ___ Dev mailing list Dev@lists.compiz-fusion.org http://lists.compiz-fusion.org/mailman/listinfo/dev