Add _FILE_OFFSET_BITS=64 CPP flag? about libuev

[alcir]

I found an old RPi 2 in a box, do you know if it's supported in Fedora 35?

https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Supported_Hardware
It should be.
But I advise you, that it will be very slow.

[troglobit]

Hmm, yeah that's not good. The whole idea with -D_TIME_BITS=64 is to avoid the Y2038 problems of time_t ... see here for more on that, and what I relied on back in 2017 https://sourceware.org/glibc/wiki/Y2038ProofnessDesign so I wouldn't recommend removing it.

I'll reopen this issue and see if I can get some time to look into this in more detail.

[troglobit]

I have absolutely no idea, I'll have to check. Any tips for a Fedora n00b on how to get the latest yet unreleased 35 to install?

[troglobit]

I'm trying out Rawhide, hopefully I can trigger the same issue you've run into.

[troglobit]

Yup, got the same as you with Rawhide. From what I can understand this is a new GLIBC requirement, we don't need it but it doesn't hurt setting it.

Thank you for taking the time to report it! <3

[alcir]

Yes, unreleased Fedora 35 is still the same thing as Rawhide.
Thanks for the answer.
However it seems that now, with -D_FILE_OFFSET_BITS=64 the package building process for i386 and armv7hl (they are 32 bit architectures, is it?) stays stuck during the test phase.
I.e. https://kojipkgs.fedoraproject.org//work/tasks/5541/73095541/build.log
Could it be related to such CPP flags?

[alcir]

I mean, what could happen if I remove -D_TIME_BITS=64?

[troglobit]

Since Fedora doesn't seem to support x86 (32-bit) anymore, and since I don't have a beefy enough 32-bit ARM system at hand atm, I downloaded OpenSUSE Tumbleweed x86 and installed it with virt-manager for running in Qemu (32-bit x86). Current Tumbleweed has GLIBC 2.33, but since 2.34 was released today maybe they'll have it available soon.

Anyway, I had no problems building, or running the test suite in my Qemu setup.

[troglobit]

According to the GLIBC 2.34 release notes adding -D_FILE_OFFSET_BITS=64 to the build, as in d7a8c78, is the way to go. So there's n possibly something else causing the tests to hang.

Is there any way to get your hands on one of those machines that run the tests, add some debug, abort the tests or get the test-suite.log file?

[alcir]

Is there any way to get your hands on one of those machines that run the tests, add some debug, abort the tests or get the test-suite.log file?

Yes.

[troglobit]

OK ... so will you look into that, or do you expect me to do it?

[alcir]

OK ... so will you look into that, or do you expect me to do it?

I can perform some test. But I need a little of guidance.

[troglobit]

That's great, thanks! :)

The following should be a good start, hopefully I covered all the basics. If any of the tests crash/segfault you can run them in gdb and get a backtrace. That's why I've included -g in the CFLAGS to the configure script.

First a fault hypothesis;
"something wrong with timers after GLIBC change and/or latest libuev commt."

Unfortunately most of the tests rely on timers, so provided the fault hypothesis is correct, all tests except event should either FAIL (return non-zero) or hang like in the autobuilder.

To test:

Either run make check from the libuev source directory, if the tests hang Ctrl-C, check if a test/test-suite.log is created, or
build and run each test separately.

The following is the sequence to build libuev and, with event as test example, build and run that test.

cd libuev/
./autogen.sh
./configure CFLAGS="-g -Og"
make
cd test/
make event
./event
echo $?

The event test should pass OK (return code 0). Repeat the last three steps for active, api, and timer, they should fail.

[alcir]

Ok. I'm on a Raspberry Pi 3 using armv7hl architecture.

Running ./event I get
*** stack smashing detected ***: terminated

Then the process doesn't exit until I press CRTL-C, so echo $? returns 130

[alcir]

If I run strace ./active, I get

...
timerfd_create(CLOCK_REALTIME, TFD_CLOEXEC|TFD_NONBLOCK) = 6
epoll_ctl(3, EPOLL_CTL_ADD, 6, {events=EPOLLIN|EPOLLRDHUP, data={u32=4858008, u64=4787679347132211352}}) = 0
timerfd_create(CLOCK_REALTIME, TFD_CLOEXEC|TFD_NONBLOCK) = 7
epoll_ctl(3, EPOLL_CTL_ADD, 7, {events=EPOLLIN|EPOLLRDHUP, data={u32=4858056, u64=4787679347132211400}}) = 0
timerfd_settime64(7, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET, {it_interval={tv_sec=20558788675239936, tv_nsec=0}, it_value={tv_sec=371086802438761, tv_nsec=0}}, NULL) = 0
timerfd_settime(4857864, 0, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=2, tv_nsec=0}}, NULL) = -1 EBADF (Bad file descriptor)
epoll_wait(3, 

Then the process stays stuck here, until I press CTRL-C

[troglobit]

Awesome, thank you! Both problems look really bad, yet also look completely unrelated to _FILE_OFFSET_BITS=64, and each other. At least at a first glance ...

I found an old RPi 2 in a box, do you know if it's supported in Fedora 35?

I'll try to navigate by feel for now ...

[alcir]

This is strace ./api

...
openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\334\32\2\0004\0\0\0"..., 512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=1837884, ...}) = 0
mmap2(NULL, 1607308, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d52000
mprotect(0xb6ebe000, 65536, PROT_NONE)  = 0
mmap2(0xb6ece000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16c000) = 0xb6ece000
mmap2(0xb6ed2000, 34444, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6ed2000
close(3)                                = 0
set_tls(0xb6f51450)                     = 0
set_tid_address(0xb6f50f78)             = 19830
set_robust_list(0xb6f50f80, 12)         = 0
mprotect(0xb6ece000, 8192, PROT_READ)   = 0
mprotect(0xb6f06000, 4096, PROT_READ)   = 0
mprotect(0xb6f1a000, 4096, PROT_READ)   = 0
mprotect(0x4d0000, 4096, PROT_READ)     = 0
mprotect(0xb6f52000, 4096, PROT_READ)   = 0
ugetrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
munmap(0xb6f4b000, 17325)               = 0
epoll_create1(EPOLL_CLOEXEC)            = 3
timerfd_create(CLOCK_MONOTONIC, TFD_CLOEXEC|TFD_NONBLOCK) = 4
epoll_ctl(3, EPOLL_CTL_ADD, 4, {events=EPOLLIN|EPOLLRDHUP, data={u32=5050380, u64=5050380}}) = 0
getrandom("\x20\xe5\xd3\xe4", 4, GRND_NONBLOCK) = 4
brk(NULL)                               = 0x17d7000
brk(0x17f8000)                          = 0x17f8000
openat(AT_FDCWD, "/dev/one", O_RDONLY)  = -1 ENOENT (No such file or directory)
timerfd_settime(4, 0, {it_interval={tv_sec=0, tv_nsec=100000000}, it_value={tv_sec=0, tv_nsec=100000000}}, NULL) = 0
epoll_wait(3, [{events=EPOLLIN, data={u32=5050380, u64=5050380}}], 10, -1) = 1
read(4, "\1\0\0\0\0\0\0\0", 8)          = 8
epoll_wait(3, [{events=EPOLLIN, data={u32=5050380, u64=5050380}}], 10, -1) = 1
read(4, "\1\0\0\0\0\0\0\0", 8)          = 8
epoll_wait(3, [{events=EPOLLIN, data={u32=5050380, u64=5050380}}], 10, -1) = 1
read(4, "\1\0\0\0\0\0\0\0", 8)          = 8
epoll_wait(3, [{events=EPOLLIN, data={u32=5050380, u64=5050380}}], 10, -1) = 1
read(4, "\1\0\0\0\0\0\0\0", 8)          = 8
epoll_wait(3, [{events=EPOLLIN, data={u32=5050380, u64=5050380}}], 10, -1) = 1
read(4, "\1\0\0\0\0\0\0\0", 8)          = 8
epoll_wait(3, [{events=EPOLLIN, data={u32=5050380, u64=5050380}}], 10, -1) = 1
read(4, "\1\0\0\0\0\0\0\0", 8)          = 8
epoll_wait(3, [{events=EPOLLIN, data={u32=5050380, u64=5050380}}], 10, -1) = 1
read(4, "\1\0\0\0\0\0\0\0", 8)
...

[troglobit]

The api.c code should do 10 laps (1 sec poll per lap) before terminating. I'm guessing it does not ever terminate ...

Btw, thanks for the pointer. I'll see if I can get my hands on an RPi3 instead.

[troglobit]

I have yet to get a rawhide nightly build to boot on the RPi3 I eventually got my hands on. I've tried the last three nightlies and none of them boot to a point where I can get access to a prompt, let alone download and reproduce the problem. Unless someone else can help out, I'm forced to wait until other distros catch up with the latest glibc before I can debug this further. Terribly sorry for the inconvenience!

[oz123]

This issue is reported in https://bugs.gentoo.org/803482.

[troglobit]

Thanks @oz123, really appreciate it!

[mwhudson]

So I've run into this in Ubuntu now, and I noticed while trying to figure out what's going on that the tests are not build with _TIME_BITS=64. This not really thought through change seems to help:

--- libuev-2.3.1.orig/tests/Makefile.am
+++ libuev-2.3.1/tests/Makefile.am
@@ -14,5 +14,5 @@ check_PROGRAMS  = $(TESTS)
 
 # Ignore warnings about unused result, in e.g. write()
 CFLAGS          += -W -Wall -Wextra -Wno-unused-result -Wno-unused-parameter
-CPPFLAGS        += -D_GNU_SOURCE
+CPPFLAGS        += -D_GNU_SOURCE -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64
 LDADD           = -L../src ../src/libuev.la

At least on the armhf system I have access to.

[troglobit]

Interesting, thank you @mwhudson! In retrospect this makes much sense, but it now also dawns on me that these defs. now also are required for all programs linking with libuEv on GLIBC-systems ... and since users rarely read release notes or ChangeLogs, it could very well become a recurring problem.

I still need a way to reproduce this myself, last time I tried with Fedora Rawhide on an RPi3 it could never finish first boot, and I've yet to see any other system adopting the latest GLIBC. What Ubuntu have you been running?

[mwhudson]

It's Ubuntu 20.04 on a raspberry pi 4 a colleague set up for me, building in a impish schroot using mk-subild/sbuild.

https://ubuntu.com/download/raspberry-pi should have enough hints to get Ubuntu going, I'd hope.

As to all downstreams needing to use these defines, hmm. Do you just need to add them to Cflags in src/libuev.pc.in? (I'm not really familiar with this side of pkg-config).

[troglobit]

Aha, that's clever, didn't consider that. Is that a rebuild of the complete dist or just libuev with impish downloaded base?

Yeah, pkg-config will definitely help, but over the years I've seen so many users skip that because they don't like it or understand how to use it. No worries, just me thinking out loud about a potential support issue and how to flag this to users :)

Cheers!

[troglobit]

Finally reproduced, on OpenSUSE Tumbleweed. I must say I loooove these rolling distributions =)

Fix suggested by @mwhudson seems to be the way to go. Preparing for a patch release tomorrow, Sunday 3rd.

[alcir]

Do you think that you will release a new version?

[troglobit]

Preparing for a patch release tomorrow, Sunday 3rd.