[Kde-bindings] Problem condition in Qyoto MethodCall

Arno Rehn arno at arnorehn.de
Sat Feb 10 16:23:13 UTC 2007


Am Samstag, 10. Februar 2007 schrieb Richard Dale:
> This is wrong, but I still haven't worked out what the correct version
> should be:
>
> // We have to check here, if our target does still exists.
> // If there is no entry in the weakRef Dictionary, the instance doesn't
> exist anymore.
> // There's also no entry, if the method is a constructor or the method is
> static.
> // If the target doesn't exist anymore, set _called to true so the method
> won't be invoked.
> // The other possibility is that the qApp was just destroyed and we want to
> call a destructor.
> // This could lead to a crash when we interfere with the destroying
> mechanism of Q(Core)Application.
> if ( ((getPointerObject(_current_object) == 0) && !_ctor && !(_tmp.flags &
> Smoke::mf_static))
>
>         || ((_tmp.flags & Smoke::mf_dtor) && (qApp == 0)) )
>
>         _called = true;
>
> Not every instance has an entry in the weak reference map. For example, I
> had a QVariant which was created in C++ code and it failed the condition
> and '_called' was set to true. Try the qdbus/pingpong example - it crashes
> when trying to access to QVariant returned.
Oops, didn't know that not every instance is in the weakRef map.

> We should only be looking at the 'o' and 'o->ptr' values and not call the
> method if they are zero and it's not a static method or constructor. I
> don't think we need to test for destructors at all because 'o->ptr' is set
> to 0 once something has been deleted (or it should be anyway).
Uhm, actually if we just test for o->ptr == 0 and the method not being a 
constructor it doesn't work. My code:
		if ((_current_object == 0) && !_ctor)
			_called = true;
Result:
*** glibc detected *** mono: free(): invalid pointer: 0xb6b94c9c ***
at startup.
As the problem with destructors just happens when the qApp is about to quit I 
think we shouldn't test for something being null at all, just if it is a 
destructor and if the qApp is about to quit. If so, don't call the 
destructor. If it still crashes somewhen else because the underlying C++ 
instance doesn't exist anymore, the problem will probably have another cause.

-- 
Arno Rehn
arno at arnorehn.de



More information about the Kde-bindings mailing list