Re: [FusionDev] [SCALE] Temporary fix for infinite loop

2009-02-27 Thread Danny Baumann
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

2009-02-27 Thread Sam Spilsbury
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

2009-02-27 Thread Dennis Kasprzyk
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

2009-02-27 Thread Sam Spilsbury
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