From original bug 21002

- I have to think about that strerror_r replacement. Normally we expect just a static string describing a known errno. But I see we have to handle unknown numbers too. hmmm.

The used behavior is GNU-specific:

       The GNU-specific strerror_r() returns a pointer to a string containing the error message.  This may be either a pointer to a string that the function stores  in  buf,  or  a  pointer  to  some
       (immutable)  static  string (in which case buf is unused).  If the function stores a string in buf, then at most buflen bytes are stored (the string may be truncated if buflen is too small and
       errnum is unknown).  The string always includes a terminating null byte ('\0').

A portable way to solve this is stick to the XSI-compliant behavior (as in the patch).

--- a/libdwfl/dwfl_error.c
+++ b/libdwfl/dwfl_error.c
@@ -140,6 +140,7 @@ __libdwfl_seterrno (Dwfl_Error error)
 const char *
 dwfl_errmsg (int error)
 {
+  static __thread char s[64] = "";
   if (error == 0 || error == -1)
     {
       int last_error = global_error;
@@ -154,7 +155,8 @@ dwfl_errmsg (int error)
   switch (error &~ 0xffff)
     {
     case OTHER_ERROR (ERRNO):
-      return strerror_r (error & 0xffff, "bad", 0);
+      strerror_r (error & 0xffff, s, sizeof(s));
+      return s;
     case OTHER_ERROR (LIBELF):
       return elf_errmsg (error & 0xffff);
     case OTHER_ERROR (LIBDW):


However, according to the comments on the original bug, it might be interesting to find a new way to deal with it.