Re: deadlock caused by gettext usage in a signal handler

[Peter Stephenson <pws@csr.com>]

Guillaume Chazarain wrote:
> Zsh seems to use dlerror though, hopefully not in a signal handler.

No, the shell is quite cautious what it executes in signal handlers;
system errors are pretty much inevitable, but there's no module handling
there so no call to dlerror.

> strerror_r also calls into gettext, so I don't see how this solves the
> problem.

strerror_r() is the way of ensuring thread safety in printing the
message by providing a buffer into which data is written.  The GNU
library manual entry does actually claim it's thread-safe; that
means that any hidden back-end functions it uses are thread-safe too.

To put it another way, I don't really care how it solves the problem; if
it doesn't it's broken.

There is a possible problem that strerror_r() might need more memory
than we pass it if it's doing random additional things, I suppose, but
the manual doesn't give any guidance.

> > To get diff output for a test failure while I was writing this I needed
> 
> Does that mean you managed to make a reproducible test case?

No, I was testing I hadn't broken anything.

> > to use "diff -a" in ztst.zsh.  I'm not sure if the option is universal,
> > however.
> 
> Confused, I can't see any diff invocation in your patch.

There isn't; I was referring to an existing test that failed while I was
writing the patch: diff assumed the difference in output was binary and
didn't show it.

> It seems to me a possible solution would be to rewrite strerror() in Zsh
> to initially build a static table of translated error messages as
> well as the translation of "Unknown error ". Don't know how much this
> would delay the Zsh startup though.

If strerror_r() really doesn't do what it's supposed to then it needs
fixing.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070