On Sun, 2021-10-03 at 11:04 +0300, Nadav Har'El wrote:
> I'm curious where -
> Maybe we have a bug in our /dev (fs/devfs/*) implementation? It
> should generate good errors when trying to open /dev/shm/something -
> not assertion failures and crashes.
Well, this is one of those rabbit holes... The assert was happening in
the abort code. Not sure I understand why yet, but the root cause seems
to be that the erlang runtime is looking for __sigaction. It wants to
play games with the signal handler (for reaons outlined below).
#if !(defined(__GLIBC__) || defined(__DARWIN__) || defined(__NetBSD__)
|| \
defined(__FreeBSD__) || defined(__sun__))
/*
* Unknown libc -- assume musl, which does not allow safe signals
*/
#error "beamasm requires a libc that can guarantee that sigaltstack
works"
#endif /* !(__GLIBC__ || __DARWIN__ || __NetBSD__ || __FreeBSD__
|| \
*
__sun__) \
*/
Now because of the way erts is being built, it actually thinks is on
glibc. So we end up in this function:
static int (*next_sigaction)(int, const struct sigaction *, struct
sigaction *);
static void do_init(void) {
next_sigaction = dlsym(RTLD_NEXT, NEXT_SIGACTION);
if (next_sigaction != 0) {
return;
}
perror("dlsym");
abort();
}
NEXT_SIGACTION is set to '__sigaction' as it would be for glibc. So the
perror("dlsym") is responsible for the message "dlsym: No error
information" we get. Then we abort().
So before I start to put more effort into shm_open / shm_unlink - I
need to understand a bit more about the signal requirements. The
relevnt comment seems to be:
/*
* Erlang code compiled to x86 native code uses RSP as its stack
pointer. This
* improves performance in several ways:
*
* - It permits the use of the x86 call and ret instructions, which
* reduces code volume and improves branch prediction.
* - It avoids stealing a gp register to act as a stack pointer.
*
* Unix signal handlers are by default delivered onto the current
stack, i.e.
* RSP. This is a problem since our native-code stacks are small and
may not
* have room for the Unix signal handler.
*
* There is a way to redirect signal handlers to an "alternate" signal
stack by
* using the SA_ONSTACK flag with the sigaction() library call.
Unfortunately,
* this has to be specified explicitly for each signal, and it is
difficult to
* enforce given the presence of libraries.
*
* Our solution is to override the C library's signal handler setup
procedure
* with our own which enforces the SA_ONSTACK flag.
*/
Rick
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/697e46243f653f65057ae75ce9d6b46677a8f7bd.camel%40rossfell.co.uk.
