[prev in list] [next in list] [prev in thread] [next in thread]
List: pykde
Subject: Re: [PyQt] [SIP] Critical issue since version 4.18
From: Antoine Lambert <antoine.lambert33 () gmail ! com>
Date: 2016-11-14 20:01:28
Message-ID: CAJ0x15NZ3NmtxWbxhb2jSy43=tyuOLbADBAt8CqzFhFi3mnbWg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I have just tested the latest snapshot (sip-4.19.dev1611111241
<https://www.riverbankcomputing.com/static/Downloads/sip/sip-4.19.dev1611111241.zip>)
and the two bugs I have reported are still present.
2016-11-14 19:57 GMT+01:00 Phil Thompson <phil@riverbankcomputing.com>:
> On 14 Nov 2016, at 6:36 pm, Antoine Lambert <antoine.lambert33@gmail.com>
> wrote:
> >
> > Hi,
> >
> > I am the maintainer of the Python bindings for the Tulip framework : an
> open source graph visualization tool. I have recently upgraded to SIP
> 4.18.1 and one critical issue appears in our generated bindings leading to
> a segfault.
> >
> > The bug is the following. We use SIP in order to implement plugins in
> Python for the Tulip framework. Implementing a plugin consists in writing a
> Python class that derives from a Tulip wrapped plugin interface (see
> http://pythonhosted.org/tulip-python/pythonplugins.html). For instance
> to write a general graph algorithm plugin, one has to write a class that
> derives from the 'tlp.Algorithm' Tulip Python class.
> > The 'tlp.Algorithm' class wraps the 'tlp::Algorithm" C++ class (
> https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/Algorithm.sip). The
> "tlp::Algorithm" class derives from the "tlp::Plugin" class (
> https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/Plugin.sip), itself deriving
> from "tlp::WithParameter" and "tlp::WithDependency" (
> https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/WithParameter.sip,
> https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/WithDependency.sip). The issue
> is that now every call to a method from the "tlp.WithParameter" class
> inside a Tulip plugin source code leads to a segfault during the plugin
> execution.
> > I managed to get back to the SIP revision that introduces the regression
> through a session of "hg bisect" : this is revision 1425 (https://www.
> riverbankcomputing.com/hg/sip/rev/14bfbaf7431a). It seems that some
> needed class cast functions are no more generated since that revision which
> then leads to segfault due to incorrect pointer cast (just my guess).
> > As a temporary workaround, i naively patch the SIP source code bundled
> in the Tulip source tree forcing the generation of these cast functions (
> https://sourceforge.net/p/auber/code/11726/).
> >
> > I also found another issue that is not critical but still problematic.
> When wrapping non const global C++ variables, setting their value in Python
> does not modify the content of the wrapped variables. For instance, in the
> Tulip Python bindings, we wrapped some global variables holding some file
> system paths (e.g. "tlp.TulipBitmapDir", https://sourceforge.net/p/
> auber/code/HEAD/tree/tulip/library/tulip-python/bindings/
> tulip-core/TlpTools.sip).
> > Even if it seems that when modifying the variable content it is taken
> into account (in particular when printing it), the content of the wrapped
> variable is not changed.
> > I assumed there is some kind of cache for wrapped const global variables
> but it should not be used for non const ones.
> > That issue was already present in SIP 4.17, I should have report it
> earlier but its was not critical and I managed to workaround it using a
> Python meta-class (https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/__init__.py).
> >
> > Hope that this report will help to fix those annoying issues for the
> next SIP version.
>
> Have you tried the current snapshot?
>
> Phil
[Attachment #5 (text/html)]
<div dir="ltr"><div>I have just tested the latest snapshot (<a \
href="https://www.riverbankcomputing.com/static/Downloads/sip/sip-4.19.dev1611111241.zip">sip-4.19.dev1611111241</a>) \
and the two bugs I have reported are still present.<br><br></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">2016-11-14 19:57 GMT+01:00 Phil \
Thompson <span dir="ltr"><<a href="mailto:phil@riverbankcomputing.com" \
target="_blank">phil@riverbankcomputing.com</a>></span>:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On 14 Nov 2016, at 6:36 pm, Antoine Lambert \
<<a href="mailto:antoine.lambert33@gmail.com">antoine.lambert33@gmail.com</a>> \
wrote:<br> ><br>
> Hi,<br>
><br>
> I am the maintainer of the Python bindings for the Tulip framework : an open \
source graph visualization tool. I have recently upgraded to SIP 4.18.1 and one \
critical issue appears in our generated bindings leading to a segfault.<br> ><br>
> The bug is the following. We use SIP in order to implement plugins in Python for \
the Tulip framework. Implementing a plugin consists in writing a Python class that \
derives from a Tulip wrapped plugin interface (see <a \
href="http://pythonhosted.org/tulip-python/pythonplugins.html" rel="noreferrer" \
target="_blank">http://pythonhosted.org/tulip-<wbr>python/pythonplugins.html</a>). \
For instance to write a general graph algorithm plugin, one has to write a class that \
derives from the 'tlp.Algorithm' Tulip Python class.<br> > The \
'tlp.Algorithm' class wraps the 'tlp::Algorithm" C++ class (<a \
href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/Algorithm.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/Algorithm.sip</a>). \
The "tlp::Algorithm" class derives from the "tlp::Plugin" class \
(<a href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/Plugin.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/Plugin.sip</a>), \
itself deriving from "tlp::WithParameter" and \
"tlp::WithDependency" (<a \
href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/WithParameter.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/WithParameter.sip</a>, \
<a href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/WithDependency.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/t \
ulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/WithDependency.sip</a>)<wbr>. \
The issue is that now every call to a method from the "tlp.WithParameter" \
class inside a Tulip plugin source code leads to a segfault during the plugin \
execution.<br> > I managed to get back to the SIP revision that introduces the \
regression through a session of "hg bisect" : this is revision 1425 (<a \
href="https://www.riverbankcomputing.com/hg/sip/rev/14bfbaf7431a" rel="noreferrer" \
target="_blank">https://www.<wbr>riverbankcomputing.com/hg/sip/<wbr>rev/14bfbaf7431a</a>). \
It seems that some needed class cast functions are no more generated since that \
revision which then leads to segfault due to incorrect pointer cast (just my \
guess).<br> > As a temporary workaround, i naively patch the SIP source code \
bundled in the Tulip source tree forcing the generation of these cast functions (<a \
href="https://sourceforge.net/p/auber/code/11726/" rel="noreferrer" \
target="_blank">https://sourceforge.net/p/<wbr>auber/code/11726/</a>).<br> ><br>
> I also found another issue that is not critical but still problematic. When \
wrapping non const global C++ variables, setting their value in Python does not \
modify the content of the wrapped variables. For instance, in the Tulip Python \
bindings, we wrapped some global variables holding some file system paths (e.g. \
"tlp.TulipBitmapDir", <a \
href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/TlpTools.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/TlpTools.sip</a>).<br>
> Even if it seems that when modifying the variable content it is taken into \
account (in particular when printing it), the content of the wrapped variable is not \
changed.<br> > I assumed there is some kind of cache for wrapped const global \
variables but it should not be used for non const ones.<br> > That issue was \
already present in SIP 4.17, I should have report it earlier but its was not critical \
and I managed to workaround it using a Python meta-class (<a \
href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/__init__.py" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/__init__.py</a>).<br>
><br>
> Hope that this report will help to fix those annoying issues for the next SIP \
version.<br> <br>
</span>Have you tried the current snapshot?<br>
<span class="HOEnZb"><font color="#888888"><br>
Phil</font></span></blockquote></div><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic