Hello LiteSpeed Team,
I am reporting a reproducible signal=11 (segmentation fault) crash in OpenLiteSpeed 1.8.5 that is consistently triggered by LiteSpeed Cache plugin 7.8.1 operations.
---
ENVIRONMENT:
- Server: OpenLiteSpeed 1.8.5 Open (BUILD built: Tue Jan 13 22:46:41 UTC 2026)
- OS: Ubuntu 24.04 LTS
- PHP: 8.3.30 (lsphp83)
- LiteSpeed Cache Plugin: 7.8.1
- WordPress: 6.9.4
- WooCommerce: Active
- VPS: KVM 4 (4 CPU cores, 16GB RAM, India – Mumbai)
Module versions:
- lsquic 4.4.1
- modgzip 1.1
- cache 1.66
- mod_security 1.4 (with libmodsecurity v3.0.14)
---
ISSUE:
OpenLiteSpeed workers crash with signal=11 (SIGSEGV) in the cache shared memory module (lsShm) when LiteSpeed Cache plugin 7.8.1 performs any of the following operations:
1. Purge All (toolbar or programmatic)
2. Cache Crawler running
3. CDN sync during purge
The crash is consistent and reproducible. All 4 OLS workers crash sequentially within seconds of triggering a purge or crawler operation. OLS auto-restarts within ~2 seconds each time.
---
CRASH LOG EXCERPT:
2026-04-03 02:51:14 [NOTICE] [AutoRestarter] child process with pid=173432 received signal=11, a core file is created!
2026-04-03 03:06:37 [NOTICE] [AutoRestarter] child process with pid=180093 received signal=11, a core file is created!
2026-04-03 03:22:47 [NOTICE] [AutoRestarter] child process with pid=185811 received signal=11, a core file is created!
2026-04-03 04:07:50 [NOTICE] [AutoRestarter] child process with pid=193667 received signal=11, a core file is created!
(Crashes continued every 10-15 minutes when crawler was running)
---
ROOT CAUSE IDENTIFIED:
The crash occurs in OLS's lsShm (shared memory hash) cache module when LiteSpeed Cache plugin triggers bulk cache operations. The crash also triggers when the crawler re-parses .htaccess files in subdirectories (wp-content/.htaccess, uploads/.htaccess) during cache warm operations.
Note: The crash does NOT occur with FlyingPress or other PHP-level cache plugins — only with LiteSpeed Cache plugin which uses OLS's native cache module via LSCAPI.
---
WORKAROUND:
Switching to FlyingPress (PHP file-based caching) completely eliminates the crash since it does not interact with OLS's lsShm cache module.
---
Note: /tmp/lshttpd/bak_core/ is currently empty as OLS cleaned up core files after restart cycles.
Please investigate the lsShm cache module interaction with LiteSpeed Cache 7.8.1 purge/crawler operations in OLS 1.8.5.
Hatsoff to your innovation its to damn fast
I am reporting a reproducible signal=11 (segmentation fault) crash in OpenLiteSpeed 1.8.5 that is consistently triggered by LiteSpeed Cache plugin 7.8.1 operations.
---
ENVIRONMENT:
- Server: OpenLiteSpeed 1.8.5 Open (BUILD built: Tue Jan 13 22:46:41 UTC 2026)
- OS: Ubuntu 24.04 LTS
- PHP: 8.3.30 (lsphp83)
- LiteSpeed Cache Plugin: 7.8.1
- WordPress: 6.9.4
- WooCommerce: Active
- VPS: KVM 4 (4 CPU cores, 16GB RAM, India – Mumbai)
Module versions:
- lsquic 4.4.1
- modgzip 1.1
- cache 1.66
- mod_security 1.4 (with libmodsecurity v3.0.14)
---
ISSUE:
OpenLiteSpeed workers crash with signal=11 (SIGSEGV) in the cache shared memory module (lsShm) when LiteSpeed Cache plugin 7.8.1 performs any of the following operations:
1. Purge All (toolbar or programmatic)
2. Cache Crawler running
3. CDN sync during purge
The crash is consistent and reproducible. All 4 OLS workers crash sequentially within seconds of triggering a purge or crawler operation. OLS auto-restarts within ~2 seconds each time.
---
CRASH LOG EXCERPT:
2026-04-03 02:51:14 [NOTICE] [AutoRestarter] child process with pid=173432 received signal=11, a core file is created!
2026-04-03 03:06:37 [NOTICE] [AutoRestarter] child process with pid=180093 received signal=11, a core file is created!
2026-04-03 03:22:47 [NOTICE] [AutoRestarter] child process with pid=185811 received signal=11, a core file is created!
2026-04-03 04:07:50 [NOTICE] [AutoRestarter] child process with pid=193667 received signal=11, a core file is created!
(Crashes continued every 10-15 minutes when crawler was running)
---
ROOT CAUSE IDENTIFIED:
The crash occurs in OLS's lsShm (shared memory hash) cache module when LiteSpeed Cache plugin triggers bulk cache operations. The crash also triggers when the crawler re-parses .htaccess files in subdirectories (wp-content/.htaccess, uploads/.htaccess) during cache warm operations.
Note: The crash does NOT occur with FlyingPress or other PHP-level cache plugins — only with LiteSpeed Cache plugin which uses OLS's native cache module via LSCAPI.
---
WORKAROUND:
Switching to FlyingPress (PHP file-based caching) completely eliminates the crash since it does not interact with OLS's lsShm cache module.
---
Note: /tmp/lshttpd/bak_core/ is currently empty as OLS cleaned up core files after restart cycles.
Please investigate the lsShm cache module interaction with LiteSpeed Cache 7.8.1 purge/crawler operations in OLS 1.8.5.
Hatsoff to your innovation its to damn fast
