Describe the bug
Reqable crashes on macOS with a null pointer dereference (EXC_BAD_ACCESS / SIGSEGV at address 0x18) inside libreqable_netbare.dylib, in the function netbareReplyWebSocketInterceptPass. The crash occurs on the io.flutter.ui thread, triggered from a Dart microtask. The native function appears to dereference a null (or already-invalidated) session/context pointer at offset +0x18.
To Reproduce
No explicit interaction was needed — the app was simply left running in the background for an extended period (idle, running as a background process) and crashed on its own. Based on the crash symbol (netbareReplyWebSocketInterceptPass), it seems related to a WebSocket intercept/reply session that may have gone stale while idle, but no manual reply/injection action was performed at the time of the crash.
Steps as experienced:
- Launch Reqable, leave it running in the background
- Leave it open/idle for a long period (~hours)
- App crashes spontaneously, no user interaction at the time
Expected behavior
Reqable should not crash spontaneously after being left open for a long time. If a WebSocket intercept session becomes stale/invalid while idle, the native layer should null-check the session/context before use instead of crashing.
Screenshots
N/A (crash report attached/pasted separately)
Information
- Platform: macOS
- OS: 26.5.2 (build 25F84)
- Arch: arm64 (Apple M2 Pro, Mac14,10)
- App Version: 3.2.16 (build 214)
req.log
Describe the bug
Reqable crashes on macOS with a null pointer dereference (
EXC_BAD_ACCESS/SIGSEGVat address0x18) insidelibreqable_netbare.dylib, in the functionnetbareReplyWebSocketInterceptPass. The crash occurs on theio.flutter.uithread, triggered from a Dart microtask. The native function appears to dereference a null (or already-invalidated) session/context pointer at offset+0x18.To Reproduce
No explicit interaction was needed — the app was simply left running in the background for an extended period (idle, running as a background process) and crashed on its own. Based on the crash symbol (
netbareReplyWebSocketInterceptPass), it seems related to a WebSocket intercept/reply session that may have gone stale while idle, but no manual reply/injection action was performed at the time of the crash.Steps as experienced:
Expected behavior
Reqable should not crash spontaneously after being left open for a long time. If a WebSocket intercept session becomes stale/invalid while idle, the native layer should null-check the session/context before use instead of crashing.
Screenshots
N/A (crash report attached/pasted separately)
Information
req.log