在ubuntu 22.04LTS中正常，但在20.04中异常 It works fine in ubuntu 22.04LTS, but abnormal in 20.04

[WengerChan]

It works fine in ubuntu 22.04LTS, but abnormal in 20.04

[WengerChan]

git clone https://github.com/wolfcw/libfaketime
cd libfaketime
make
export LD_PRELOAD=/root/libfaketime/src/libfaketime.so.1
date

[nonedark2008]

@WengerChan can you check the output of pstack <pid> where <pid> is a pid of your hung process?
I'm currently investigating another deadlock issue. And in my case the problem is caused by recently merged #488 So maybe this change is also the cause of your problem.

[WengerChan]

@WengerChan can you check the output of pstack <pid> where <pid> is a pid of your hung process? I'm currently investigating another deadlock issue. And in my case the problem is caused by recently merged #488 So maybe this change is also the cause of your problem.

Hang:

root@ubuntu2004:~# cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.4 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
root@ubuntu2004:~# date
Thu 03 Apr 2025 08:36:30 AM CST
root@ubuntu2004:~# export LD_PRELOAD=/root/libfaketime/src/libfaketime.so.1 
root@ubuntu2004:~# date

output of pstack:

root@ubuntu2004:~# ps -ef |grep date
root        7426     995  0 08:36 pts/0    00:00:00 date
root        7428    7415  0 08:36 pts/1    00:00:00 grep --color=auto date
root@ubuntu2004:~# pstack 7426

7426: date
(No symbols found)
0x7f3398b0b498: ???? (0, 0, 0, 0, 0, 0) + ffff80cc671779f1
crawl: Input/output error
Error tracing through process 7426
0x00000000: ????

[csanchezdll]

This is happening to me as well, in Ubuntu 20.04. The actual program you run does not matter (as long as you LD_PRELOAD libfaketime.so.1 or libfaketimeMT.so.1) because the hang happens on library initialization. It seems ftpl_init is called twice (recursively) because it uses sem_open which internally calls __fxstat64 and this is interposed by libfaketime.

(gdb) bt
#0  futex_wait (private=0, expected=1, futex_word=0x7ffff7fbe5f0 <initialized_once_control>) at ../sysdeps/nptl/futex-internal.h:141
#1  futex_wait_simple (private=0, expected=1, futex_word=0x7ffff7fbe5f0 <initialized_once_control>) at ../sysdeps/nptl/futex-internal.h:172
#2  __pthread_once_slow (once_control=0x7ffff7fbe5f0 <initialized_once_control>, init_routine=0x7ffff7fb43a4 <ftpl_really_init>) at pthread_once.c:105
#3  0x00007ffff7fb5a75 in ftpl_init () at libfaketime.c:3078
#4  0x00007ffff7faf5f7 in __fxstat64 (ver=1, fildes=3, buf=0x7fffffffd180) at libfaketime.c:1124
#5  0x00007ffff7c1f8e1 in check_add_mapping (name=name@entry=0x7fffffffd3e1 "faketime_sem_2868572", namelen=namelen@entry=21, fd=fd@entry=3, existing=existing@entry=0x7ffff7ffb000) at sem_open.c:71
#6  0x00007ffff7c200c8 in sem_open (name=0x7fffffffd3e1 "faketime_sem_2868572", oflag=<optimized out>) at sem_open.c:303
#7  0x00007ffff7fadb45 in ft_shm_create () at libfaketime.c:450
#8  0x00007ffff7fadf6a in ft_shm_really_init () at libfaketime.c:563
#9  0x00007ffff7c1f4df in __pthread_once_slow (once_control=0x7ffff7fc0b84 <ft_shm_initialized_once_control>, init_routine=0x7ffff7fadf1f <ft_shm_really_init>) at pthread_once.c:116
#10 0x00007ffff7fadf1c in ft_shm_init () at libfaketime.c:550
#11 0x00007ffff7fb5165 in ftpl_really_init () at libfaketime.c:2834
#12 0x00007ffff7c1f4df in __pthread_once_slow (once_control=0x7ffff7fbe5f0 <initialized_once_control>, init_routine=0x7ffff7fb43a4 <ftpl_really_init>) at pthread_once.c:116
#13 0x00007ffff7fb5a75 in ftpl_init () at libfaketime.c:3078
#14 0x00007ffff7fe0b9a in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffde88, env=env@entry=0x7fffffffde98) at dl-init.c:72
#15 0x00007ffff7fe0ca1 in call_init (env=0x7fffffffde98, argv=0x7fffffffde88, argc=1, l=<optimized out>) at dl-init.c:30
#16 _dl_init (main_map=0x7ffff7ffe190, argc=1, argv=0x7fffffffde88, env=0x7fffffffde98) at dl-init.c:119
#17 0x00007ffff7fd013a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#18 0x0000000000000001 in ?? ()
#19 0x00007fffffffe1fe in ?? ()
#20 0x0000000000000000 in ?? ()

Ubuntu 20.04 is using glibc -2.31, whereas Ubuntu 22.04 uses glibc-2.35. Between the two versions there was a semaphore refactor (commit https://sourceware.org/git/?p=glibc.git;a=commit;h=da4aea0b5e60ec2351367b0facee24e6035a7129) which make sem_open no longer call interposed __fxstat64 but use __fstat64 instead, so the problem does not happen there.

Change in #488 which removed the initialized check to call ftpl_really_init thus makes the library unusable on glibc versions prior to commit da4aea0b5e60ec2351367b0facee24e6035a7129, that is glibc < 2.34.

Options in my mind:

1. Declare the library not compatible with glibc < 2.34
2. Remove the ftpl_init() call from all the interposed functions (constructor is called on dynlib load, and AFAIK libfaketime is meant to be always LD_PRELOADed; maybe I am missing some scenario)
3. Bring back the initialized check which was removed in Fix several data races #488 (we can keep the rest of the changeset)

I think 3 is the simplest change.