Mildred Ki'Lya | 19 Sep 12:51 2014

fclose blocks until a fread call in another thread returns


I'm having a problem with glibc 2.20. I have a program with multiple 
threads (two are running when I have the problem). The main thread 
contains an event loop. The other thread is just a popen call to nmap, 
and a read call that blocks until nmap has finished.

On the main thread, at some point, I open a file, write some content, 
and then close the file.

The problem is that the main thread is always blocking until the nmap 
thread finishes reading the popen pipe.

Running the application with gdb, I found the following stack traces:

main thread:

#0  0x00007ffff73d8b2b in __lll_lock_wait_private () from 
#1  0x00007ffff7359b25 in __GI__IO_un_link.part.1 () from 
#2  0x00007ffff734dad5 in fclose <at>  <at> GLIBC_2.2.5 () from /usr/lib/

popen thread:

#0  0x00007ffff73bf55d in read () from /usr/lib/
#1  0x00007ffff73596c0 in __GI__IO_file_underflow () from 
#2  0x00007ffff735a6ec in __GI__IO_default_xsgetn () from 
(Continue reading)

Mark Hills | 18 Sep 12:03 2014

LD_PRELOAD functions are called before _init

I am finding that when LD_PRELOAD is used, calls to symbols are commonly 
(incorrectly?) invoked before the _init function.

See the minimal example below; where fopen64() is invoked before the 

This makes it impossible to use _init as a 'constructor'. Am I expecting a 
guarantee that does not exist?

In practice, my problem is this completely prevents wrapping of fopen() in 
a commercial application:

* this application provides a new malloc() by linking against

* the new malloc() function takes a lock and makes a call to fopen()

* without the constructor, our implementation of fopen() must call 
  dlsym(), but this recursively calls malloc() and deadlocks

Is there are better practice to 'initialise' this, or is some bug mangling 
the expected ordering?

This is on Scientific Linux 6.5 (a derivative of RedHat 6.5, see version 

Advice appreciated -- thanks.


(Continue reading)

Steve Ellcey | 12 Sep 01:23 2014

Problem running make check?

Has anyone seen these errors when running 'make check' on glibc?

make[2]: *** No rule to make target
needed by `tests'.

make[2]: *** No rule to make target
needed by `tests'.

I am not sure if it is related or not but when building glibc I got these
warnings from perl:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

I think that after these errors my 'make check' hangs.

Steve Ellcey

Cedric Jehasse | 11 Sep 10:06 2014

-D_FORTIFY_SOURCE=2 doesn't show backtrace on ARM


I have a toolchain with glibc2.19 for ARM. I've a small test program
for -DFORTIFY_SOURCE=2. When a buffer overflow is detected, it doesn't
show a backtrace.
It seems to be because it's missing unwind information for some
functions in the c-library. Eg. for __libc_message.

After adding this line to the libio/Makefile:
CFLAGS-libc_fatal.c = $(exceptions)

I get a partial backtrace:
*** buffer overflow detected ***: ./fortify_test1 terminated
======= Backtrace: =========
======= Memory map: ========
00008000-00009000 r-xp 00000000 00:13 9063117
00010000-00011000 rw-p 00000000 00:13 9063117
00feb000-0100c000 rw-p 00000000 00:00 0          [heap]
b6e05000-b6e0f000 r-xp 00000000 00:0b 362        /lib/
b6e0f000-b6e16000 ---p 0000a000 00:0b 362        /lib/
b6e16000-b6e17000 rw-p 00009000 00:0b 362        /lib/
b6e17000-b6f3e000 r-xp 00000000 00:0b 417        /lib/
b6f3e000-b6f46000 ---p 00127000 00:0b 417        /lib/
b6f46000-b6f48000 r--p 00127000 00:0b 417        /lib/
b6f48000-b6f49000 rw-p 00129000 00:0b 417        /lib/
(Continue reading)

Steven Stewart-Gallus | 9 Sep 19:21 2014

Re: strerror_r() between fork and exec?

Hello, as you can see in the manual (at
strerror_r is not safe in such a situation. The usual trick in such a
situation is to use a pipe to report back the error code to the
parent. If you really cannot use such a trick then one hack you might
be able to do is to fork an initial zygote process from before you
start using multithreaded functions and then spawn off forks of that
process instead of your latest one. These are just a few potential
approaches though and I would need to more about your particular
situation before I could give you better help.

Thank you,
Steven Stewart-Gallus

Ian Pilcher | 8 Sep 23:38 2014

strerror_r() between fork and exec?

It seems like this would be an FAQ, but I haven't been able to find
anything useful ...

Since sys_errlist and sys_nerr are deprecated, how is one supposed to
convert errno values to error messages in an async-safe manner?  As far
as I can tell strerror_r() is not async-safe.

I am using sys_errlist and sys_nerr as part of the error reporting
between fork() and execv() in a multi-threaded program, so (as I now
know) I can only use async-safe functions.



Ian Pilcher                                         arequipeno@...
-------- "I grew up before Mark Zuckerberg invented friendship" --------

Stig | 4 Sep 18:38 2014

Failing to resolve since glibc-2.12-1.107.el6, looking for help testing more recent versions.

Hello and thank you for libc.

I am investigating the inability of RHEL6 and RHEL7 to resolve since glibc-2.12-1.107.el6.

glibc-2.12-1.80.el6, glibc-2.12-1.47.el6 and glibc-2.5-118 on RHEL5
are able to resolve it, I am testing with:

/usr/bin/ltrace -f -s 96 -n 2 -S -tt -T /usr/bin/getent ahosts

glibc-2.12-1.107.el6, glibc-2.12-1.132.el6 and glibc-2.17-55.el7 all
fail to resolve.

I wanted to test on upstream libc versions and non RH distros to see
if it works, I have yet to create a bug.

It works on the 3.11.0-20 Ubuntu shell I can get from using a bash shell/stack which is using Ubuntu EGLIBC

Can anyone help test on more recent versions of glibc?  Or does anyone
recognise the behaviour and know of a related bug that may have been
fixed upstream?

I suspect which is
this patch:

diff -rup a/resolv/res_init.c b/resolv/res_init.c
--- a/resolv/res_init.c 2012-07-26 15:10:45.655638776 -0600
+++ b/resolv/res_init.c 2012-07-26 15:11:27.731423002 -0600
(Continue reading)

Carlos O'Donell | 4 Sep 16:04 2014

Re: pthread_condattr_setclock() and CLOCK_BOOTTIME

On 09/04/2014 06:14 AM, Hannu Mallat wrote:
> Hi all,
> I'm wondering if there would be any ill effects from allowing more
> clock IDs in pthread_condattr_setclock()?
> I was investigating a problem of glib2 timeouts not triggering when
> the platform I'm working on (Jolla, a Linux-based smartphone) is
> suspended. This was because glib2 is using CLOCK_MONOTONIC as its time
> source (in g_get_time_monotonic()), and CLOCK_MONOTONIC does not
> increment during suspend; neither does it jump forward when the device
> wakes up. So a timer that would trigger in T seconds at the time of
> entering suspend is still the same when the device wakes up, no matter
> how long it has been suspended. Timed activity with outside entities,
> e.g., DHCP lease renewal, obviously suffers from this.
> Using CLOCK_BOOTTIME as the glib2 time source instead solves the
> problem of clock not advancing after waking up, and I can schedule a
> wakeup at a suitable time by platform-specific means; but glib2 also
> makes calls to pthread_condattr_setclock() and currently glibc only
> allows the clock id to be CLOCK_MONOTONIC or CLOCK_REALTIME. 
> I have made a patch that allows also CLOCK_BOOTTIME to be used (the
> size of the bit field used to store the clock id is widened to 3 bits
> to fit CLOCK_BOOTTIME id) and on the face of it, it works nicely.
> However I'd like to get more feedback whether a change like this could
> break something I'm not seeing at the moment. Or are there some other
> arguments against the change?
(Continue reading)

ricaljasan | 4 Sep 06:50 2014

nss.texi patch for review

I am preparing a patch for the glibc manual and would like to offer my
first attempt at revision for review. I've edited the manual/nss.texi
file. The diff was obtained from `git diff'. It appears to meet the
criteria in section 13 of, but I wanted
to make sure that was OK.

There are some places where reading only the diff doesn't do the edits
justice, so I wanted to mention those. In "The NSS Configuration File"
section, the language was a little ambiguous to me. The word "action"
seemed to be used for a handful of things, so I tried to rearrange or
word things so they were clearer in context. In general, I tried to make
the language more consistent throughout the chapter.

There are some comments near the end of the diff which I expect to
remove before any commit; they are there for my reference at this time,
but I have left them in case somebody who reviews this knows the answer
to the questions within them. I'll be inspecting the source further to
see if I can answer them myself, but since this email is only intended
as a preliminary review, I thought it wouldn't hurt to leave them.

There are quite a few purely grammatical edits. I always appreciate
well-written documentation and I think (hope) most of them do contribute
to the document's clarity. I've tried not to add anything like
superfluous commas (but no guarantees, as those can be a matter of taste
- another aspect I hope to address with this review).

I believe I've dialed in Thunderbird to send mail according to the
specifications in the third point of section 13 of the the above URL. I
have sent myself some test messages to verify Content-Type is
(Continue reading)

Steven Stewart-Gallus | 29 Aug 01:46 2014

What is GLibc's policy on what is safe to use after a fork from a multithreaded program?


POSIX conformance constrains one to only use async-signal-safe
functions after a fork from a mulithreaded program.  More practically,
fork fucks with state such as the PID, pending signals, timers,
outstanding asynchronous I/O operations and locks that threads are
holding onto.  I need to fork from a multithreaded program and do
complicated things such as sandboxing a process with non
async-signal-safe functions such as mount, syscall, unshare, umount2
and setgroups (I can't exec a helper process because that drops
capabilities automatically).  I can always check the GLibc source and
verify if problems will happen but that becomes really painful when
checking all the system calls I use.  As well, in the future GLibc can
always change functions to be not safe after a fork from a
multithreaded program.  What is GLibc's policy on what is safe to use
after a fork from a multithreaded program?  There doesn't seem to be
any documentation about this.

Thank you,
Steven Stewart-Gallus

Mark Boorer | 28 Aug 17:54 2014

dlopen, RTLD_LOCAL and identically named libraries


I have a question regarding dlopen with RTLD_LOCAL and libraries with
identical names

I have two versions of a library with the same filename in separate
directories, and I have two separate "plugins", each linking to one
version of the library. -> library1/ -> library2/

The path to is baked into the RPATH of each plugin, so when
ran independently, they each call the correct functions. However, when
I load both plugins one after the other (with RTLD_NOW | RTLD_LOCAL) ,
only the first version of is used.

The behaviour is the same if the two versions of share an
soname as well. It seems as though the basename of the library (or the
soname) is checked at a global level.
I would expect that behaviour if was already linked in the
global scope, but in my case it is not.

Is this the intended behaviour? I would have thought that RTLD_LOCAL
would start the library search afresh.

I have a small example C application that demonstrates the issue if required.

Any help/advice would be greatly appreciated :)

(Continue reading)