Wang Weidong | 22 Apr 15:19 2014

[Ask for help]: Met a problem with strtof


I test the code below :
int main() {

	char *str1="-0x1.4EF009P-16";
	char *str2="-0x1.744513P-55";
	char *str3="+0x1.1C7509P-19";
	float temp;


	temp = strtof(str1, NULL);
	printf(" %s -> %a\n", str1, temp);


        temp = strtof(str2, NULL);
        printf("%s -> %a\n", str2, temp);
        temp = strtof(str3, NULL);
        printf("%s -> %a\n", str3, temp);
	return 0;


I met a problem as below:
On SUSE-SP1 x86_64 with glibc-2.11-3 and gcc-4.3.2
I got the result:
(Continue reading)

Abhinav Ratna | 22 Apr 02:30 2014

Getting Stack Backtraces on ARM


I have been trying to get stack backtraces on the ARM platform.If I
compile my program with -funwind-tables compiler flag, I am able to
get a stack backtrace through backtrace() and related APIs. However I
observed that the backtrace() API does not work from a signal handler
of the SIGABRT signal.

Furtrher, I observerd that if a SIGTERM signal is received while
executing my application code, I can get a stack backtrace() from
SIGTERM signal handler. However, If the code is executing inside
glibc, and a SIGTERM is received, no meaningful backtrace() is
generated from the SIGTERM signal handler.

Can anyone suggest how to get this working. My glibc version is  2.13-12.12.


Peter TB Brett | 11 Apr 23:21 2014

__statfs64() is declared but not defined

Hi all,

I'm relatively new to the glibc source code, so please bear with me --
this is probably a very basic question!

I'm currently hacking around in shm_open(), trying to change __statfs()
calls to use __statfs64(), as suggested in [BZ 15514].

When I make the naive change and try to compile the library, shm_open.c
gets compiled to an object successfully, but the linker fails with:

  undefined reference to `__statfs64'

If I change the __statfs64() calls to us statfs64() instead, compilation
is successful.

Clearly, the header files used during compilation declare __statfs64(),
but no definition gets included in the object files.

Am I missing something obvious here?



Dr Peter Brett <peter@...>

Waldemar Brodkorb | 11 Apr 12:57 2014

glibc 2.19 for microblazeel

Hi Libc hackers,

I am trying to build glibc 2.18/2.19 based cross toolchain 
for microblaze little endian architecture using buildroot.

I am getting following link error:
shared -static-libgcc -Wl,-O1  -Wl,-z,defs
-Wl,-dynamic-linker=/lib/  -B/
-Wl, -Wl ,-z,combreloc -Wl,-z,relro
-Wl,--hash-style=both -nostdlib -nostartfiles -e __li bc_main
-L/home/wbx/buildroo t/output/build/glibc-2.19/build/math
-L/home/wbx/buildroot/output/build/glibc-2.  19/build/elf
-L/home/wbx/buildroot/output/build/glibc-2.19/build/dlfcn -L/home/w
-L/home/wbx/buildroot/output/buil d/glibc-2.19/build/nis
-L/home/wbx/buildroot/output/build/glibc-2.19/build/rt -L
-L/home/wbx/buildroot/o utput/build/glibc-2.19/build/crypt
-L/home/wbx/buildroot/output/build/glibc-2.19 /build/nptl
(Continue reading)

Robert K. Johnson | 9 Apr 18:53 2014

pthread_cond_wait hangs on pthread_cancel when mutex uses PRIO_INHERIT

 I have seen other entries on this problem and I am aware of the patch
titled "Fix exception table for i386 pthread_cond_wait".  I have the
same problem described in these other entries where it only hangs when
PRIO_INHERIT is used with the mutex.

I am working with an embedded system that uses a Freescale P2020
processor.  I am using the Gentoo Linux distribution as provided by
the SBC vendor.  It uses glibc 2.15-r2 with gcc 4.6.3.  I need to use
PRIO_INHERIT because the condition variable is used by several threads
of different SCHED_RR and SCHED_FIFO priorities.

I am assuming that the i386 does not apply to the Freescale P2020?

Is there a more general patch that fixes this problem for all platforms?

This problem also occurs on an x86_64 system that uses the Ubuntu
Linux distribution with glibc 2.15 and gcc 4.6.3.

P J P | 1 Apr 20:47 2014

[Patch] RFE new API - gettimezone


WRT BZ#1077902 [1], please find attached herein, a patch to add the new API - gettimezone(), which returns
local time zone information in the form of a POSIX TZ environment variable string. The API reads the
'/etc/localtime' file to fetch the said information.

Could someone please help me with the patch review or any other comments that would be helpful in the
development of this API.

Thank you.
Attachment (gettimezone-api.patch): text/x-patch, 3791 bytes
Joël Krähemann | 27 Mar 05:34 2014

resume Aborted

What could cause this behaviour of my sleeping thread. It's a thread pool and the threads were send to sleep
and waken up by the pool.
My application does it several times without any error message.

** (process:16940): Message (recursed): resume Aborted

I'm running debian GNU/Linux and here is the directory containing affected files:

* ags_thread.[ch]
* ags_returnable_thread.[ch]
* ags_task_thread.[ch]
* ags_thread_pool.[ch]

Jan Kratochvil | 26 Mar 19:21 2014

TLS variables access for -static -lpthread executables


gcc -g -o tlsvar tlsvar.c -pthread -static; gdb ./tlsvar -ex 'b 12' -ex r -ex 'info thread' -ex 'p *thread_local_p'

Actual output:
Cannot find executable file `.../tlsvar' in dynamic linker's load module list

Expected output:
$1 = 10 (or 20 or 30)

With -static there is no _r_debug, no link_map, no '.dynamic' section so there
is nothing to pass as 'psaddr_t __map_address' for td_thr_tls_get_addr.

Attached GDB fix that uses td_thr_tlsbase() instead of td_thr_tls_get_addr()
and pass 'modid' as value 1.  But I haven't found it documented anywhere.

Is such patch acceptable for upstream GDB or is there some better way with

#include <pthread.h>
#include <stdio.h>

__thread int *thread_local_p;

void *start_routine(void *arg)
(Continue reading)

Joël Krähemann | 24 Mar 16:51 2014

where to put sigmask of suspend/resume thread

Where to put this code?

  sigdelset(&(thread->wait_mask), AGS_THREAD_SUSPEND_SIG);
  sigdelset(&(thread->wait_mask), AGS_THREAD_RESUME_SIG);

  sa.sa_flags = 0;

  sa.sa_handler = ags_thread_resume_handler;
  sigaction(AGS_THREAD_RESUME_SIG, &sa, NULL);

  sa.sa_handler = ags_thread_suspend_handler;
  sigaction(AGS_THREAD_SUSPEND_SIG, &sa, NULL);

In the thread objects instantiation code which isn't run in its own
thread or in threads start routine?

later I'll do:

  pthread_kill((thread->thread), AGS_THREAD_SUSPEND_SIG);

Gilles DOFFE | 23 Mar 09:56 2014

Problem trying to build eglibc for m68k Coldfire MCF54418


I'm trying to build eglibc 2.19-svnr25243 for a Coldfire MCF54418 (has
no fpu and but has a MMU) with buildroot.

The configuration is this one : (extract from config.log) :
ac_cv_path_BASH_SHELL=/bin/bash libc_cv_forced_unwind=yes
--target=m68k-buildroot-linux-gnu --host=m68k-buildroot-linux-gnu
--build=x86_64-unknown-linux-gnu --prefix=/usr --enable-shared
--without-fp --with-pkgversion=Buildroot --without-cvs
--disable-profile --without-gd --enable-obsolete-rpc

But I always get this kind of errors :
In file included from ../sysdeps/ieee754/flt-32/math_private.h:3:0,
                 from ../sysdeps/ieee754/dbl-64/e_exp.c:40:
../sysdeps/ieee754/dbl-64/e_exp.c: In function '__ieee754_exp':
../sysdeps/ieee754/dbl-64/e_exp.c:61:22: error: 'FE_TONEAREST'
undeclared (first use in this function)
../sysdeps/generic/math_private.h:584:32: note: in definition of macro
   ROUNDFUNC (&__libc_save_rm, (RM))
../sysdeps/ieee754/dbl-64/e_exp.c:61:3: note: in expansion of macro
(Continue reading)

Oliver Becker | 21 Mar 12:53 2014

Memory consumption of iconv


I am developing a server software which spawns up to thousands of client 
processes which use iconv_open (through Qt) to later transform strings between 
different encodings. This works like a charm of course but after a while I 
recognized that every process used about 1MB (non shared) memory for the iconv 
This allone is not that much but If you multiply it by the number of child 
processes, I get a huge size of multiple GB. If you take into account that I 
use the same locales in every child process this is not easy to understand.

I searched through the iconv/gconv sources but didn't get any farther when 
coming to the point where external module functions get called which allocate 
the actual data.

So my question is: Do the gconv_* functions which load the actual "big" (some 
KB) amount of data for transforming use shared memory segments (like shmget) 
and my system just doesn't report it? Or can't they use them because of some 

My thought of using shared memory is to just decrease the overall memory 
footprint of my application from ~1-10GB to several MB.

Thanks in advance.



(Continue reading)