Title: [Own investigation] SIGSEGV in get_bwrap_bin() (use_bwrap.c) during cgid startup - OpenLiteSpeed 1.9.1 + lsphp83 8.3.33
Note: This is a self-diagnosed issue based on my own log analysis, A/B
comparison between two servers, and a GDB backtrace from a core dump on
my own infrastructure. I have not found any existing report matching
this specific crash (checked the forum and GitHub issues for
"get_bwrap_bin", "use_bwrap.c", and similar Bubblewrap+lsphp83 segfault
reports - nothing matched this exact stack). Posting in case this is a
new regression worth investigating, and happy to be corrected if this
turns out to be a known/duplicate issue.
ENVIRONMENT:
- Server: OpenLiteSpeed 1.9.1 Open (BUILD built: Sun Jul 12 18:16:07 UTC 2026)
- OS: Debian 13 (trixie)
- PHP: lsphp83 8.3.33-1+trixie
- Bubblewrap Container: Enabled (bubbleWrap 2 at vhost level, default
bwrap command line, not customized)
- Module versions: lsquic 4.8.2, modgzip 1.1, cache 1.66,
mod_security 1.4 (libmodsecurity v3.0.15)
- ~30 WordPress vhosts on one box
ISSUE:
After apt upgrade lsphp83 8.3.30 -> 8.3.33 (alongside openlitespeed 1.8.5 ->
1.9.1), the cgid worker process segfaults on startup/reconfig, and continues
to crash repeatedly (several times per minute under traffic that triggers
new cgid spawns), taking lsphp/LSAPI handling down with it.
stderr.log:
Cgid: Child process with pid: XXXXXXX was killed by signal: 11, core dump: 128
dmesg:
litespeed[PID]: segfault at 0 ip 0000000000000000 sp 00007ffdab8b7728 error 14
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
ISOLATION (my own testing):
1. A second, identically configured server running the same OpenLiteSpeed
1.9.1 build but with lsphp83 held at 8.3.32 shows ZERO crashes under
equivalent traffic and vhost config -- isolates the regression to
lsphp83 8.3.33 (or its interaction with Bubblewrap), not to OpenLiteSpeed
1.9.1 core by itself.
2. Disabling Bubblewrap Container at the server level immediately and
completely stopped the crashes (25+ minutes clean under load afterward,
vs. crashes every few seconds beforehand).
3. Confirmed ~27,000 core dumps had accumulated over ~30 hours before I
noticed and cleaned them up (unrelated disk-space side effect, but shows
the crash frequency under our traffic).
GDB BACKTRACE (openlitespeed-dbgsym 1.9.1-2+trixie installed, full symbols,
core taken from my own production server):
#0 0x0000000000000000 in ?? ()
#1 0x000000000056b12a in get_bwrap_bin ()
at src/extensions/cgi/use_bwrap.c:613
#2 get_bwrap_bin ()
at src/extensions/cgi/use_bwrap.c:603
#3 0x000000000056b967 in build_bwrap_exec (...)
at src/extensions/cgi/use_bwrap.c:635
#4 0x000000000056ba0c in exec_using_bwrap (...)
at src/extensions/cgi/use_bwrap.c:831
#5 0x000000000055626c in execute_cgi (...)
at src/extensions/cgi/lscgid.cpp:725
#6 0x0000000000557082 in processreq (...)
at src/extensions/cgi/lscgid.cpp:982
#7 child_main (...) at src/extensions/cgi/lscgid.cpp:1006
#8 new_conn (...) at src/extensions/cgi/lscgid.cpp:1018
#9 run (...) at src/extensions/cgi/lscgid.cpp:1137
#10 lscgid_main (...) at src/extensions/cgi/lscgid.cpp:1306
#11 CgidWorker::spawnCgid (...) at src/extensions/cgi/cgidworker.cpp:184
#12 CgidWorker::start (...) at src/extensions/cgi/cgidworker.cpp:145
#13 CgidWorker::start (...) at src/util/tsingleton.h:53
#14 CgidWorker::config (...) at src/extensions/cgi/cgidworker.cpp:399
#15 HttpServerImpl::configSecurity (...) at src/main/httpserver.cpp:3291
#16 HttpServerImpl::configServerBasic2 (...) at src/main/httpserver.cpp:3531
#17 HttpServerImpl::configServer (...) at src/main/httpserver.cpp:4778
#18 HttpServerImpl::initServer (...) at src/main/httpserver.cpp:5090
#19 HttpServer::initServer (...) at src/main/httpserver.cpp:6199
#20 LshttpdMain::config (...) at src/main/lshttpdmain.cpp:721
#21 LshttpdMain::init (...) at src/main/lshttpdmain.cpp:1027
#22 LshttpdMain::main (...) at src/main/lshttpdmain.cpp:1132
#23 main (...) at src/main.cpp:67
MY OWN NOTES / SPECULATION (not verified against source, just what the
trace suggests):
- Crash happens during server startup/config load path
(CgidWorker::config -> CgidWorker::start -> spawnCgid), i.e. cgid itself
crashes while being spawned/configured, not only during individual PHP
request handling. This would explain the flood of crashes seen
immediately after every service restart.
- get_bwrap_bin() at use_bwrap.c:613 appears twice in the stack (self-
recursive call from line 603) -- I'm guessing this means the function
recurses to try an alternate bwrap binary location/path, and that
recursive branch ends up calling through an uninitialized/NULL function
pointer, but I haven't looked at the actual source to confirm.
- Frame #3 (build_bwrap_exec) shows bwrap_cmdline = 0x0 and begin_param =
0x0 in the locals, which seems consistent with a failed/empty command-
line construction feeding into the crashing call, but again this is my
interpretation, not a confirmed root cause.
I'm not a LiteSpeed developer, so take the interpretation above with a grain
of salt -- the backtrace itself is the solid part. Happy to provide the raw
core file, additional traces from other crashed PIDs, run further tests, or
try a patched build if one becomes available.
Note: This is a self-diagnosed issue based on my own log analysis, A/B
comparison between two servers, and a GDB backtrace from a core dump on
my own infrastructure. I have not found any existing report matching
this specific crash (checked the forum and GitHub issues for
"get_bwrap_bin", "use_bwrap.c", and similar Bubblewrap+lsphp83 segfault
reports - nothing matched this exact stack). Posting in case this is a
new regression worth investigating, and happy to be corrected if this
turns out to be a known/duplicate issue.
ENVIRONMENT:
- Server: OpenLiteSpeed 1.9.1 Open (BUILD built: Sun Jul 12 18:16:07 UTC 2026)
- OS: Debian 13 (trixie)
- PHP: lsphp83 8.3.33-1+trixie
- Bubblewrap Container: Enabled (bubbleWrap 2 at vhost level, default
bwrap command line, not customized)
- Module versions: lsquic 4.8.2, modgzip 1.1, cache 1.66,
mod_security 1.4 (libmodsecurity v3.0.15)
- ~30 WordPress vhosts on one box
ISSUE:
After apt upgrade lsphp83 8.3.30 -> 8.3.33 (alongside openlitespeed 1.8.5 ->
1.9.1), the cgid worker process segfaults on startup/reconfig, and continues
to crash repeatedly (several times per minute under traffic that triggers
new cgid spawns), taking lsphp/LSAPI handling down with it.
stderr.log:
Cgid: Child process with pid: XXXXXXX was killed by signal: 11, core dump: 128
dmesg:
litespeed[PID]: segfault at 0 ip 0000000000000000 sp 00007ffdab8b7728 error 14
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
ISOLATION (my own testing):
1. A second, identically configured server running the same OpenLiteSpeed
1.9.1 build but with lsphp83 held at 8.3.32 shows ZERO crashes under
equivalent traffic and vhost config -- isolates the regression to
lsphp83 8.3.33 (or its interaction with Bubblewrap), not to OpenLiteSpeed
1.9.1 core by itself.
2. Disabling Bubblewrap Container at the server level immediately and
completely stopped the crashes (25+ minutes clean under load afterward,
vs. crashes every few seconds beforehand).
3. Confirmed ~27,000 core dumps had accumulated over ~30 hours before I
noticed and cleaned them up (unrelated disk-space side effect, but shows
the crash frequency under our traffic).
GDB BACKTRACE (openlitespeed-dbgsym 1.9.1-2+trixie installed, full symbols,
core taken from my own production server):
#0 0x0000000000000000 in ?? ()
#1 0x000000000056b12a in get_bwrap_bin ()
at src/extensions/cgi/use_bwrap.c:613
#2 get_bwrap_bin ()
at src/extensions/cgi/use_bwrap.c:603
#3 0x000000000056b967 in build_bwrap_exec (...)
at src/extensions/cgi/use_bwrap.c:635
#4 0x000000000056ba0c in exec_using_bwrap (...)
at src/extensions/cgi/use_bwrap.c:831
#5 0x000000000055626c in execute_cgi (...)
at src/extensions/cgi/lscgid.cpp:725
#6 0x0000000000557082 in processreq (...)
at src/extensions/cgi/lscgid.cpp:982
#7 child_main (...) at src/extensions/cgi/lscgid.cpp:1006
#8 new_conn (...) at src/extensions/cgi/lscgid.cpp:1018
#9 run (...) at src/extensions/cgi/lscgid.cpp:1137
#10 lscgid_main (...) at src/extensions/cgi/lscgid.cpp:1306
#11 CgidWorker::spawnCgid (...) at src/extensions/cgi/cgidworker.cpp:184
#12 CgidWorker::start (...) at src/extensions/cgi/cgidworker.cpp:145
#13 CgidWorker::start (...) at src/util/tsingleton.h:53
#14 CgidWorker::config (...) at src/extensions/cgi/cgidworker.cpp:399
#15 HttpServerImpl::configSecurity (...) at src/main/httpserver.cpp:3291
#16 HttpServerImpl::configServerBasic2 (...) at src/main/httpserver.cpp:3531
#17 HttpServerImpl::configServer (...) at src/main/httpserver.cpp:4778
#18 HttpServerImpl::initServer (...) at src/main/httpserver.cpp:5090
#19 HttpServer::initServer (...) at src/main/httpserver.cpp:6199
#20 LshttpdMain::config (...) at src/main/lshttpdmain.cpp:721
#21 LshttpdMain::init (...) at src/main/lshttpdmain.cpp:1027
#22 LshttpdMain::main (...) at src/main/lshttpdmain.cpp:1132
#23 main (...) at src/main.cpp:67
MY OWN NOTES / SPECULATION (not verified against source, just what the
trace suggests):
- Crash happens during server startup/config load path
(CgidWorker::config -> CgidWorker::start -> spawnCgid), i.e. cgid itself
crashes while being spawned/configured, not only during individual PHP
request handling. This would explain the flood of crashes seen
immediately after every service restart.
- get_bwrap_bin() at use_bwrap.c:613 appears twice in the stack (self-
recursive call from line 603) -- I'm guessing this means the function
recurses to try an alternate bwrap binary location/path, and that
recursive branch ends up calling through an uninitialized/NULL function
pointer, but I haven't looked at the actual source to confirm.
- Frame #3 (build_bwrap_exec) shows bwrap_cmdline = 0x0 and begin_param =
0x0 in the locals, which seems consistent with a failed/empty command-
line construction feeding into the crashing call, but again this is my
interpretation, not a confirmed root cause.
I'm not a LiteSpeed developer, so take the interpretation above with a grain
of salt -- the backtrace itself is the solid part. Happy to provide the raw
core file, additional traces from other crashed PIDs, run further tests, or
try a patched build if one becomes available.