Problem
When lsp-bridge-enable-debug is t on macOS, GDB cannot start the lsp-bridge process at all:
"/Users/<user>/.bin/python-lsp-bridge": not in executable format: file format not recognized
Don't know how to run. Try "help target".
No stack.
Process *lsp-bridge* exited abnormally with code 1
Root Cause
Two compounding issues:
1. GDB on macOS requires codesigning + entitlements
GDB cannot start any process on macOS without proper codesigning and entitlements. This affects all executables — not just scripts:
$ gdb -batch -ex run -ex bt --args /tmp/hello # compiled C binary
Don't know how to run. Try "help target".
No stack.
This is documented in GCC GNAT Guide — Codesigning the Debugger. Most macOS users will not have GDB codesigned, making lsp-bridge-enable-debug effectively unusable out of the box.
2. Debugging through python-lsp-bridge wrapper script gives low-value traces
python-lsp-bridge is a bash wrapper:
#!/usr/bin/env bash
SCRIPT_PATH=$(realpath "$0")
SCRIPT_DIR_PATH=$(dirname "$SCRIPT_PATH")
exec uv --directory="$SCRIPT_DIR_PATH" run python "$@"
Even with a properly codesigned GDB, debugging through this script would trace the bash/uv process rather than the actual Python interpreter, yielding unhelpful backtraces for diagnosing lsp-bridge crashes.
Reproduce
- macOS (tested on Darwin 24.6.0, arm64)
- GDB installed via Homebrew (unsigned, default state)
(setq lsp-bridge-enable-debug t)
M-x lsp-bridge-restart-process
*lsp-bridge* buffer shows the error above, LSP never starts
Suggested Fix
Enable Python's built-in faulthandler in lsp_bridge.py as a cross-platform, zero-dependency alternative:
import faulthandler
faulthandler.enable()
This prints native Python tracebacks on segfault without requiring any external debugger, works on all platforms, and is compatible with both script wrappers and direct Python invocation.
Environment
- macOS Darwin 24.6.0 (arm64)
- GDB 17.1 (via Homebrew, unsigned)
- lsp-bridge commit:
c0b2140
python-lsp-bridge via uv
Problem
When
lsp-bridge-enable-debugiston macOS, GDB cannot start the lsp-bridge process at all:Root Cause
Two compounding issues:
1. GDB on macOS requires codesigning + entitlements
GDB cannot start any process on macOS without proper codesigning and entitlements. This affects all executables — not just scripts:
This is documented in GCC GNAT Guide — Codesigning the Debugger. Most macOS users will not have GDB codesigned, making
lsp-bridge-enable-debugeffectively unusable out of the box.2. Debugging through
python-lsp-bridgewrapper script gives low-value tracespython-lsp-bridgeis a bash wrapper:Even with a properly codesigned GDB, debugging through this script would trace the bash/uv process rather than the actual Python interpreter, yielding unhelpful backtraces for diagnosing lsp-bridge crashes.
Reproduce
(setq lsp-bridge-enable-debug t)M-x lsp-bridge-restart-process*lsp-bridge*buffer shows the error above, LSP never startsSuggested Fix
Enable Python's built-in
faulthandlerinlsp_bridge.pyas a cross-platform, zero-dependency alternative:This prints native Python tracebacks on segfault without requiring any external debugger, works on all platforms, and is compatible with both script wrappers and direct Python invocation.
Environment
c0b2140python-lsp-bridgeviauv