Description
We are encountering a segmentation fault when using Hyperscan 5.4.0 in a multi-threaded production environment on Ubuntu 22.04.
The crash occurs inside the AVX2 execution path during hs_scan(). A similar issue was previously observed on Ubuntu 18.04 as well, suggesting this may not be OS-specific.
Environment
Hyperscan version: 5.4.0
OS: Ubuntu 22.04 (also previously seen on 18.04)
Architecture: x86_64 (AVX2 enabled)
Compiler: GCC 11
Build type: Release
Usage: Block mode scanning (hs_scan)
Threading: Multi-threaded (each thread uses its own scratch space)
Observed Behavior
Process crashes with SIGSEGV
Crash consistently happens inside Hyperscan AVX2 internal functions
No error is returned by hs_scan() before crash
stack trace excerpt:
#0 avx2_roseRunProgram()
#1 avx2_roseFloatingCallback()
#2 avx2_fdr_exec_*()
#3 avx2_fdrExec()
#4 avx2_roseBlockExec()
#5 avx2_hs_scan()
#6
(Full trace omitted due to internal code, but follows the same structure)
Repro Characteristics
Occurs under load (high throughput scanning)
Input is a short string (few bytes to tens of bytes)
Pattern database contains multiple expressions (mixed complexity)
Crash is intermittent
What We Checked
Each thread uses its own hs_scratch_t
Scratch space allocated using hs_alloc_scratch
No sharing of scratch across threads
Database compiled once and reused (read-only)
Input buffers are valid and remain alive during scan
No custom allocators involved
Questions / Help Needed
Are there any known issues in 5.4.0 AVX2 execution path (especially rose / fdr engines)?
Could this be related to:
scratch space reuse across fibers / coroutines?
alignment or memory corruption expectations?
specific pattern combinations triggering edge cases?
Are there recommended debugging flags or builds (e.g., assertions, sanitizers) to narrow this down?
Has this been fixed in a newer version?
Additional Notes
The crash appears deep in internal execution (not during compile)
We are using Boost fibers in our threading model (in case stack switching matters)
No obvious memory corruption detected on our side yet
Request Any guidance on:
known bugs,
debugging strategies,
or whether upgrading Hyperscan is recommended
would be greatly appreciated.
Description
We are encountering a segmentation fault when using Hyperscan 5.4.0 in a multi-threaded production environment on Ubuntu 22.04.
The crash occurs inside the AVX2 execution path during hs_scan(). A similar issue was previously observed on Ubuntu 18.04 as well, suggesting this may not be OS-specific.
Environment
Hyperscan version: 5.4.0
OS: Ubuntu 22.04 (also previously seen on 18.04)
Architecture: x86_64 (AVX2 enabled)
Compiler: GCC 11
Build type: Release
Usage: Block mode scanning (hs_scan)
Threading: Multi-threaded (each thread uses its own scratch space)
Observed Behavior
Process crashes with SIGSEGV
Crash consistently happens inside Hyperscan AVX2 internal functions
No error is returned by hs_scan() before crash
stack trace excerpt:
#0 avx2_roseRunProgram()
#1 avx2_roseFloatingCallback()
#2 avx2_fdr_exec_*()
#3 avx2_fdrExec()
#4 avx2_roseBlockExec()
#5 avx2_hs_scan()
#6
(Full trace omitted due to internal code, but follows the same structure)
Repro Characteristics
Occurs under load (high throughput scanning)
Input is a short string (few bytes to tens of bytes)
Pattern database contains multiple expressions (mixed complexity)
Crash is intermittent
What We Checked
Each thread uses its own hs_scratch_t
Scratch space allocated using hs_alloc_scratch
No sharing of scratch across threads
Database compiled once and reused (read-only)
Input buffers are valid and remain alive during scan
No custom allocators involved
Questions / Help Needed
Are there any known issues in 5.4.0 AVX2 execution path (especially rose / fdr engines)?
Could this be related to:
scratch space reuse across fibers / coroutines?
alignment or memory corruption expectations?
specific pattern combinations triggering edge cases?
Are there recommended debugging flags or builds (e.g., assertions, sanitizers) to narrow this down?
Has this been fixed in a newer version?
Additional Notes
The crash appears deep in internal execution (not during compile)
We are using Boost fibers in our threading model (in case stack switching matters)
No obvious memory corruption detected on our side yet
Request Any guidance on:
known bugs,
debugging strategies,
or whether upgrading Hyperscan is recommended
would be greatly appreciated.