Tetreault, Francois | 30 Oct 21:37 2014

Weird behavior observed with NPTL semaphores


We have questions about the glibc Native POSIX Thread Library (NPTL).

We have an application which has a few threads, where mutexs are used to arbitrate access to data. 
The Mutex object content is as shown below.
    mMutex = {
      __data = {
        __lock = -2147473878, 
        __count = 0, 
        __owner = 0, 
        __kind = 33, 
        __nusers = 0, 
          __spins = 0, 
          __list = {
            __next = 0x0
      __size = "\200\000&*", '\000' <repeats 11 times>, "!\000\000\000\000\000\000\000", 
      __align = -2147473878

Where 33 translates to:
#define PTHREAD_MUTEX_TYPE(m) ((m)->__data.__kind & 127)

(Continue reading)

frank ernest | 29 Oct 23:16 2014

What is errno really defined as

I've been following up on the research of Rical Jasan.
In the file /usr/include/bits/errno.h

# ifndef __ASSEMBLER__
/* Function to get address of global `errno' variable.  */
extern int *__errno_location (void) __THROW __attribute__ ((__const__));

#  if !defined _LIBC || defined _LIBC_REENTRANT
/* When using threads, errno is a per-thread value.  */
#   define errno (*__errno_location ())
#  endif
# endif /* !__ASSEMBLER__ */
#endif /* _ERRNO_H */

Errno is declared as a function returning pointer to int and it does not modify or read any golbal variables.
What I'm confused by though, is the redefinition of errno as (*__errno_location ()), namely, why the
extra parentheses, no argument, no const attribute, and the return type is * vs int * which, though
defalting to int, is considered bad programming practice?

In the file /usr/include/errno.h errno is declared as "extern int errno;" and the file
/usr/include/bits/errno.h defines errno and some values for errno and then it includes
/usr/include/linux/errno.h which contains nothing except a directive to include
/usr/include/asm/errno.h which does the same as it's predecessor, this time including
/usr/include/asm-generic/errno.h which defines several values for errno and goes on to include
/usr/include/asm-generic/errno-base.h which defines some more values for errno and the trail ends there.

Looking into the glibc-2.18 source I find __errno_location to possess a variety of definitions. For
instance, on hurd systems glibc-2.18/sysdeps/mach/hurd/errno-loc.c reads:

#include <errno.h>
(Continue reading)

Shaun Jackman | 28 Oct 19:34 2014

Portable glibc binary package

I'd like compile and distribute a binary glibc package that can be
installed in a user's home directory. High performance computing
systems are notorious for running decade-old distributions of Linux,
which makes it difficult to compile and run modern software, and
almost impossible to run binary executables from elsewhere. To update
glibc, I've had fantastic luck building glibc from source and
installing in a home directory. I'd like now to compile and distribute
a binary package of glibc for Linuxbrew (http://brew.sh/linuxbrew/),
called a bottle in Homebrew terminology

I feel like this portability would be technically possible if glibc
were compiled with --prefix=/ and then at run time determined its
prefix (relative to the libc.so.6 loaded by the dynamic interpreter)
and then added that prefix to all glibc files it accessed: other glibc
solibs, localization, config files, and so on.

This feature would be quite useful to me. Does it sound interesting
and/or useful to anyone else? How much work do you think it would be
to implement? Is there a simpler solution?



frank ernest | 28 Oct 14:01 2014

static fork strerror and how they interact.

Hello, I've been reading the glibc docs and they read that the function strerror warns that when using
multiple threads that the static buffer may be overwritten. At the same time I wanted to create a new thread
using fork and it says thet the process it spawns _will_ have a complete copy of the parents memory space. I
also thought from what I learned that declaring anything as static garentees that the said thing will not
be addressable from another process.
My question is this, if I'm correct in my deductions so far am I corretc in believing that the strerror
function, after fork is used, _will_ have a _seperate_ static buffer for the newly spawned process, and so
the buffer will not be accidentally overwritten?

Halim Amer | 27 Oct 16:56 2014

fairness in NPTL mutex


This question concerns the NPTL mutex implementation but it is tightly 
related to the futex syscall. So, please let me know if you think this 
is not the right place to seek answers.

In short, I would like to know if there is a way to guarantee fairness 
in lock acquisition when using a mutex. AFAIK, the NPTL mutex 
implementation is based on atomic operations to acquire the lock and 
block on a FUTEX_WAIT if not successful. The problem arises when a the 
lock is released, a thread/process wakes up with a FUTEX_WAKE but has to 
race again to acquire the lock through atomic operations. Since cases 
where another thread/process wins the lock instead of the one that just 
woke up (ex. tight loop where the thread releases the lock will acquire 
it faster than others) unfairness is  happening.

This issue was already pointed out in the paper "Fuss, Futexes and 
Furwocks: Fast Userlevel Locking in Linux". The authors proposed a fair 
futex syscall (futex_up_fair) to avoid this problem. However it seems 
like it never went to the mainstream kernel. Am I wrong, or there is no 
way to achieve this behavior with the current futex available operations?

I am aware of fair lock implementations such as ticket and queue-based 
locks, but I would like a lock that guarantees fairness while blocking 
threads/processes in the kernel space instead of busy waiting. Any 
suggestions are welcome.

Thank you,

(Continue reading)

Akihiro TSUKADA | 26 Oct 17:13 2014

acceptable new gconv modules


I have a question about contribution to the iconv modules.
I wrote new gconv modules for the character encodings
which are used only in digital television systems,
and I'd like to contribute them if it is possible.

Is a contribution of gconv module for such an application-domain
specific character encoding  acceptable to glibc?

[I posted the same question to libc-alpha but
it seems that it was inappropriate and did not get any responses,
so I re-post it here.]


ricaljasan | 26 Oct 08:06 2014

Aging Standards

In chapter Error Reporting, section Error Messages, there is the
following note:

 <at> strong{Compatibility Note:} The  <at> code{strerror} function was introduced
in  <at> w{ISO C89}.  Many older C systems do not support this function yet.

Given that the standard is now a quarter-century old and thrice revised,
is it still reasonable to expect that an older C system which does not
support the strerror function will, at some point?  Also, are there
"many"?  Perhaps we could say:

Some older C systems do not support this function.

which fulfills the purpose of the compatibility note.

Rical Jasan

ricaljasan | 25 Oct 07:08 2014

Non-volatile errno

Chapter Error Reporting, section Checking for Errors defines errno as:

 <at> deftypevr {Variable} {volatile int} errno

and continues on to say:

Since  <at> code{errno} is declared  <at> code{volatile}, it might be changed
asynchronously by a signal handler; see  <at> ref{Defining Handlers}.

but errno is not declared volatile.  On a system built with 2.19:

$ find /usr/include -name errno.h | xargs grep 'volatile.*errno'
$ find /usr/include -name errno.h | xargs grep 'int errno'
/usr/include/errno.h:extern int errno;

In the current git:
$ find . -name errno.h | xargs grep 'volatile.*errno'
$ find . -name errno.h | xargs grep 'int errno'
./stdlib/errno.h:extern int errno;

I assume extern is taken for granted since I don't see any other
variables declared extern in the manual.

Also, I'm not sure about the correctness of the subsequent description.
 Is it true that a signal handler can asynchronously change errno
*because* it is declared volatile?  If so, does removing the volatile
declaration warrant removing the comment about signal handlers, or
should that be reworded to say something else?

(Continue reading)

Andrei Borzenkov | 16 Oct 19:46 2014

Incorrect timezone offset with current Russian rules - tzdata or glibc bug or normal?

I hit strange problem which looks like a bug and actually caused
serious problem due to different interpretation of current timezone

Current tzdata correctly - as far as I can tell - defines time today as
UTC-4 with summer time inactive:

/etc/localtime  Sat Mar 26 23:00:00 2011 UT = Sun Mar 27 03:00:00 2011 MSK isdst=0 gmtoff=14400
/etc/localtime  Sat Oct 25 21:59:59 2014 UT = Sun Oct 26 01:59:59 2014 MSK isdst=0 gmtoff=14400
/etc/localtime  Sat Oct 25 22:00:00 2014 UT = Sun Oct 26 01:00:00 2014 MSK isdst=0 gmtoff=10800
/etc/localtime  9223372036854689407 = NULL
/etc/localtime  9223372036854775807 = NULL

But the valule of variable "timezone" (man timezone(3)) is set to
UTC-3 ...

bor <at> opensuse:~/tmp/sapttzz> ./sapttz 
Name of local time zone:
   no info (=TZ)

Technical description of local time zone:
   UTC time +10800 sec

Daylight Saving Time at the current/given date is:

where offset is computed as simply

    printf("   UTC time %+ld sec\n",- (long int)timezone);
    if(tm->tm_isdst == 1)
(Continue reading)

Michael Brunnbauer | 14 Oct 14:52 2014

glibc 2.20 make install

hi all,

I remember reading that upgrading glibc with make install is not a good idea
or "not supported". What is the correct way of upgrading glibc?

make install worked for me so far as some basic tools like rm, mv and ln are 
static. But when upgrading from glibc 2.17 to glibc 2.20, I had to use a 
statically linked msgfmt and I had to revert this change from the Changelog:

   * Makerules (make-shlib-link): Use rellns-sh to get relative name

I hope that either there is an easy way to avoid such problems or that the
developers try to keep "make install" simple - so that it can be used for
upgrading. It has worked for me for many years.


Michael Brunnbauer


++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@...
++  http://www.netestate.de/
(Continue reading)

ricaljasan | 5 Oct 08:30 2014

Questions on Documentation and NSS

Does documentation follow the 79-column style?  The style in
manual/nss.texi (and most other manual/*.texi files) appears to lean
towards 72 columns, although there are a handful of lines where it goes
over by a few characters. This isn't including  <at> node,  <at> item, etc., lines
which consistently go much longer on a single line, despite Texinfo
allowing '\' line breaks (tested, no errors, node references remained
correct).  I'll stick with 72 because of the respect-the-locals
philosophy, but that brings up a couple other questions: should I bother
bringing rogue 73+ character lines back to <73 when I come across them
or would changes like those be considered too superfluous?  Occasionally
I would add a character to a line and that would cause an entire
paragraph to shift, causing the diff to appear much more substantial
than it really was.  I left 73-column lines in those cases.  Aside from
preventing diff noise (a term I believe I heard on the list at some
point), I couldn't find any coding guidelines which stated documentation
source should be 72 columns instead of the glibc 79.

Next question: is it "the 'Name Service Switch'" or "Name Service
Switch"?  For instance, the second paragraph of the chapter states, "The
GNU C Library... calls this scheme `Name Service Switch'".  To me, "the
`Name Service Switch'" sounds more appropriate.  I do contrast that with
the acronym, NSS, however.  When I read the initials, I usually don't
prefix the phrase with "the" because I read it as the three letters,
"en-ess-ess", and it acts as its own entity for the most part.

I think the key difference to me is the use of "switch" as a noun in the
sense of: 7) a turning, shifting, or changing. (Dictionary.com)  I just
happened to be reading RFC 1034 the other day and when I finished it and
started skimming the references, I realized some of the historical
significance of the Domain Name Service - I saw a handful of earlier
(Continue reading)