Merge lp:~smspillaz/compiz-core/compiz-core.fix_931927 into lp:compiz-core

Proposed by Sam Spilsbury
Status: Merged
Merged at revision: 3010
Proposed branch: lp:~smspillaz/compiz-core/compiz-core.fix_931927
Merge into: lp:compiz-core
Diff against target: 420 lines (+87/-89)
9 files modified
include/core/abiversion.h (+1/-1)
include/core/option.h (+3/-3)
include/core/plugin.h (+2/-2)
plugins/move/src/move.cpp (+7/-7)
plugins/resize/src/resize.cpp (+7/-7)
src/event.cpp (+1/-1)
src/option.cpp (+62/-64)
src/plugin.cpp (+1/-1)
src/session.cpp (+3/-3)
To merge this branch: bzr merge lp:~smspillaz/compiz-core/compiz-core.fix_931927
Reviewer Review Type Date Requested Status
Alan Griffiths Approve
Daniel van Vugt Approve
Tim Penhey Pending
Review via email: mp+93779@code.launchpad.net

This proposal supersedes a proposal from 2012-02-16.

Description of the change

Only call removeAction on the CompOption destructor and not the CompOption::Value
destructor, since plugins that make copies of CompOption::Value can cause actions to
be added through setOptionForPlugin and then those actions will be removed when the
value temporary goes away.

The action adding and removing only happens within the bounds of CompOption anyways, so
its its more appropriate to have it in its destructor.

Of course, this brings up another issue, which is that CompOption should be noncopyable
but this opens up a whole another can of worms.

How this even worked before is beyond me...

bug 931927

(See also lp:~smspillaz/compiz-expo-plugin/compiz-expo-plugin.api_change_931927)

To post a comment you must log in.
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

The noOptions API change makes me nervous. Especially the part about returning a reference to a static local:

203 +CompOption::Vector &
204 +noOptions ()
205 +{
206 + static CompOption::Vector v (0);
207 + return v;
208 +}

Why not just change the global:
    CompOption::Vector noOptions (0);
to:
    const CompOption::Vector noOptions (0);
??

review: Needs Information
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

And change:
    extern CompOption::Vector noOptions;
to:
    extern const CompOption::Vector noOptions;

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

And the same for all of:
164 -CompOption::Vector noOptions (0);
165 -CompOption::Value::Vector emptyList;
166 -CompString emptyString;
167 -CompMatch emptyMatch;
168 -CompAction emptyAction;
169 -unsigned short emptyColor[4];

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

All the globals should remain globals instead of functions. Perhaps convert them to const for safety.

review: Needs Fixing
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Static initialization and destruction, basically.

There's a case where the destructor would be called on the global when a plugin was loaded (compiler, linker bug?) before it was actually fully constructed.

I would have made them const, but a lot of the Option* code requires a non const reference. It worked fine even when the globals weren't const, so I don't think this is an issue.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

OK, that's not a compiler/linker/loader bug at all. That is correct behaviour. I have seen many such static ctor/dtor DSO bugs on various Unixes before, but not Linux, at least not for ~10 years.

The real problem must be globals using other globals during their construction/destruction (again). That's what really needs fixing I think.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Its not worth fixing in this branch :)

The best way to get around this fiasco, is like the article says, to use the construct-upon-access idiom which is what I have done here.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

> OK, that's not a compiler/linker/loader bug at all. That is correct behaviour.
> I have seen many such static ctor/dtor DSO bugs on various Unixes before, but
> not Linux, at least not for ~10 years.

To clarify, I guess the reason why I said linker bug was because of this

#0 CompAction::active
#1 CompOption::~CompOption // wtf ?
#2 __static_initialization_and_destruction

The use of uninitialized globals within the constructors of other globals is fine, but calling the destructor to a static object before we hit main () is very strange indeed.

(And yes, I've hit compiler bugs before where destructors were incorrectly called :P)

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

OK, I agree it's a quick fix that should work, even though it impacts the public API in a less than ideal way.

Alan already started logging bugs describing the removal of globals such as screen (in the distant future)...

review: Abstain
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

And I do believe you now :)

But you will probably find some obscure DSO-related reason for the apparently premature destruction.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

> OK, I agree it's a quick fix that should work, even though it impacts the
> public API in a less than ideal way.
>
> Alan already started logging bugs describing the removal of globals such as
> screen (in the distant future)...

The good news is that only one plugin was impacted by this.

It would be so awesome if const references could be NULL. I guess that's what exceptions are for.

Revision history for this message
Tim Penhey (thumper) wrote : Posted in a previous version of this proposal

I have to agree with Daniel on a number of points. This is kinda ick, but
better than nothing as far as I can tell.

Might as well remove the boost/noncopyable header since you are not using it.

You do hit a couple of differences here.

Static initialisation initially zeros things out. So...

unsigned short emptyColor[4];
would be zero initialised.

When you have a static variable in a function, I don't think it is zero
initialised. Worth checking with Alan about that. So, inside the emptyColor
function use:
  static unsigned short v[4] = {0,0,0,0};

We need to file bugs about the catch (...) bits, that's just ick.

I can't comment on whether this fix actually works. Ideally we'd have test
coverage :-(

review: Needs Fixing
Revision history for this message
Tim Penhey (thumper) wrote : Posted in a previous version of this proposal

> And I do believe you now :)
>
> But you will probably find some obscure DSO-related reason for the apparently
> premature destruction.

What do you mean by DSO-related?

And I have to say that everytime I've come across a weird destruction bug, whether mis-timed or double delete, it has been a coding error, not the compiler.

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

I mean that if this destruction issue /is/ a bug then it is most likely triggered by using dynamic shared objects. I've seen many such loader/construction/destruction bugs before. But none in Linux since at least before Ubuntu existed.

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

Re: "Static initialisation initially zeros things out"

Is that in the C++ spec? As far as I know, basic types like;
    unsigned short emptyColor[4];
will not be initialized at all, because they don't have a constructor.

Revision history for this message
Tim Penhey (thumper) wrote : Posted in a previous version of this proposal

> Re: "Static initialisation initially zeros things out"
>
> Is that in the C++ spec? As far as I know, basic types like;
> unsigned short emptyColor[4];
> will not be initialized at all, because they don't have a constructor.

Normally no, but for statics / globals, yes.

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

If that's true I would still recommend explicit initialization for the sake of readability :)

Revision history for this message
Tim Penhey (thumper) : Posted in a previous version of this proposal
review: Approve
Revision history for this message
Alan Griffiths (alan-griffiths) wrote : Posted in a previous version of this proposal

> Re: "Static initialisation initially zeros things out"
>
> Is that in the C++ spec? As far as I know, basic types like;
> unsigned short emptyColor[4];
> will not be initialized at all, because they don't have a constructor.

Local statics have a special case (don't you just love C++) - they are zero initialized (the same as namespace scope variables - which is what they are to the link loader).

Revision history for this message
Alan Griffiths (alan-griffiths) wrote : Posted in a previous version of this proposal

Oh, and you don't need

"static unsigned short v[4] = {0,0,0,0};"

either:

"static unsigned short v[] = {0,0,0,0};"

or

"static unsigned short v[4] = {0};"

is fine

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

*** Found the problem ***

CompOption::Vector noOptions (0);
causes a reserve of at least one CompOption to be constructed (and then quickly destructed)

The fix is to change:
    CompOption::Vector noOptions (0);
to:
    CompOption::Vector noOptions;

review: Needs Fixing
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

> *** Found the problem ***
>
> CompOption::Vector noOptions (0);
> causes a reserve of at least one CompOption to be constructed (and then
> quickly destructed)
>
> The fix is to change:
> CompOption::Vector noOptions (0);
> to:
> CompOption::Vector noOptions;

It is still better to use the on-demand construction, for reasons specified above. I'll fix this though.

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

This means we don't need to change the public API of "noOptions" or need to change any plugins. You're now doing it for stylistic reasons only. :)

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

There is still a risk involved. I'd much prefer to have less risky code then to be tripped up later.

This isn't "purely stylistic"

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

(Also as evidenced by the fact that PrivateAction was not even created during static initialization and destruction makes me more inclined to make it like this)

Revision history for this message
Alan Griffiths (alan-griffiths) wrote : Posted in a previous version of this proposal

170 + CompString & emptyString ()

Rather invites:

emptyString () = CompString("Murphy rules!");

(The same applies to a lot of the functions, and the original [non-]constants.)

So, we should add const to the "constants" while addressing this problem.

On the comment discussion: Global data, monostate & singleton are all likely causes for issues. So this code could do with some cleanup regardless of "on demand" or "global data".

As Sam says, it is slightly safer to use "on demand" than global variables - as it ensures they have actually been initialized before use. OTOH, if we "know" there is no init-sequence issue that only makes the design marginally better.

So, I wouldn't have done the "wrapping" if the problem can be fixed more simply. But, if we had the code ready to go I'd take it, it make the codebase a safer place to live.

review: Needs Fixing
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

I can remove all the global data, but I can tell you know that the diff is going to get a *lot* bigger (ditto for adding constness)

Revision history for this message
Tim Penhey (thumper) wrote : Posted in a previous version of this proposal

Sam, if the change to the vector constructor is enough to fix this bug, we should go with the simplest possible branch.

Revision history for this message
Tim Penhey (thumper) wrote : Posted in a previous version of this proposal

I have to admit to preferring to use the default constructor for vectors rather than trying to be clever with the size. It also means that people don't have to go and look for what the integer parameter constructor does.

Revision history for this message
Alan Griffiths (alan-griffiths) wrote : Posted in a previous version of this proposal

"Don't initialize to list size zero since that creates a temporary and destroys it
(for gosh knows what reasons)"

That's because it calls a constructor with a default parameter. Vis:

CompOption::Vector(o, CompOption());

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

I'd really like to know what all the push back on delaying initialization till use is, its a far safer way of doing things and doesn't have any obvious drawbacks.

Revision history for this message
Tim Penhey (thumper) wrote : Posted in a previous version of this proposal

Please also change the constructor in noOptions too:

  static CompOption::Vector v (0);

should be:

  static CompOption::Vector v;

Given that there were also issues around the ordering of the static object initialisation that Sam said he saw, I'm in favour of landing this branch. However, we should look to clean the whole mess up soonish.

I want to know though what the impact is of making these constants.

review: Needs Fixing
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

Yes indeed on demand construction is more than stylistic. I think my clumsy words missed the point there. My point should have been that on demand construction (while being good for preventative maintenance), is causing a lot more code to change just before a release. And that's a risk.

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

Conditionally approved, pending the 1-line fix Tim mentioned:
210 + static CompOption::Vector v (0);
becomes:
210 + static CompOption::Vector v;

I've also tested for further API breakage in libcompizconfig, compiz-plugins-main and compiz-plugins-extra. Only main (expo) failed, which Sam has already proposed a fix for.

review: Approve
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Impact of removing the const is that we need to remove these

CompAction &
CompOption::Value::action ()
{
    try
    {
 return boost::get<CompAction>(mValue);
    }
    catch (...)
    {
 return emptyAction ();
    }
}

CompMatch &
CompOption::Value::match ()
{
    try
    {
 return boost::get<CompMatch>(mValue);
    }
    catch (...)
    {
 return emptyMatch ();
    }
}

CompString &
CompOption::Value::s ()
{
    try
    {
 return boost::get < CompString > (mValue);
    }
    catch (...)
    {
 return emptyString ();
    }
}

which I am +1 for but I'm not sure how much client code uses these

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Satisfies my previous comment.

review: Approve
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

Reads OK.

Still concerned about the lack of const-safety, But willing to leave that for posterity.

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
=== modified file 'include/core/abiversion.h'
--- include/core/abiversion.h 2012-01-25 13:46:33 +0000
+++ include/core/abiversion.h 2012-02-20 08:16:21 +0000
@@ -5,6 +5,6 @@
5# error Conflicting definitions of CORE_ABIVERSION5# error Conflicting definitions of CORE_ABIVERSION
6#endif6#endif
77
8#define CORE_ABIVERSION 201201258#define CORE_ABIVERSION 20120216
99
10#endif // COMPIZ_ABIVERSION_H10#endif // COMPIZ_ABIVERSION_H
1111
=== modified file 'include/core/option.h'
--- include/core/option.h 2012-01-31 14:52:20 +0000
+++ include/core/option.h 2012-02-20 08:16:21 +0000
@@ -47,7 +47,8 @@
47 * A configuration option with boolean, int, float, String, Color, Key, Button,47 * A configuration option with boolean, int, float, String, Color, Key, Button,
48 * Edge, Bell, or List.48 * Edge, Bell, or List.
49 */49 */
50class CompOption {50class CompOption
51{
51 /**52 /**
52 * Option data types53 * Option data types
53 */54 */
@@ -375,7 +376,6 @@
375 set (t);376 set (t);
376}377}
377378
378379CompOption::Vector & noOptions ();
379extern CompOption::Vector noOptions;
380380
381#endif381#endif
382382
=== modified file 'include/core/plugin.h'
--- include/core/plugin.h 2012-02-01 17:49:07 +0000
+++ include/core/plugin.h 2012-02-20 08:16:21 +0000
@@ -268,7 +268,7 @@
268{268{
269 CompOption::Class *oc = dynamic_cast<CompOption::Class *> (T::get (screen));269 CompOption::Class *oc = dynamic_cast<CompOption::Class *> (T::get (screen));
270 if (!oc)270 if (!oc)
271 return noOptions;271 return noOptions ();
272 return oc->getOptions ();272 return oc->getOptions ();
273}273}
274274
@@ -306,7 +306,7 @@
306{306{
307 CompOption::Class *oc = dynamic_cast<CompOption::Class *> (T::get (screen));307 CompOption::Class *oc = dynamic_cast<CompOption::Class *> (T::get (screen));
308 if (!oc)308 if (!oc)
309 return noOptions;309 return noOptions ();
310 return oc->getOptions ();310 return oc->getOptions ();
311}311}
312312
313313
=== modified file 'plugins/move/src/move.cpp'
--- plugins/move/src/move.cpp 2012-02-01 14:03:38 +0000
+++ plugins/move/src/move.cpp 2012-02-20 08:16:21 +0000
@@ -511,7 +511,7 @@
511 {511 {
512 moveTerminate (&optionGetInitiateButton (),512 moveTerminate (&optionGetInitiateButton (),
513 CompAction::StateTermButton,513 CompAction::StateTermButton,
514 noOptions);514 noOptions ());
515 }515 }
516 }516 }
517 }517 }
@@ -606,9 +606,9 @@
606 if (ms->w->id () == event->xclient.window)606 if (ms->w->id () == event->xclient.window)
607 {607 {
608 moveTerminate (&optionGetInitiateButton (),608 moveTerminate (&optionGetInitiateButton (),
609 CompAction::StateCancel, noOptions);609 CompAction::StateCancel, noOptions ());
610 moveTerminate (&optionGetInitiateKey (),610 moveTerminate (&optionGetInitiateKey (),
611 CompAction::StateCancel, noOptions);611 CompAction::StateCancel, noOptions ());
612612
613 }613 }
614 }614 }
@@ -617,15 +617,15 @@
617 case DestroyNotify:617 case DestroyNotify:
618 if (w && w->id () == event->xdestroywindow.window)618 if (w && w->id () == event->xdestroywindow.window)
619 {619 {
620 moveTerminate (&optionGetInitiateButton (), 0, noOptions);620 moveTerminate (&optionGetInitiateButton (), 0, noOptions ());
621 moveTerminate (&optionGetInitiateKey (), 0, noOptions);621 moveTerminate (&optionGetInitiateKey (), 0, noOptions ());
622 }622 }
623 break;623 break;
624 case UnmapNotify:624 case UnmapNotify:
625 if (w && w->id () == event->xunmap.window)625 if (w && w->id () == event->xunmap.window)
626 {626 {
627 moveTerminate (&optionGetInitiateButton (), 0, noOptions);627 moveTerminate (&optionGetInitiateButton (), 0, noOptions ());
628 moveTerminate (&optionGetInitiateKey (), 0, noOptions);628 moveTerminate (&optionGetInitiateKey (), 0, noOptions ());
629 }629 }
630 default:630 default:
631 break;631 break;
632632
=== modified file 'plugins/resize/src/resize.cpp'
--- plugins/resize/src/resize.cpp 2012-02-09 07:48:57 +0000
+++ plugins/resize/src/resize.cpp 2012-02-20 08:16:21 +0000
@@ -1259,7 +1259,7 @@
1259 CompAction *action = &optionGetInitiateButton ();1259 CompAction *action = &optionGetInitiateButton ();
12601260
1261 resizeTerminate (action, CompAction::StateTermButton,1261 resizeTerminate (action, CompAction::StateTermButton,
1262 noOptions);1262 noOptions ());
1263 }1263 }
1264 }1264 }
1265 }1265 }
@@ -1356,9 +1356,9 @@
1356 if (rs->w->id () == event->xclient.window)1356 if (rs->w->id () == event->xclient.window)
1357 {1357 {
1358 resizeTerminate (&optionGetInitiateButton (),1358 resizeTerminate (&optionGetInitiateButton (),
1359 CompAction::StateCancel, noOptions);1359 CompAction::StateCancel, noOptions ());
1360 resizeTerminate (&optionGetInitiateKey (),1360 resizeTerminate (&optionGetInitiateKey (),
1361 CompAction::StateCancel, noOptions);1361 CompAction::StateCancel, noOptions ());
1362 }1362 }
1363 }1363 }
1364 }1364 }
@@ -1366,15 +1366,15 @@
1366 case DestroyNotify:1366 case DestroyNotify:
1367 if (w && w->id () == event->xdestroywindow.window)1367 if (w && w->id () == event->xdestroywindow.window)
1368 {1368 {
1369 resizeTerminate (&optionGetInitiateButton (), 0, noOptions);1369 resizeTerminate (&optionGetInitiateButton (), 0, noOptions ());
1370 resizeTerminate (&optionGetInitiateKey (), 0, noOptions);1370 resizeTerminate (&optionGetInitiateKey (), 0, noOptions ());
1371 }1371 }
1372 break;1372 break;
1373 case UnmapNotify:1373 case UnmapNotify:
1374 if (w && w->id () == event->xunmap.window)1374 if (w && w->id () == event->xunmap.window)
1375 {1375 {
1376 resizeTerminate (&optionGetInitiateButton (), 0, noOptions);1376 resizeTerminate (&optionGetInitiateButton (), 0, noOptions ());
1377 resizeTerminate (&optionGetInitiateKey (), 0, noOptions);1377 resizeTerminate (&optionGetInitiateKey (), 0, noOptions ());
1378 }1378 }
1379 default:1379 default:
1380 break;1380 break;
13811381
=== modified file 'src/event.cpp'
--- src/event.cpp 2012-02-17 09:17:31 +0000
+++ src/event.cpp 2012-02-20 08:16:21 +0000
@@ -306,7 +306,7 @@
306 {306 {
307 if (!o.value ().action ().terminate ().empty ())307 if (!o.value ().action ().terminate ().empty ())
308 o.value ().action ().terminate () (&o.value ().action (),308 o.value ().action ().terminate () (&o.value ().action (),
309 state, noOptions);309 state, noOptions ());
310 }310 }
311 }311 }
312312
313313
=== modified file 'src/option.cpp'
--- src/option.cpp 2012-02-08 15:31:32 +0000
+++ src/option.cpp 2012-02-20 08:16:21 +0000
@@ -35,12 +35,47 @@
35#include <core/option.h>35#include <core/option.h>
36#include "privateoption.h"36#include "privateoption.h"
3737
38CompOption::Vector noOptions (0);38namespace
39CompOption::Value::Vector emptyList;39{
40CompString emptyString;40 CompOption::Value::Vector & emptyList ()
41CompMatch emptyMatch;41 {
42CompAction emptyAction;42 static CompOption::Value::Vector v;
43unsigned short emptyColor[4];43 return v;
44 }
45
46 CompString & emptyString ()
47 {
48 static CompString v;
49 return v;
50 }
51
52 CompMatch & emptyMatch ()
53 {
54 static CompMatch v;
55 return v;
56 }
57
58 CompAction & emptyAction ()
59 {
60 static CompAction v;
61 return v;
62 }
63
64 unsigned short * emptyColor ()
65 {
66 static unsigned short v[4] = { 0, 0, 0, 0 };
67 return v;
68 }
69}
70
71CompOption::Vector &
72noOptions ()
73{
74 static CompOption::Vector v;
75 return v;
76}
77
78
4479
45static bool80static bool
46checkIsAction (CompOption::Type type)81checkIsAction (CompOption::Type type)
@@ -59,32 +94,8 @@
59 return false;94 return false;
60}95}
6196
62static void
63finiOptionValue (CompOption::Value &v)
64{
65 switch (v.type()) {
66 case CompOption::TypeAction:
67 case CompOption::TypeKey:
68 case CompOption::TypeButton:
69 case CompOption::TypeEdge:
70 case CompOption::TypeBell:
71 if (v.action ().state () & CompAction::StateAutoGrab && screen)
72 screen->removeAction (&v.action ());
73 break;
74
75 case CompOption::TypeList:
76 foreach (CompOption::Value &val, v.list ())
77 finiOptionValue (val);
78 break;
79
80 default:
81 break;
82 }
83}
84
85CompOption::Value::~Value()97CompOption::Value::~Value()
86{98{
87 finiOptionValue(*this);
88}99}
89100
90void101void
@@ -142,7 +153,7 @@
142 }153 }
143 catch (...)154 catch (...)
144 {155 {
145 return emptyColor;156 return emptyColor ();
146 }157 }
147}158}
148159
@@ -155,7 +166,7 @@
155 }166 }
156 catch (...)167 catch (...)
157 {168 {
158 return emptyString;169 return emptyString ();
159 }170 }
160}171}
161172
@@ -168,7 +179,7 @@
168 }179 }
169 catch (...)180 catch (...)
170 {181 {
171 return emptyString;182 return emptyString ();
172 }183 }
173}184}
174185
@@ -181,7 +192,7 @@
181 }192 }
182 catch (...)193 catch (...)
183 {194 {
184 return emptyMatch;195 return emptyMatch ();
185 }196 }
186}197}
187198
@@ -194,7 +205,7 @@
194 }205 }
195 catch (...)206 catch (...)
196 {207 {
197 return emptyMatch;208 return emptyMatch ();
198 }209 }
199}210}
200211
@@ -207,7 +218,7 @@
207 }218 }
208 catch (...)219 catch (...)
209 {220 {
210 return emptyAction;221 return emptyAction ();
211 }222 }
212}223}
213224
@@ -220,7 +231,7 @@
220 }231 }
221 catch (...)232 catch (...)
222 {233 {
223 return emptyAction;234 return emptyAction ();
224 }235 }
225}236}
226237
@@ -235,7 +246,7 @@
235 }246 }
236 catch (...)247 catch (...)
237 {248 {
238 return emptyList;249 return emptyList ();
239 }250 }
240}251}
241252
@@ -248,7 +259,7 @@
248 }259 }
249 catch (...)260 catch (...)
250 {261 {
251 return emptyList;262 return emptyList ();
252 }263 }
253}264}
254265
@@ -416,33 +427,20 @@
416 setName (name, type);427 setName (name, type);
417}428}
418429
419static void
420finiScreenOptionValue (CompScreen *s,
421 CompOption::Value &v)
422{
423 switch (v.type()) {
424 case CompOption::TypeAction:
425 case CompOption::TypeKey:
426 case CompOption::TypeButton:
427 case CompOption::TypeEdge:
428 case CompOption::TypeBell:
429 if (v.action ().state () & CompAction::StateAutoGrab)
430 s->removeAction (&v.action ());
431 break;
432
433 case CompOption::TypeList:
434 foreach (CompOption::Value &val, v.list ())
435 finiScreenOptionValue (s, val);
436 break;
437
438 default:
439 break;
440 }
441}
442
443CompOption::~CompOption ()430CompOption::~CompOption ()
444{431{
445 finiOptionValue (priv->value);432 /* Remove any added actions */
433 try
434 {
435 CompAction &action = value ().action ();
436
437 if (action.active () && screen)
438 screen->removeAction (&action);
439 }
440 catch (...)
441 {
442 }
443
446 delete priv;444 delete priv;
447}445}
448446
449447
=== modified file 'src/plugin.cpp'
--- src/plugin.cpp 2012-01-31 17:01:32 +0000
+++ src/plugin.cpp 2012-02-20 08:16:21 +0000
@@ -661,7 +661,7 @@
661CompOption::Vector &661CompOption::Vector &
662CompPlugin::VTable::getOptions ()662CompPlugin::VTable::getOptions ()
663{663{
664 return noOptions;664 return noOptions ();
665}665}
666666
667bool667bool
668668
=== modified file 'src/session.cpp'
--- src/session.cpp 2012-01-19 18:12:31 +0000
+++ src/session.cpp 2012-02-20 08:16:21 +0000
@@ -220,7 +220,7 @@
220dieCallback (SmcConn connection,220dieCallback (SmcConn connection,
221 SmPointer clientData)221 SmPointer clientData)
222{222{
223 screen->sessionEvent (CompSession::EventDie, noOptions);223 screen->sessionEvent (CompSession::EventDie, noOptions ());
224224
225 CompSession::close ();225 CompSession::close ();
226 exit (0);226 exit (0);
@@ -230,14 +230,14 @@
230saveCompleteCallback (SmcConn connection,230saveCompleteCallback (SmcConn connection,
231 SmPointer clientData)231 SmPointer clientData)
232{232{
233 screen->sessionEvent (CompSession::EventSaveComplete, noOptions);233 screen->sessionEvent (CompSession::EventSaveComplete, noOptions ());
234}234}
235235
236static void236static void
237shutdownCancelledCallback (SmcConn connection,237shutdownCancelledCallback (SmcConn connection,
238 SmPointer clientData)238 SmPointer clientData)
239{239{
240 screen->sessionEvent (CompSession::EventShutdownCancelled, noOptions);240 screen->sessionEvent (CompSession::EventShutdownCancelled, noOptions ());
241}241}
242242
243void243void

Subscribers

People subscribed via source and target branches