You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Benjamin Bannier (JIRA)" <ji...@apache.org> on 2015/10/07 13:59:26 UTC

[jira] [Commented] (MESOS-3551) Replace use of strerror with thread-safe alternatives strerror_r / strerror_l.

    [ https://issues.apache.org/jira/browse/MESOS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946733#comment-14946733 ] 

Benjamin Bannier commented on MESOS-3551:
-----------------------------------------

OK, the 0th implementation brought some open ends to the surface.

h5. strerror_r vs. strerror_l

To not break OS X compatibility {{strerror_l}} seems out of reach and we need to resort to {{strerror_r}}.

h5. Glibc provides a non-compliant and potentially broken {{strerror_r}}

Since {{strerror}} uses are currently all across stout (a few), libprocess (a handful), and mesos (plenty), a natural place to implement a wrapper should probably be in stout.

Since stout is header-only a reusable wrapper implementation would probably under the covers use any available implementation (or: _Should this be a reason to (a) implement the wrapper higher up, e.g. in libprocess, or (b) make stout include compiled components, or (c) no, leave it in stout?_).


Assuming we decide to implement this wrapper in a header we would also decide on how to deal with a bug in glibc-2.15:

bq. https://sourceware.org/bugzilla/show_bug.cgi?id=12204

Here glibc's {{strerror_r}} might set the global {{errno}} should it run into errors itself (e.g. because the passed errnum was invalid) which is not compliant and probably unexpected. Fixed versions where shipped e.g. starting with Debian8, CentOS7, Ubuntu14.04.

Since the mesos {{configure.ac}} already requires at least gcc-4.8.0 which is not satisfied by stock Debian7 (gcc-4.7.2), CentOS6 (gcc-4.4.7), or Ubuntu12.04 (gcc-4.6.3) _we could provide an implementation for either (a) only glibc-2.16+, or (b) introduce a workaround if we are using an old version_. If we decide on (a) it appears that adding a configure check wouldn't be sufficient to prevent someone from including the header from stout so we would need to add checks and potentially {{#errors}} in the implementation itself.


h5. Localized error messages

We cannot know the maximal length of error messages since they might be localized. We could either

  (a) implement an algorithm growing the buffer used by {{strerror_r}} until the message fits in, or
  (b) use a fixed buffer size with an educated guess about the maximal error message length (say 2000 char like used in {{llvm::sys::StrError}}).

Given the complexity workarounds for glibc non-conformance might introduce I feel option (b) might be good enough for now.


Any input welcome.


> Replace use of strerror with thread-safe alternatives strerror_r / strerror_l.
> ------------------------------------------------------------------------------
>
>                 Key: MESOS-3551
>                 URL: https://issues.apache.org/jira/browse/MESOS-3551
>             Project: Mesos
>          Issue Type: Bug
>          Components: libprocess, stout
>            Reporter: Benjamin Mahler
>            Assignee: Benjamin Bannier
>              Labels: newbie, tech-debt
>
> {{strerror()}} is not required to be thread safe by POSIX and is listed as unsafe on Linux:
> http://pubs.opengroup.org/onlinepubs/9699919799/
> http://man7.org/linux/man-pages/man3/strerror.3.html
> I don't believe we've seen any issues reported due to this. We should replace occurrences of strerror accordingly, possibly offering a wrapper in stout to simplify callsites.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)