New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Destroying the default loop in corecext causes the interpreter to crash #1098

Closed
jamadden opened this Issue Feb 13, 2018 · 1 comment

Comments

Projects
None yet
1 participant
@jamadden
Member

jamadden commented Feb 13, 2018

  • gevent version: master
  • Python version: Seen in CPython 3.4, 3.5 and sometimes 3.6 and 3.7
  • Operating System: Seen on Linux, OS X, and Appveyor
>>> import gevent
>>> gevent.get_hub()
<Hub at 0x10cb74768 select default pending=0 ref=0>
>>> loop = gevent.config.loop(default=True)
>>> loop.destroy()
None
>>> del loop
>>> ^D
Segmentation fault: 11

I've seen this backtrace from that example:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   corecext.cpython-35m-darwin.so	0x000000010cba05e0 __pyx_pw_6gevent_5libev_8corecext_4loop_5_stop_watchers + 112
1   corecext.cpython-35m-darwin.so	0x000000010cb92ba5 __Pyx_PyObject_CallMethO + 85
2   greenlet.cpython-35m-darwin.so	0x000000010cbeb123 green_dealloc + 691
3   org.python.python             	0x000000010ae21ee4 subtype_dealloc + 849
4   org.python.python             	0x000000010ae0aff2 free_keys_object + 67
5   org.python.python             	0x000000010ae0ca15 dict_dealloc + 183
6   org.python.python             	0x000000010ae0aff2 free_keys_object + 67
7   org.python.python             	0x000000010ae0ca15 dict_dealloc + 183
8   org.python.python             	0x000000010aea70d8 local_clear + 97
9   org.python.python             	0x000000010aea6edf local_dealloc + 40
10  org.python.python             	0x000000010ae21ee4 subtype_dealloc + 849
11  org.python.python             	0x000000010ae0aff2 free_keys_object + 67
12  org.python.python             	0x000000010ae0ce17 dict_tp_clear + 9
13  org.python.python             	0x000000010aea5e0c collect + 1824
14  org.python.python             	0x000000010aea56e3 _PyGC_CollectNoFail + 43
15  org.python.python             	0x000000010ae861d4 PyImport_Cleanup + 968
16  org.python.python             	0x000000010ae8fb49 Py_Finalize + 92
17  org.python.python             	0x000000010aea4d2f Py_Main + 2615

I've also seen this backtrace from a test script:

 0   libsystem_kernel.dylib        	0x00007fff66455e3e __pthread_kill + 10
 1   libsystem_pthread.dylib       	0x00007fff66594150 pthread_kill + 333
 2   libsystem_c.dylib             	0x00007fff663648fe raise + 26
 3   libsystem_platform.dylib      	0x00007fff66587f5a _sigtramp + 26
 4   ???                           	000000000000000000 0 + 0
 5   greenlet.cpython-35m-darwin.so	0x000000010d76b297 green_clear + 183
 6   org.python.python             	0x000000010c707e0c collect + 1824
 7   org.python.python             	0x000000010c7076e3 _PyGC_CollectNoFail + 43
 8   org.python.python             	0x000000010c6e81d4 PyImport_Cleanup + 968
 9   org.python.python             	0x000000010c6f1b49 Py_Finalize + 92
 10  org.python.python             	0x000000010c6f20d5 Py_Exit + 13
 11  org.python.python             	0x000000010c6f4631 handle_system_exit + 320
 12  org.python.python             	0x000000010c6f42a1 PyErr_PrintEx + 42

We should try to do better than crash.

@jamadden

This comment has been minimized.

Member

jamadden commented Feb 14, 2018

This can also happen in the CFFI implementations, you just have to work at it because they don't have a __del__ that attempts to destroy the loop. This will crash the process (segfault with libev, abort() with libuv):

loop1 = gevent.config.loop(default=True)
loop2 = gevent.config.loop(default=True)
loop1.destroy()
loop2.destroy() # bang!

jamadden added a commit that referenced this issue Feb 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment