Crash on mac after timeout connecting to device

• bleak version: 0.11
• Python version: 3.8.5
• Operating System: MacOS 11.3.1
• BlueZ version (bluetoothctl -v) in case of Linux:

Description

Sometimes (not always) when I get a timeout connecting to a device I get an asyncio.exceptions.TimeoutError exception. Subsequently the program crashes.

Even if I catch the exception the Python program will still crash on exit.

Here are the relevant bits of the crash report:

Crashed Thread:        5  Dispatch queue: bleak.corebluetooth

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [20790]

Application Specific Information:
BUG IN CLIENT OF LIBPTHREAD: pthread_exit() called from a thread not created by pthread_create()

Thread 0:: Dispatch queue: com.apple.main-thread
0   org.python.python             	0x00000001031f7a64 PyTuple_ClearFreeList + 84
1   org.python.python             	0x00000001032dc4ce collect + 3454
2   org.python.python             	0x00000001032db737 _PyGC_CollectNoFail + 55
3   org.python.python             	0x00000001032a2db1 PyImport_Cleanup + 1521
4   org.python.python             	0x00000001032b8f98 Py_FinalizeEx + 152
5   org.python.python             	0x00000001032da8db Py_RunMain + 1659
6   org.python.python             	0x00000001032dae3f pymain_main + 223
7   org.python.python             	0x00000001032db03b Py_BytesMain + 43
8   libdyld.dylib                 	0x00007fff20619f3d start + 1

Thread 5 Crashed:: Dispatch queue: bleak.corebluetooth
0   libsystem_pthread.dylib       	0x00007fff205fc7cd pthread_exit + 56
1   org.python.python             	0x00000001032ca905 PyThread_exit_thread + 21
2   org.python.python             	0x000000010326dd90 PyEval_RestoreThread + 128
3   org.python.python             	0x00000001032bc68a PyGILState_Ensure + 122
4   _objc.cpython-38-darwin.so    	0x0000000103a5ff98 method_stub + 40
5   _objc.cpython-38-darwin.so    	0x0000000103a83294 ffi_closure_unix64_inner + 708
6   _objc.cpython-38-darwin.so    	0x0000000103a827b6 ffi_closure_unix64 + 70
7   com.apple.CoreBluetooth       	0x00007fff30b31822 -[CBCentralManager handlePeripheralDisconnectionCompleted:] + 223
8   com.apple.CoreBluetooth       	0x00007fff30b31822 -[CBCentralManager handlePeripheralDisconnectionCompleted:] + 223
9   com.apple.CoreBluetooth       	0x00007fff30b31822 -[CBCentralManager handlePeripheralDisconnectionCompleted:] + 223

that last one is repeated for the 512 stack frames dumped in the crash report.

What may be relevant is that I’m connecting to devices that are powered for only 200ms after sending an advertisement and then power down for 2 seconds (unless contacted by a client within those 200ms). If I understand the BLE specs correctly this is supported behaviour.

[dlech]

I was able to reproduce the issue by setting timeout=0.15 in BleakClient().

The problem is that when the Python runtime has exited we can still get delegate callbacks for the central manager or a peripheral. These are running on a thread created by libdispatch.dispatch_queue_create. The man page has this to say:

The dispatch framework manages the relationship between dispatch queues and threads of execution. As a result, applications MUST NOT delete or mutate objects that they did not create. The following interfaces MUST NOT be called by blocks submitted to a dispatch queue:

• pthread_cancel()
• pthread_detach()
• pthread_join()
• pthread_kill()
• pthread_exit()

However the callback from pyobjc is calling PyGILState_Ensure() which eventually calls take_gil() which is the source of the PyThread_exit_thread() calls that call the forbidden pthread_exit(). The code references a couple of bugs explaining why it does this.

We might be able to work around this in Bleak by disconnecting all delegates before the runtime exits. But it would be worthwhile reporting the bug to PyObjC and or CPython.

The docs also mention a dispatch_suspend function that could be called, perhaps with atexit to avoid the callback that causes the crash.

[dlech]

Sorry, my original remark sounded like criticism

No, not at all. 😄 I was just curious to hear a new/different perspective.