I ran into an odd issue building grub-9999 against libzfs (sys-fs/zfs). I've simplified the issue below.
Basically, if a function with a constructor attribute in a shared library violates the sandbox restrictions, we can end up triggering an infinite recursion scenario.
For example. take fictional library libfoo with constuctor libfoo_init:
1. libfoo_init() is called before libsb_init(), so sb_unwrapped_open still points to open. See note  below.
2. libfoo_init() calls mkdir("/foo")
3. mkdir is wrapped by mkdir_DEFAULT
5. check_syscall; access fails
9. open is wrapped by open_DEFAULT
11. check_syscall; access fails
15. open is wrapped by open_DEFAULT
16. Repeat 10-15 until we run out of stack and segfault.
When threads are involved (as in libzfs), we end up locking somewhere and the sandbox code basically deadlocks instead of recursing. I haven't debugged this to see what is happening there.
I think we could avoid this by calling libsb_init() from before_syscall() or check_syscall(). I tried inserting it at the top of before_syscall, and that seemed to work.
DISCLAIMER: I don't normally work with stuff this low-level, so I may not actually know what I'm talking about.
 Based on a quick google search, it seems the run order of constructors in different compilation units is undefined. So, libsb_init() is not guaranteed to run before libfoo_init().
I have uploaded my simple test case to my devspace if you would like to try it for yourself.
the constructor we're using atm lacks priory, so it runs in an arbitrary order
does it work if you do:
(In reply to comment #2)
Nope, same result.
should be fixed by:
(really this just needed sbio_open to get initialized in the data section, but i figured might as well move as much out as possible while i was there)
(In reply to comment #4)
unfortunately, that fix broke a different use case. if an app starts up and doesn't make any syscalls before main() and modifies the env, things don't get initialized properly. like `env -i env`.
you might want to double check i didn't re-break you