Spyder crashes at shutdown #2

[impact27]

Issue Report Checklist

• Searched the issues page for similar reports
• Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
• Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
• Could not reproduce inside jupyter qtconsole (if console-related)
• Tried basic troubleshooting (if a bug/error)
  • Restarted Spyder
  • Reset preferences with spyder --reset
  • Reinstalled the latest version of Anaconda
  • Tried the other applicable steps from the Troubleshooting Guide
• Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description

Different issue from #20561
e.g. on the master mac tests:
https://github.com/spyder-ide/spyder/actions/runs/4205227388/jobs/7297000397

you find:

Fatal Python error: Bus error

Current thread 0x000000010df61600 (most recent call first):
<no Python frame>
.github/scripts/run_tests.sh: line 15:  7088 Bus error: 10           python runtests.py --color=yes
      7089 Done                    | tee -a pytest_log.txt

It may be mac only?

On my mac, running a random test:

Fatal Python error: Bus error

Current thread 0x000000020ac9fa80 (most recent call first):
  <no Python frame>

the trace is:

Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x1af9021b0 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x1af938cec pthread_kill + 288
2   libsystem_c.dylib             	       0x1af83aa50 raise + 32
3   libsystem_platform.dylib      	       0x1af9672a4 _sigtramp + 56
4   QtCore.abi3.so                	       0x10526541c cleanup_qobject(_sipSimpleWrapper*, void*) + 44
5   sip.cpython-310-darwin.so     	       0x104f56d2c sip_api_visit_wrappers + 100
6   QtCore.abi3.so                	       0x105265298 cleanup_on_exit(_object*, _object*) + 16
7   Python                        	       0x102e5efb0 cfunction_vectorcall_NOARGS + 96
8   Python                        	       0x102fbcf84 atexit_callfuncs + 120
9   Python                        	       0x102f4d09c Py_FinalizeEx + 88
10  Python                        	       0x102f4f090 Py_Exit + 20
11  Python                        	       0x102f539ec handle_system_exit + 44
12  Python                        	       0x102f51f04 _PyErr_PrintEx + 56
13  Python                        	       0x102f52980 _PyRun_SimpleFileObject + 524
14  Python                        	       0x102f51ec4 _PyRun_AnyFileObject + 232
15  Python                        	       0x102f74f14 pymain_run_file_obj + 220
16  Python                        	       0x102f74664 pymain_run_file + 72
17  Python                        	       0x102f73ef4 Py_RunMain + 872
18  Python                        	       0x102f752f0 Py_BytesMain + 40
19  dyld                          	       0x1af60fe50 start + 2544

What steps reproduce the problem?

open and close spyder or run a random test that open spyder:
pytest spyder/app/tests/test_mainwindow.py::test_window_title

What is the expected output? What do you see instead?

Paste Traceback/Error Below (if applicable)

PASTE TRACEBACK HERE

Versions

Python 3.10.8 64-bit | Qt 5.15.5 | PyQt5 5.15.7 | Darwin 22.2.0

• Spyder version:
• Python version:
• Qt version:
• PyQt version:
• Operating System name/version:

Dependencies

PASTE DEPENDENCIES HERE

[impact27]

https://www.riverbankcomputing.com/static/Docs/PyQt5/gotchas.html#crashes-on-exit

Might be difficult to debug :/

[ccordoba12]

I can confirm this problem on Linux too, even after the fix you proposed for the other crash on PR #20562. However, that seems to be a problem only when running our tests because:

1. When Spyder is opened as a regular app and then closed, I see no segfault in the console.

2. If I add window.close() to line 460 below, and then run any main window test, I get no segfault either.

   spyder/spyder/app/tests/conftest.py

   Lines 455 to 468 in fd12df1

   	else:
   	# Try to close used mainwindow directly on fixture
   	# after running test that uses the fixture
   	# Currently 'test_out_runfile_runcell' is the last tests so
   	# in order to prevent errors finalizing the test suit such test has
   	# this marker
   	close_main_window = request.node.get_closest_marker(
   	'close_main_window')
   	if close_main_window:
   	main_window.window = None
   	window.close()
   	window = None
   	CONF.reset_to_defaults(notification=False)
   	else:

So, I guess the window.close() call correctly cleans up some Qt objects that otherwise are not.

A simple solution for this on CIs would be to automatically add the close_main_window marker to the last test on test_mainwindow.py.

[jitseniesen]

I get a similar crash in my spyder-unittest CI runs, after pytest reports that all tests have succeeded. In my tests I do window.close() in every test. For me, the crash only happens on CI runs, not when I run the tests locally. The crash is not totally reproducible but happens almost always under Ubuntu with Python 3.9 - however, only when running the entire test suite, not when running individual tests. The crash happens far less often with other combinations of OS and Python version. It is frustrating.

Anyway, here is the gdb backtrace of the crashing thread (there are 50 threads in total):

#0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=139821441042240) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=11, threadid=139821441042240) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=139821441042240, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
#3  0x00007f2ab7579476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
#4  <signal handler called>
#5  0x00007f2ab718afc0 in ?? ()
#6  0x00007f2ab612fec1 in cleanup_qobject(_sipSimpleWrapper*, void*) () from /usr/share/miniconda3/envs/test/lib/python3.10/site-packages/PyQt5/QtCore.abi3.so
#7  0x00007f2ab30bed28 in sip_api_visit_wrappers () from /usr/share/miniconda3/envs/test/lib/python3.10/site-packages/PyQt5/sip.cpython-310-x86_64-linux-gnu.so
#8  0x00007f2ab612fbdc in cleanup_on_exit(_object*, _object*) () from /usr/share/miniconda3/envs/test/lib/python3.10/site-packages/PyQt5/QtCore.abi3.so
#9  0x0000561860e1d395 in cfunction_vectorcall_NOARGS (func=0x7f2ab6486f20, args=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at /usr/local/src/conda/python-3.10.11/Objects/methodobject.c:489
#10 0x0000561860ee8bdc in atexit_callfuncs (state=0x5618610911d0) at /usr/local/src/conda/python-3.10.11/Modules/atexitmodule.c:98
#11 0x0000561860ee85cd in _PyAtExit_Call (interp=<optimized out>) at /usr/local/src/conda/python-3.10.11/Modules/atexitmodule.c:118
#12 Py_FinalizeEx () at /usr/local/src/conda/python-3.10.11/Python/pylifecycle.c:1734
#13 0x0000561860edac2b in Py_RunMain () at /usr/local/src/conda/python-3.10.11/Modules/main.c:672
#14 0x0000561860ea9e09 in Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at /usr/local/src/conda/python-3.10.11/Modules/main.c:1090
#15 0x00007f2ab7560d90 in __libc_start_call_main (main=main@entry=0x561860ea9dc0 <main>, argc=argc@entry=7, argv=argv@entry=0x7ffcb5437118) at ../sysdeps/nptl/libc_start_call_main.h:58
#16 0x00007f2ab7560e40 in __libc_start_main_impl (main=0x561860ea9dc0 <main>, argc=7, argv=0x7ffcb5437118, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcb5437108) at ../csu/libc-start.c:392
#17 0x0000561860ea9d01 in _start ()

[ccordoba12]

Pinging @dalthviz about it because he could have a better idea of what's happening here.

[dalthviz]

Not sure what could be happening here :/ maybe some sort of race condition when cleaning/closing widgets? Maybe some widget is instanced without setting a parent and it's accessed in a way that causes a segfault when the window close method is called due to it being already invalid when the close method is called?

[jitseniesen]

That sounds very difficult to debug. In the mean time, I found out that the crashes become less frequent if I don't produce a coverage report. Since I don't understand the information on the codecov website (the coverage goes up and down without any reason that I can see), this is an acceptable work-around for me.