Crash-on-exit after call to app.processEvents()

[Raymond Osborn]

Armando,
I’m writing again because I’ve learned a couple of useful things that might be worth sharing. I had a scare when the problem started occurring again for no apparent reason, using the same sequence I had tested before. I decided to look more closely in the debugger and discovered that the exit process never fully completed if one of the windows that had been resized following a  processEvents() call was still open. Somewhere between the ‘event.accept()’ call in the main window’s closeEvent function and completing the app._exec() call, it just quit, sometimes with a segfault, sometimes without. 

The offending windows had all been opened with the main window as parent, but when I made them top-level windows, the exit process completed successfully. I had tried that already before contacting the mailing list. I think the combination of opening the offending windows without a parent and then closing all top-level widgets, as you suggested, may have finally fixed the problem. 

Not sure if that’s the final word though.

Thanks again,
Ray

> On May 25, 2020, at 5:42 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
> 
> This is reminding me of the issues Armando raised with Matplotlib (https://github.com/matplotlib/matplotlib/issues/14178 <https://github.com/matplotlib/matplotlib/issues/14178> / https://github.com/matplotlib/matplotlib/pull/14179 <https://github.com/matplotlib/matplotlib/pull/14179>).  I now understand why Matplotlib (and IPython) holding references to the qApp can be problematic (as in this case del ing app just drops your reference to it but does not actually trigger the `__delete__` code because other parts of the codebase are keeping it alive) if having a "live" app on process shut down can cause problems.
> 
> My naive guess as to why calling `ProcessEvents` triggers the issue as that it creates some extra state on at least the c++ side and we end up tearing down the objects on the Python side in a different order than we need to on the c++ side.  Oventually something winds up with a null pointer (because there was a reference at the c++ level but not at the Python level) and boom.  I stress that while that is where I would start looking to track this down it is still very much a guess.
> 
> Tom
> 
> On Mon, May 25, 2020 at 5:36 PM Raymond Osborn <rayosborn at mac.com <mailto:rayosborn at mac.com>> wrote:
> Hi Armando,
> Good to hear from you. I thought for a while that I had managed to fix it with the following code :
> 
>     def main(filename=None):
>         app = NXConsoleApp()
>         app.initialize(filename=filename)
>         app.start()
>         for w in QApplication.topLevelWindows():
>             del w
>         del app.window, app.app
>         sys.exit(0)
> 
> It proved to be a false dawn - the problem started to recur again. I’ll see if your version catches things that mine missed, and let you know.
> 
> I have spent a lot of time trying to cover up PyQt5 bugs in the past year. The problem is that I can’t guarantee that my users will have the latest version of PyQt, so even if it is fixed in v5.14, I still have to patch the code. I just have no idea why simply calling processEvents() triggers the bug. If I knew that, perhaps it would give some clue how to work around it.
> 
> Ray
> 
> 
>> On May 25, 2020, at 3:38 PM, V. Armando Sole <sole at esrf.fr <mailto:sole at esrf.fr>> wrote:
>> 
>> Hi Ray,
>> 
>> I do not know if it will help your case. I was getting rid of some crashes on exit by deleting all widgets that had no parent. For instance, when closing the QMainWindow by doing:
>> 
>>     def closeEvent(self, event):
>>         if __name__ == "__main__":
>>             app = qt.QApplication.instance()
>>             allWidgets = app.allWidgets()
>>             for widget in allWidgets:
>>                 try:
>>                     # we cannot afford to crash here
>>                     if id(widget) != id(self):
>>                         if widget.parent() is None:
>>                             widget.close()
>>                 except:
>>                     _logger.debug("Error closing widget")
>>         return qt.QMainWindow.closeEvent(self, event)
>> 
>> Best regards,
>> 
>> Armando
>> 
>> On 25.05.2020 19:48, Raymond Osborn wrote:
>> 
>>> I added a call to QtWidgets.QApplication.instance().processEvents() in order to force adjustResize() to work when switching tabs (that's another story). It succeeded in fixing my resize issue, but now it triggers a segfault when I exit the application. This seemed to be related to the bug described in https://www.riverbankcomputing.com/static/Docs/PyQt5/gotchas.html#crashes-on-exit <https://www.riverbankcomputing.com/static/Docs/PyQt5/gotchas.html#crashes-on-exit>. One fix, suggested by @ekhumoro on stackoverflow (https://stackoverflow.com/questions/59120337/why-does-pyqt-sometimes-crash-on-exit <https://stackoverflow.com/questions/59120337/why-does-pyqt-sometimes-crash-on-exit>) was to delete the main window and the app first, but that doesn't seem to fix it. I am running PyQt 5.12 because that is the last version supported by conda, so I can't test the one-exit fix in v5.13, and my users probably wouldn't have it installed anyway. It happens on Macs and linux.
>>>  
>>> What I am asking is if there are additional things to try in addition to @ekhumoro's suggestion? Basically he suggests doing something like:
>>>  
>>> def main():
>>>     app = QApplication(sys.argv)
>>>     main_window = MainWindow()
>>>     main_window.show()
>>>     app.exec_()
>>>     # ensure correct deletion order
>>>     del main_window, app
>>> Does anyone understand why the crash only occurs if I have calls to processEvents() in the code? It never happens when I remove them.
>>>  
>>> Thanks,
>>> Ray
>>>  
>>>  
> 
> 
> 
> -- 
> Thomas Caswell
> tcaswell at gmail.com <mailto:tcaswell at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20200525/2562ce9e/attachment-0001.htm>