[Devel] Re: [PATCH 4/4] restart thread-safety: avoid malloc in ckpt_msg()
Nathan Lynch
nathanl at austin.ibm.com
Wed Aug 4 16:30:04 PDT 2010
On Fri, 2010-07-30 at 13:08 -0400, Oren Laadan wrote:
> We use clone and eclone directly and not through glibc, therefore
> must explicitly care about thread-safety of malloc.
>
> This patch removes the use of malloc in ckpt_msg() and instead
> allocate a buffer on the stack. Also convert calls to strerr() to
> to calls to strerr_r() which are thread-safe.
Well, strerror_r is safe only for code that uses glibc/libpthread
interfaces to create threads, right?
Furthermore, strerror_r has different behaviors depending on whether
you're using the XSI- or GNU-specified version. My local strerror(3)
man page says:
"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)."
And I'm seeing garbage output from ckpt_perror() with this patch
applied, implying that the GNU version is in use and that it is electing
not to modify the supplied buffer.
Surely strerror(errno) is "good enough" for error paths?
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list