> diff --git a/src/usr.sbin/relayd/hce.c b/src/usr.sbin/relayd/hce.c
> index 5233e2c..4a1bf1c 100644
> --- a/src/usr.sbin/relayd/hce.c
> +++ b/src/usr.sbin/relayd/hce.c
> @@ -94,6 +94,9 @@ hce_setup_events(void)
> table->tls_cfg != NULL)
>
Theo Buehler wrote:
> > I'm not sure if there is much value in percolating the error upwards through
> > tls_init() into a careful termination provides a huge amount of value
> > because
> > the error cannot be resolved without proper build & library support.
>
> Maybe not, but
> I'm not sure if there is much value in percolating the error upwards through
> tls_init() into a careful termination provides a huge amount of value because
> the error cannot be resolved without proper build & library support.
Maybe not, but tls_config_new() can fail for many reasons, so its
https://pubs.opengroup.org/onlinepubs/009695299/functions/pthread_once.html
POSIX does not specify that pthread_once() can return ENOSYS. That is a
weird decision to make in libc.
I'm not sure if there is much value in percolating the error upwards through
tls_init() into a careful termination
Hello everyone,
During the process of porting latest changes of OpenBSD's relayd to FreeBSD, I stumbled upon an
interesting issue. One of them is that the HCE subprocess of relayd gets a SIGSEGV, brining down all
the other relayd subprocesses. Here's how it looks like on the command-line:
