[Stackless] PySide problem, take #2: typeobject clash

[Kristján Valur Jónsson]

Yes. 
But, stackless tries to detect if a type has the proper stackless extensions, by a flag in the type's 'flag' entry:
Py_TPFLAGS_HAVE_STACKLESS_EXTENSION
Therefore, there shouldn't be confusion:

1) if Stackless sees a type defined by Shiboken, even with the shiboken extension, it shouldn't have this flag, and stackless should ignore it.
2) If Shiboken sees a type object from stackless, it won't do anything with it because it only adds the sbk extensions to its own types.
The issue is, imho, likely to be a problem with 1), a yet unidentified case in stackless where we assume all internal types to have the extension, i.e. fail to check for the presence of the flag.

K

> -----Original Message-----
> From: Christian Tismer [mailto:tismer at stackless.com]
> Sent: 8. desember 2012 21:45
> To: stackless at stackless.com; Kristján Valur Jónsson; Richard Tew; lars van
> Gemerden
> Subject: PySide problem, take #2: typeobject clash
> 
> Hi again,
> 
> after some more investigation, I think I found it.
> See thread [PySide violates Python API - PyQt does not!] The first message
> was not correct, but the second one very likely is.
> 
> As said there, the PyHeapTypeObject is extended like so:
> 
> > /// PyTypeObject extended with C++ multiple inheritance information.
> > struct LIBSHIBOKEN_API SbkObjectType
> > {
> >     PyHeapTypeObject super;
> >     SbkObjectTypePrivate* d;
> > };
> 
> This additional pointer gets aliased to the first 4 bytes (win 32 bit) of
> 
> typedef struct _slp_methodflags {
>      signed char tp_itemsize;
>      signed char tp_weaklistoffset;
>      signed char tp_dictoffset;
>      signed char nb_add;
>      signed char nb_subtract;
>      signed char nb_multiply;
>      signed char nb_divide;
>      signed char nb_remainder;
> ...
> 
> 
> The first three seem irrelevant. But the nb_add might influence the way how
> __add__ is interpreted. Due to the pointer value, stackless tries to call
> __add__ using the soft-switching protocol, which then fails miserably.
> 
> The macro that tries this is:
> 
> #define STACKLESS_PROMOTE_METHOD(obj, meth) \
>      (obj->ob_type->tp_flags & Py_TPFLAGS_HAVE_STACKLESS_EXTENSION ?
> \
>      slp_try_stackless = stackless & obj->ob_type->slpflags.meth : 0)
> 
> and it is used by
> 
> #define STACKLESS_PROPOSE_METHOD(obj, meth)                         \
> {                                                               \
>      int stackless = STACKLESS_POSSIBLE();                       \
>      STACKLESS_PROMOTE_METHOD(obj, meth);                        \
>      }
> 
> Unfortunately, I could not find out if there is a way for Stackless to fall into
> this trap. But a good thing would be a little test:
> 
> Lars, Richard:
> Can you please try your crashing examples, by putting
> > import stackless
> > stackless.enable_softswitch(False)
> 
> right after the program start?
> 
> That makes sure that stackless support of the interpreter is completely
> disabled, so the misinterpreted frags are of no influence.
> 
> If that leads to significantly less crashes, then there is a quick fix for PySide:
> Insert a dummy void* into object.h before slpflags:
> 
> >     PyObject *ht_name, *ht_slots;
> >     slp_methodflags slpflags;
> > #endif
> > } PyTypeObject;
> 
> Hope this helps, but I'm not confident -- Chris
> 
> --
> Christian Tismer             :^)   <mailto:tismer at stackless.com>
> Software Consulting          :     Have a break! Take a ride on Python's
> Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
> 14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
> PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
>        whom do you want to sponsor today?   http://www.stackless.com/
>