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
