[PySide] RuntimeError: Failed to connect signal xxxx
Joel B. Mohler
jmohler at gamry.com
Mon Feb 25 18:10:30 CET 2013
On 2/23/2013 4:50 AM, Stefan Champailler wrote:
> I have never seen that kind of issue but what I've learned the hard
> way is that memory leaks can cause very erratic behaviours.
> So, as a first step, if you didn't already do so, you should make
> sure there are no ownership issues in your code. If you have a large
> code base, I found it was easier to simply remove the code part
> by part until the problem disappear (and so had I a better idea of
> the location of the issue).
> I also found very instructing to reduce the code to a small piece
> to reproduce the bug. Doing so help to learn quite a bit about PySide
> (because when you reduce code to a minimum you get to know how to
> express some ideas in a much better way).
> Either way, I bet you have some work ahead...
> On 02/21/2013 10:22 PM, Joel B. Mohler wrote:
>> On 2/21/2013 12:52 PM, Zak wrote:
>>> The following idea helped me with a different glitch that was
>>> probably unrelated to yours, but who knows, it might help you. Try
>>> each of the following:
>>> # Signals and slots example
>>> # From qt_webview_play.py
>>> @Slot(bool) # bool is PySide.QtCore.bool
>>> def my_slot(input_bool):
>>> # The following three lines should be equivalent, but they
>>> # are not always equivalent in practice:
>>> q_widget.connect(q_widget, SIGNAL("toggled(bool)"), my_slot)
>>> I don't know why they are different, but sometimes they are. My bug
>>> arose when I tried to manually disconnect and reconnect signals,
>>> specifically the loadFinished(bool) signal on a QWebView widget.
>>> In my own experience, it is best to always use the first method,
>>> with SIGNAL("toggled(bool)"). I notice that the StackOverflow
>>> question you linked uses the third method. Try switching it up and
>>> see if anything helps.
>> Thanks for your comments. I think they were helpful, but the bug
>> reproduction process here got pretty weird as I fiddle with this some
>> more. I commonly use method 2 to connect signals and slots (I wasn't
>> aware of method 3, but I think I see it's necessity at times). I
>> changed the one connection to use method 1 and sure enough I think I
>> don't get that failure any more.
>> (and now just a personal tale of woe this has led me down ...)
>> However, I now see that regardless of signal/slot issues, that if I
>> sit here and open,close,reopen and repeat continuously I'm sure to
>> get signal/slot failures and missing attributes and even segfault
>> crashes sometime in the first 30 open/close iterations.
>> Unfortunately, this widget that I'm closing and reopening has nested
>> sub-widgets probably 4 layers deep and many many nuances. It will
>> take a while to decode this, but it certainly looks like memory
>> corruption. I'm not going to hazard a guess about where to point a
>> finger at this point aside to say that pure python pyside shouldn't
For the public record in this thread and to indeed confirm Stefan's very
accurate statements, I report that the signal/slot issues entirely
resolved on their own once I understood the bug which I described at
https://bugreports.qt-project.org/browse/PYSIDE-144 . The workaround
there was to explicitly create my own QMdiSubWindow explicitly and set
my widget with QMdiSubWindow.setWidget. I find this to be an entirely
acceptable state of the code for my usage. The moral of the story is
that incorrect ownership (somewhere) can indeed cause seemingly
arbitrary faults later in the PySide-based application.
Stefan's approach of eliminating code piece by piece is virtually the
only way that I've been able to come to grips with this and prior PySide
experiences of this nature. This is grotesque, but quick python debug
cycles and revision control to know all your slicing & dicing changes
make it quite doable.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PySide