I was reading source code of glibc. In function void *__libc_malloc(size_t bytes): It shows that if the first thread was created, it calls ptmalloc_init(), and links thread_arena with main_arena, and sets __malloc_initialized to true. On the other hand, the second thread was blocked by the following code in ptmalloc_init(): Thus the thread_arena of the second thread is NULL, and it
Tag: glibc
NTP 4.2.8p15 fails build with glibc 2.34: error: missing binary operator before token “(“
I am building NTP 4.2.8p15 with glibc 2.34. The build fails with error: Answer The problem is answered here: https://bugs.archlinux.org/task/74690 Since glibc 2.34 PTHREAD_STACK_MIN is no longer a compile time constant so can not be used in preprocessor comparisons which causes the compilation failure [1]. The fix attached to the upstream bug report [2] resolves the issue. Additional info: ntp
getifaddrs returning ‘bad file descriptor’/crashing the application
In my program, I have a thread which has to continuously monitor the network interfaces therefore it continuosly uses getifaddrs() in a while loop. Most of the time my program works fine. However, sometimes getifaddrs() returns -1 and errNo = EBADF(bad file descriptor). In order to not exit my thread, I have temporarily replaced exit with continue(as I don’t want
Building and using a newer GLIBC on CentOS 7
I use CentOS 7 and would like to use some Anaconda python package that requires GLIBC_2.18 while the host OS only provides 2.17. I tried compiling a newer version of glibc myself following these instructions. When I try to run any executable with this newer glibc I am getting an error: Is there a workaround for this issue? Update 1:
Why does ld-linux-x86-64.so.2 link against unexpected location?
I have installed a new glibc in /root/tools/ in debian which already has a pre-installed glibc. For testing the new glibc, I type : produces a.out, then type: it shows But type ls -l /root/tools/lib/ld-linux-x86-64.so.2 , it shows /root/tools/lib/ld-linux-x86-64.so.2 -> ld-2.33.so Why does ld.so in new glibc link against ld.so in /lib64 ? How to explain this ? Answer then
Installing libc6 2.33 on debian
I would like to install libc6 2.33 onto a debian docker container for security patch reasons. I can see here that it has been released, and also it is noted here that 2.33 is available. Is there any easy way to get this installed onto a debian docker container? Is there a hard way to get this installed onto a
glibc configure doesn’t recognize Linux header files
I’ve downloaded Linux kernel source from kernel.org to cross-compile glibc onto aarch64 Linux (emulated by QEMU). However, when I run: I get this error: Any idea what I am doing wrong? Answer –with-headers=/home/teo.samarzija/linux-5.7.6/include This looks like a checked-out kernel tree. You need to install the kernel tree first and specify that location, using a command like this: (You still have
Overlapping mappings for loaded ELF segments
I’d like to understand a detail of how the dynamic loader creates mappings for ELF segments. Consider a tiny shared library linked with GNU ld. The program headers are: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x00095c 0x00095c R E 0x200000 LOAD 0x000df8 0x0000000000200df8 0x0000000000200df8 0x000250 0x000258 RW 0x200000 DYNAMIC 0x000e08 0x0000000000200e08 0x0000000000200e08 0x0001d0 0x0001d0
How does the ELF64 loader know to update the initial addresses in .got.plt?
Consider the following program hello.c: The file is compiled with gcc -o hello -Og -g hello.c and then loaded with gdb hello. Inspecting the GOT for the call to printf with p ‘printf@got.plt’ gives which is the offset of the second instruction in the corresponding PLT entry relative to the start of the section. After starting and linking the program
does linux kill() return after the process excute signal handler?
I want use kill() to kill a program. does linux kernel ensure that the program is killed before kill() returned? If not, I have to check whether the program is killed already. Answer does linux kernel ensure that the program is killed before kill() returned? No, kill merely sends a signal to a process or group of processes. Its successful