no_stack_overflow_on_drop tests fail on FreeBSD

[bjorn3]

What version of regex are you using?

a9b2e02

Describe the bug at a high level.

The no_stack_overflow_on_drop tests crash on FreeBSD with SIGBUS followed by SIGSEGV. This happens while spawning the thread. I am pretty sure it overflows the stack. 1k of stack seem to be way too little for spawning a thread on FreeBSD. The smallest stack size for which I was able to make it work is 8k. Anything below either crashes or hangs.

What are the steps to reproduce the behavior?

Run cargo test -p regex-syntax on FreeBSD.

What is the actual behavior?

(gdb) run
Starting program: /tmp/cirrus-ci-build/download/regex/target/debug/deps/regex_syntax-872800c174f9b4f7 
warning: Could not load shared library symbols for [vdso].
Do you need "set solib-search-path" or "set sysroot"?
[New LWP 115642 of process 30733]

Thread 2 received signal SIGBUS, Bus error.
[Switching to LWP 115642 of process 30733]
0x00000008019775b4 in find_symdef (symnum=1266, refobj=refobj@entry=0x801993008, defobj_out=defobj_out@entry=0x7fffdfffd0c0, flags=flags@entry=1, cache=cache@entry=0x0, lockstate=lockstate@entry=0x7fffdfffd058) at /usr/src/libexec/rtld-elf/rtld.c:2031
2031        if (ELF_ST_BIND(ref->st_info) != STB_LOCAL) {
(gdb) bt
#0  0x00000008019775b4 in find_symdef (symnum=1266, refobj=refobj@entry=0x801993008, defobj_out=defobj_out@entry=0x7fffdfffd0c0, 
    flags=flags@entry=1, cache=cache@entry=0x0, lockstate=lockstate@entry=0x7fffdfffd058) at /usr/src/libexec/rtld-elf/rtld.c:2031
#1  0x00000008019773fc in _rtld_bind (obj=0x801993008, reloff=14856) at /usr/src/libexec/rtld-elf/rtld.c:1028
#2  0x0000000801972fbd in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121
#3  0x0000000801bbcf9e in malloc_mutex_trylock_final (mutex=<optimized out>)
    at /usr/src/contrib/jemalloc/include/jemalloc/internal/mutex.h:159
#4  malloc_mutex_lock (tsdn=0x801e67090, mutex=<optimized out>) at /usr/src/contrib/jemalloc/include/jemalloc/internal/mutex.h:218
#5  tsd_add_nominal (tsd=0x801e67090) at jemalloc_tsd.c:92
#6  __je_tsd_state_set (tsd=tsd@entry=0x801e67090, new_state=new_state@entry=0 '\000') at jemalloc_tsd.c:193
#7  0x0000000801bbd2e7 in __je_tsd_fetch_slow (tsd=0x801e67090, minimal=<optimized out>) at jemalloc_tsd.c:285
#8  0x0000000801b6c34b in tsd_fetch_impl (init=true, minimal=false)
    at /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:355
#9  tsd_fetch () at /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:381
#10 imalloc (sopts=<optimized out>, dopts=<optimized out>) at jemalloc_jemalloc.c:2256
#11 __je_malloc_default (size=64) at jemalloc_jemalloc.c:2293
#12 0x00000008019bc284 in _thr_attr_init (attr=0x7fffdfffd290) at /usr/src/lib/libthr/thread/thr_attr.c:365
#13 0x0000000001713bf7 in std::sys::unix::thread::guard::current () at sysroot_src/library/std/src/sys/unix/thread.rs:861
#14 0x00000000014f9b62 in std::thread::Builder::spawn_unchecked_::{{closure}} ()
    at /tmp/cirrus-ci-build/download/sysroot/sysroot_src/library/std/src/thread/mod.rs:523
#15 0x00000000014b7b9d in core::ops::function::FnOnce::call_once{{vtable.shim}} ()
    at /tmp/cirrus-ci-build/download/sysroot/sysroot_src/library/core/src/ops/function.rs:250
#16 0x0000000001686fee in <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once ()
    at /tmp/cirrus-ci-build/download/sysroot/sysroot_src/library/alloc/src/boxed.rs:1988
#17 0x0000000001686f8b in <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once ()
    at /tmp/cirrus-ci-build/download/sysroot/sysroot_src/library/alloc/src/boxed.rs:1988
#18 0x000000000164ffed in std::sys::unix::thread::Thread::new::thread_start ()
    at sysroot_src/library/std/src/sys/unix/thread.rs:108
#19 0x00000008019be83a in thread_start (curthread=0x802212700) at /usr/src/lib/libthr/thread/thr_create.c:292

What is the expected behavior?

The test passes.

[BurntSushi]

Hmmm. The test is definitely not particularly robust. The problem with choosing a large stack size is that you also then have to build a bigger expression. For example, on my (Linux) system, the test passes:

$ cargo t --manifest-path regex-syntax/Cargo.toml --lib ast::tests
   Compiling regex-syntax v0.6.28 (/home/andrew/code/rust/regex/regex-syntax)
    Finished test [unoptimized + debuginfo] target(s) in 1.83s
     Running unittests src/lib.rs (target/debug/deps/regex_syntax-cfadee16848a08de)

running 1 test
test ast::tests::no_stack_overflow_on_drop ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 137 filtered out; finished in 0.00s

But that isn't quite the point of the test. Because the test also depends on the fact that if you remove the custom Drop impl on Ast, then the test fails (with a stack overflow):

     Running unittests src/lib.rs (target/debug/deps/regex_syntax-cfadee16848a08de)

running 1 test

thread '<unknown>' has overflowed its stack
fatal runtime error: stack overflow
error: test failed, to rerun pass `--lib`

Caused by:
  process didn't exit successfully: `/home/andrew/code/rust/regex/target/debug/deps/regex_syntax-cfadee16848a08de 'ast::tests'` (signal: 6, SIGABRT: process abort signal)

So okay, I bumped the stack size to 8K and the test does indeed still fail. I then bumped it to 16K and the test still fails. Since that feels comfortably above the minimum that worked for you, I think that sounds okay to me? (It actually fails with 31K too, but not with 32K. So 16K seems like a good number.)

I put #968 up to fix this (including the corresponding test for Hir, which I presume is probably also failing for you).

[BurntSushi]

Also, can I just say, I'm so fucking excited for Cranelift. It is amazing how far y'all are!

[BurntSushi]

This is fixed in regex 1.7.2 and regex-syntax 0.6.29.

[bjorn3]

Thanks! Updated in bjorn3/rustc_codegen_cranelift@ae0a22c and confirmed that it works on FreeBSD.