Linda A. Walsh | 19 Jul 04:57 2014

how to redirect glibc's dump output ?

How can I redirect glibc's dump output to a file -- it seems to ignore 
of stdout and stderr.

Barring that, how can I disable the output -- i.e. just let it leave the 


Chip Bagwell | 7 Jul 18:33 2014

Does pthread_mutex_lock/unlock require and imply a memory barrier for all addressable memory?

Dear glibc-help community,

In reading the POSIX 2008 standards found here,,

the following paragraph is written regarding memory synchronization.

"Applications shall ensure that access to any memory location by more
than one thread of control (threads or processes) is restricted such
that no thread of control can read or modify a memory location while
another thread of control may be modifying it. Such access is
restricted using functions that synchronize thread execution and also
synchronize memory with respect to other threads. The following
functions synchronize memory with respect to other threads:"

I read the "synchronize memory with respect to other threads" to mean
that a memory barrier is required in both pthread_mutex_lock() and
pthread_mutex_unlock() along with the other mentioned functions in the
standard.  Otherwise what would be protecting the data
structures/variables you are trying to access/modify inside the
critical section protected by the mutex?

Am I missing something that is leading me to the wrong interpretation
of the POSIX standard?

Thanks in advance!--

Chip Bagwell
(Continue reading)

Warlich, Christof | 4 Jul 09:15 2014

-magign-double on i686

Dear glibc community,

for various reasons being out of my control, I have to compile an application with -malign-double for a i686
(i.e. 32 bit) Linux system. With glibc being the only library used by that application, I wonder which
pitfalls I may run into?

I roughly skimmed the data types of the glibc API, and with very few exceptions (I actually just found one),
glibc's API doesn't seem to use structures that have different internal padding when using either 32 bit
or 64 bit alignment. Thus, is it right that I'm on the save side as long as my application does not use any
glibc functions (or macros) expecting (or returning) structures containing long long or double?

To push the topic even further, the only example I found that seems to have different padding when using
either 32 bit or 64 bit alignment is struct aiocb64, due to its member __off64_t aio_offset:

struct aiocb64
  int aio_fildes;		/* File desriptor.  */
  int aio_lio_opcode;		/* Operation to be performed.  */
  int aio_reqprio;		/* Request priority offset.  */
  volatile void *aio_buf;	/* Location of buffer.  */
  size_t aio_nbytes;		/* Length of transfer.  */
  struct sigevent aio_sigevent;	/* Signal number and value.  */

  /* Internal members.  */
  struct aiocb *__next_prio;
  int __abs_prio;
  int __policy;
  int __error_code;
  __ssize_t __return_value;

(Continue reading)

Joël Krähemann | 2 Jul 13:05 2014


Hi, my name is Joël Krähemann and I'm developing Advanced Gtk+
Sequencer. I get the following backtrace out of gdb. `ags` should be
thread safe so perhaps it's more related to glib and the root cause
may be line 4 and: have_lock=0

I'll read the source code of glib for further investigation, assumed
someone knows the problem it would be nice to know it.

What about ignoring SIGABRT?

            7fff937d0000-7fff93fd0000 rw-p 00000000 00:00 0
            7fff93fd0000-7fff93fd1000 ---p 00000000 00:00 0
            7fff93fd1000-7fff947d1000 rw-p 00000000 00:00 0
            7fff947d1000-7fff947d2000 ---p 00000000 00:00 0
            7fff947d2000-7fff94fd2000 rw-p 00000000 00:00 0
            7fff94fd2000-7fff94fd3000 ---p 00000000 00:00 0
            7fff94fd3000-7fff957d3000 rw-p 00000000 00:00 0
            7fff957d3000-7fff957d4000 ---p 00000000 00:00 0
            7fff957d4000-7fff95fd4000 rw-p 00000000 00:00 0
            7fff95fd4000-7fff95fd5000 ---p 00000000 00:00 0
            7fff95fd5000-7fff967d5000 rw-p 00000000 00:00 0
            Program received signal SIGABRT, Aborted.
            [Switching to Thread 0x7fffeec86700 (LWP 15013)]
            0x00007ffff0303349 in __GI_raise (sig=sig <at> entry=6) at
            56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
            (gdb) make ags
            (gdb) bt
            #0 0x00007ffff0303349 in __GI_raise (sig=sig <at> entry=6) at
(Continue reading)

Waldemar Brodkorb | 28 Jun 10:49 2014 must be installed for pthread_cancel to work

Dear Libc Hackers,

I recently decided to change my toolchain to use a static libgcc.
This initially worked fine so far. So there is no 
in my toolchain nor on my target.

Now I recognized that for backtrace functions and pthread_cancel,
dlopen is used to get the required unwinding code from

Is there a way to avoid when using GNU libc?
Is there a technical reason why the needed code can not be linked
statically from libgcc_eh.a or a libgcc.a (with contains libgcc_eh.a
functions, in the case of a gcc build with static libgcc)?

There are other C libraries, which do not use any unwinding code
from libgcc_eh.a to implement pthread_cancel.

BTW: Is static linking with GNU libc supported or discouraged?
I know there would be still the issue with NSS (but there is a FAQ
entry on your site, which explains a solution for that), but is static
linking a supported method or should I avoid it with GNU libc?

Thanks in advance for clarifying any of my misunderstandings,

best regards

Nathan Lynch | 28 Jun 00:49 2014

missing bits/syscall.h when cross-building scanf15.c test

With current master (6f12d0629f41) I get the following error when trying
to run "make check":

$ printf "CC=arm-linux-gnueabihf-gcc\nBUILD_CC=gcc\n" > configparms
$ CC=arm-linux-gnueabihf-gcc ../../../src/glibc.git/configure \
  --prefix=/usr --disable-profile --host=arm-linux-gnueabihf \
$ make
$ make test-wrapper='/srv/dev/src/glibc.git/scripts/
imx6sl' check
arm-linux-gnueabihf-gcc scanf15.c -c -std=gnu99 -fgnu89-inline  -O2
-Wall -Winline -Wundef -Wwrite-strings -fmerge-all-constants
-frounding-math -g -Wstrict-prototypes   -I../libio -I../stdlib
-I../wcsmbs -I../time -I../string -I../wctype       -I../include
-I/srv/dev/build/glibc/armhf/stdio-common  -I/srv/dev/build/glibc/armhf
 -I../sysdeps/unix/sysv/linux/arm  -I../nptl/sysdeps/unix/sysv/linux
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../nptl/sysdeps/unix/sysv
-I../sysdeps/unix/sysv  -I../sysdeps/unix/arm  -I../nptl/sysdeps/unix
-I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/arm/armv7/multiarch
 -I../sysdeps/arm/armv7  -I../sysdeps/arm/armv6t2
-I../sysdeps/arm/armv6  -I../sysdeps/arm/nptl  -I../sysdeps/arm/include
-I../sysdeps/arm  -I../sysdeps/arm/soft-fp  -I../sysdeps/wordsize-32
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64
-I../sysdeps/ieee754  -I../sysdeps/generic  -I../nptl  -I.. -I../libio
-I. -nostdinc -isystem
(Continue reading)

Linlin Yan (颜林林 | 5 Jun 17:29 2014

Re: Asking for Help on Seeking to End of File

Hi Godmar,

Thank you for your suggestion!

Actually, what the issue affects on our server is a python2-based
application that is using buffered file I/O functions. In addition, I
guess there are many other (scientific computing, biological in our
case) programs also have such problem potentially, since many
non-computer-science background developers usually use those
fopen/fseek/fread functions. So, I would like to know what parameters
of file system and/or storage device could affect the buffered I/O
behaviour, and I think such tuning on system level could help to solve
the problem easier.

On Thu, Jun 5, 2014 at 10:17 PM, Godmar Back <godmar@...> wrote:
> The obvious suggestion would be to not use stdio. What's the benefit of
> using it with such large files?
> Alternatively, you could try setbuf(f, NULL) to turn buffering off - if all
> you're doing is large fread/fwrite, that perhaps shouldn't make a
> difference.
>  - Godmar
> On Thu, Jun 5, 2014 at 7:17 AM, Linlin Yan (颜林林) <yanll@...>
> wrote:
>> Dear developers,
(Continue reading)

Linlin Yan (颜林林 | 5 Jun 13:17 2014

Asking for Help on Seeking to End of File

Dear developers,

I recently noticed that glibc does not move file cursor to the exact
position when fseek(fp, 0, SEEK_END), instead it move to another
position before it and read the bytes left.

Here goes a simple reproducible example (tested in glibc-2.17):

$ cat foo.c
#include <stdio.h>
int main(int argc, char * const *argv)
   FILE *fp = fopen(argv[1], "rb");
   fseek(fp, 0, SEEK_END);
   return 0;
$ gcc foo.c
$ strace ./a.out ~/Research/Data/GRCh38.fa  # This is a big file for
testing (3GB)
open("/home/yanll/Research/Data/GRCh38.fa", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3255188431, ...}) = 0
0) = 0x7fbcc4f70000
fstat(3, {st_mode=S_IFREG|0644, st_size=3255188431, ...}) = 0
lseek(3, 3255185408, SEEK_SET)          = 3255185408
close(3)                                = 0
munmap(0x7fbcc4f70000, 4096)            = 0
(Continue reading)

Nagaraju Mekala | 3 Jun 12:32 2014

Unsigned int


    I am newbie to GLIBC. I was porting GLIBC-2.19 for an embedded
target. Basic port was sucessful and it was working fine.

     When I try to print an unsigned int variable then it is failing
with Segmentation fault.


      #include <iostream>
      using namespace std;

    int main()
     unsigned int a=4;
        cout << "Hello, World!\n";
        cout << a;
        cout << "Bye\n";
        return 0;


    Hello World
    Segmentation fault

 If I use printf then it is working fine. The problem is only with cout

(Continue reading)

John Lumby | 2 Jun 18:15 2014

RE: aio_suspend from different process than originated aio_read

I hope this is the correct list for this question,
if not please advise.

I am working on a multi-process application 
which uses shared-memory buffer for filesystem operations.
It has tradtionally used ordinary synchronous read() and write().
Now we are experimenting with librt's aio functions,
in particular aio_read,  aio_error,  aio_suspend.
Everything works fine when a single process does all of the above.
But the question concerns two processes:
Note that the aiocb is also in shared memory :
   .  process A issues aio_read
   .  process B wants the block being read and needs to wait for
     completion.        It loops on calling aio_suspend with a
     timeout and eventually it finds the read has completed.

This use of timeout to do polling is documented in man page for aio_suspend :

       One can achieve polling by using a non-NULL timeout
       that specifies a zero time interval.

However nowhere in aio man pages is there any statement
permitting or prohibiting multi-process use of an aiocb.

We find that this polling technique done by a different process
works functionally,  except that,  if the read had not completed
on entry to aio_suspend,  then it waits for the full timeout interval
even if,  say,  the read completes half way through that interval.
(Continue reading)

Liu hua | 30 May 05:09 2014

how to compile glibc to pure arm instructions?

Hi guys,

When I compile eglibc for ARM32 platform. I find ports/sysdeps/arm/armv6t2/memchr.S
allways be translated to thumb instructions. There is a macro named "NO_THUMB" in
this file. However I can't define this NO_THUMB through configration.

So my question is how can I compile glibc into pure arm instructions through
configration, rather than modifing makefile?

If not possible, is it necessary to add an interface for this?

Liu Hua