[powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

  • Open
  • quality assurance status badge
Details
3 participants
  • Thiago Jung Bauermann
  • Chris Marusich
  • Kaelyn
Owner
unassigned
Submitted by
Chris Marusich
Severity
normal
C
C
Chris Marusich wrote on 10 Jun 2021 06:21
(address . bug-guix@gnu.org)
871r9atkne.fsf@gmail.com
Hi,

On powerpc64le-linux, using Guix commit
7692295f970a292a3f3db31fc21d05efd97dcb25 on top of Debian unstable, the
libfaketime package fails to build because one of its tests hangs. It
appears to hang during the CLOCK_MONOTONIC test:

Toggle snippet (8 lines)
Running the test program with no faked time specified
$ LD_PRELOAD=../src/libfaketime.so.1 ./timetest
pthread_cond_timedwait: CLOCK_REALTIME test
(Intentionally sleeping 1 second...)
pthread_cond_timedwait: CLOCK_MONOTONIC test
(Intentionally sleeping 1 second..., see docs about CLOCK_MONOTONIC test)

There is no output after that last line. It just sits there. I left it
there for about 24 hours, and it didn't make any progress. I tried with
--cores=1, too, but the problem still occurred. Therefore, it probably
isn't a multithreading issue.

On x86_64-linux Guix, using the aforementioned commit, on top of Fedora
32, the tests pass and the libfaketime builds successfully. Therefore,
this is probably a platform-specific issue.

The README file for libfaketime says:

Toggle quote (8 lines)
> CLOCK_MONOTONIC test: Running "make test" performs a series of tests
> after successful compilation of the libfaketime library. On some
> platforms, the "CLOCK_MONOTONIC test" will apparently hang
> forever. If and only if this happens on your platform, add the CFLAG
> -DFORCE_MONOTONIC_FIX to src/Makefile and recompile libfaketime. Do
> not set FORCE_MONOTONIC_FIX on platforms where the test does not
> hang.

In fact, we do set this in Guix, via the (apparently undocumented)
FAKETIME_COMPILE_CFLAGS environment variable:

Toggle snippet (19 lines)
(define-public libfaketime
(package
(name "libfaketime")
...
(arguments
'(#:phases (modify-phases %standard-phases
(replace 'configure
(lambda* (#:key outputs #:allow-other-keys)
(let ((out (assoc-ref outputs "out")))
(setenv "CC" "gcc")
(setenv "PREFIX" out)

;; XXX: Without this flag, the CLOCK_REALTIME test hangs
;; indefinitely. See README.packagers for more information.
;; Try removing this for future versions of libfaketime.
(setenv "FAKETIME_COMPILE_CFLAGS" "-DFORCE_MONOTONIC_FIX")
...

In spite of this, the test hangs on powerpc64le-linux. Out of
curiosity, I tried NOT setting FAKETIME_COMPILE_CFLAGS, but the behavior
was the same: it still got stuck forever on powerpc64le-linux.

--
Chris
-----BEGIN PGP SIGNATURE-----

iQJIBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmDBkzUVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkad5Q8P+O5nwDGGIaykQbkLx9iBNKpdUYL+
53P7x6/OBOkcA8YhZcuXtVjYekYNVi97uXhqndVc9G/SB/gKWhioVa/KCcewq1Kd
3hzQTOM5LZjuREc2GotEViNGYOhwPHqfwbOmQLlBptj3OmBjUlA7XUkUvlTk2oE9
oYwYckPi9fLoRB6OdTQFqrTS1aOQvePEp0qJYOvoyRvrjDmsKdhkc2ny1HaG12kj
QkY0EUvhX96FadKeilcjMmWNXt1AEvSa7Op2e0J4zwPHioiryCGHuCrCdViWgTnd
aY00vyvRbd+LNmXgBda1ZwjDZ8uzi+D1yAsNGlWmiyCR0aQL+ZqIqnbhwzyJ8m1O
ymHKBHf2njZM37HcOyAkjUwft++Ikcm4trLU3jynFRoevXFnf6xc8pMlELnp19YB
64pi1kqxS9OU/alWEH4lkQNoBfQmH+FSSoELIyuN4t/VswouO2qXuv682tMKO+4Y
21muJDBIJe4Bupp8gE+0ox+DgMHg3ck4wmfJeqSAUBkWJpDNJeGKnJpHaTPehNbY
kFYiRqBoo62Ft9MOyjsujE8b5fDZF+njpNE+Hvf8IehWOtzpOA03YWW4ToD4C/vS
VryYK8FEt9FH6q3l8hBFPkjrD3kdL9s2HyBxjP7OP1EewCEBwd1CGgQTRpdUPTLJ
fWFtWgLzeADkDeQ=
=75A5
-----END PGP SIGNATURE-----

C
C
Chris Marusich wrote on 12 Jun 2021 04:56
(address . 48941@debbugs.gnu.org)
87wnqzssdz.fsf@gmail.com
Hi,

Since I'm not sure how to proceed, I've reported this upstream and asked
for help:


--
Chris
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmDEIkgVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadNacP/1DrC2awRDnUCdPKj2QfVnWUqDq/
M9P5++oDYTi/cVQLo7EyBb5OLaMajnO4hNhBrafqGTc6Q/udoji1X/7dJfxzdre0
Uzzurk5qzyEPYDo7fw/gtx6Ok5UZ4Dc/zuOe4zBsBbAkw8yaD9ONnBRgXZl8AGaQ
mFPYtjr2+cCZHLOUWVV+9B3g5FLvnsjcX3IfKjzvCT9YF1Y0fEuwerHTrhBsQEJb
6QVCLzqObThhjakAIlVozqVQFUbrp6o6hLPl1pT44Z5VuDWyIWBf1q73JonV5d3q
1dKv3isuVYK8IhiAWV/dWM3lWt/PZ4X9rI4317zANthNATFBjOzfpCo9U2AGRW/O
WM2G1FhfVET+1PUXAz5RxcGN9p2t/IQmMOBtBnB7dvARg6dNYEFnCowtL6BESOao
oHkeFWB4oQPJMgb+j8Roa4KtjaCuFQ6z15Mk1ZdIP9iStHVjD1JGlXNQORkaXX3y
OqzByvkUrfmYmzpthk77yTxHr8m1RG665VU4b4TOXfvEOjjqjR9Goz9a1RgETM6U
XZasaL5wZguftXAAA7/GkptPO1mE5wZxRKw4cvKjlJ/vE4xnBpLJNMdGvOAjIqfT
v0F9MtHcbfJgloRLAI+R9Y3k4A4+wgLUE+486pC50ySA9ZjGF/ffuSM85hbPJQws
Yp1WZAp4X1TRxrOc
=aG6a
-----END PGP SIGNATURE-----

C
C
Chris Marusich wrote on 21 Jul 2021 07:08
(address . 48941@debbugs.gnu.org)(address . guix-devel@gnu.org)
874kco8d9s.fsf@gmail.com
Hi,

I need a little help figuring out how to use gdb in Guix for bug 48941:


Here's the situation. A libfaketime test hangs forever. Upstream
suggested I debug it. I'm trying to, but gdb errors out. What am I
doing wrong? It's probably something simple, but I can't see what.

I'll describe what I've done. First, I started a build like so:

./pre-inst-env guix build --keep-failed libfaketime

While the problematic test hung, I found the PID of the test and killed
it. This caused the build to fail, leaving the build environment for me
to play around in.

I entered a pure environment that contains all the things I need to
debug the test (gcc 10.3.0 is currently the default gcc on
core-updates):

./pre-inst-env guix environment --pure libfaketime --ad-hoc gcc-toolchain@10.3.0 gcc-toolchain@10.3.0:debug gdb

In the pure environment, I confirmed I can build and run the hanging
test via the following commands (I added -g in order to get debug
symbols):

make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix
make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix test

OK, so I can trigger the hang. Great! Next step, fire up GDB:

Toggle snippet (21 lines)
[0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source/test
$ gdb ./timetest
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64le-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./timetest...
(gdb)

The debug symbols provided by gcc-toolchain@10.3.0:debug are under
$GUIX_ENVIRONMENT/lib/debug. This is the value of GUIX_ENVIRONMENT:

Toggle snippet (4 lines)
$ echo $GUIX_ENVIRONMENT
/gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile

By the way, this directory corresponds to glibc 2.33:

Toggle snippet (4 lines)
$ realpath /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug
/gnu/store/8akrlhc25d7xvi85gzvginw0vdi4zyg4-glibc-2.33-debug/lib/debug

Let's tell GDB where to find those debug symbols:

(gdb) set debug-file-directory /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug

Let's also tell GDB to set the environment variables that upstream
recommended when running the test program:

Toggle snippet (5 lines)
(gdb) set environment LD_PRELOAD=../src/libfaketime.so.1
(gdb) set environment FAKETIME=-10d
(gdb) set environment NO_FAKE_STAT=1

Now run it:

Toggle snippet (10 lines)
(gdb) run
Starting program: /tmp/guix-build-libfaketime-0.9.9.drv-0/source/test/timetest
/bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ../src/libfaketime.so.1)
/bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libpthread.so.0)
/bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libdl.so.2)
/bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/librt.so.1)
During startup program exited with code 1.
(gdb)

Huh? What happened? I've double checked that I'm using gdb provided by
Guix:

Toggle snippet (4 lines)
$ type -P gdb
/gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/bin/gdb

I also tried running gdb by invoking it via that absolute file name, and
it still errored out in the same way.

I'm operating in a --pure environment. All the tools are provided by
Guix. I'm surprised that /bin/sh and /lib are even mentioned above.

If anyone can provide any advice, I'd be very grateful. I'm not sure
how to proceed.

--
Chris
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmD3q88VHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadEpsQAIJLVTNnKRcnkie5ZVnnElRq9ARJ
Vbe9LOeTunNHTSNe/EvpxXyBRu3jkSF5nK5BaiA49WpdtL3y2R+V+jv8cHbupg+D
jwXxzyIZXcb+IazfctTysyCM/3ocVK/f0ENdajzNbCyEF0327CsTpruYxVIhGcyl
xKN1a/mPbRJlWq6ay59nr3CL19CoUIOpRnzZdi114Y4RhOX1o1ULSkhO6g988Q8C
wde1iBbK6SffzMKimk5ChjOk1SzfaPef+IZL8PDl9B4poPGjiXgBLef3AOrvobFq
z5zx6jNfi2tMMO0dDoSUDNjcnkfZHooyu3VM+McpIqa5fTs0cdK1qYn+EP9vzltk
EPIcd37AgQuKPQFB15w67zKPLlk7BFfQ3V/WHM2Hft9u0+Uw53mSum5XugJEUVFz
hb3CS22Th84fGhUHRHfldfA9jWpfdFA2xlqPOxH0+XO+81II+/GrBtrKaKq8BXEL
YagM4LkOiDF6yYN6f2ItkRtJiCadAg+ws5vbfmFN77bmbP2m5HZb6sHhBntY4R2M
lUcG9g/1JjGo3Gm/cPo+isCjAC7QZOknCdlPP75X0+fD7+DQLzcCHdl4t3YnZxbF
UcJfXf05SRiOyC8YaK0oj/jvlivDYgWcX6CttVW1USGb/7cTIlyjp2lIwbPSIXOq
axD/y2F4IwjJ78GR
=ef4c
-----END PGP SIGNATURE-----

K
K
Kaelyn wrote on 21 Jul 2021 16:31
(name . Chris Marusich)(address . cmmarusich@gmail.com)
GijrfHfxGeVNJVWlkkOpscqh2dekCZhqP6OG4ihBNoSCZlxk0evgqhgCT4WEpHdpRsEk_tBHC0rsTHHgl20vhEBt8UJHnsNNglj5-SF4JrI=@protonmail.com
Hi,

??????? Original Message ???????

On Wednesday, July 21st, 2021 at 1:08 AM, Chris Marusich <cmmarusich@gmail.com> wrote:

Toggle quote (132 lines)
> Hi,
>
> I need a little help figuring out how to use gdb in Guix for bug 48941:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48941
>
> Here's the situation. A libfaketime test hangs forever. Upstream
>
> suggested I debug it. I'm trying to, but gdb errors out. What am I
>
> doing wrong? It's probably something simple, but I can't see what.
>
> I'll describe what I've done. First, I started a build like so:
>
> ./pre-inst-env guix build --keep-failed libfaketime
>
> While the problematic test hung, I found the PID of the test and killed
>
> it. This caused the build to fail, leaving the build environment for me
>
> to play around in.
>
> I entered a pure environment that contains all the things I need to
>
> debug the test (gcc 10.3.0 is currently the default gcc on
>
> core-updates):
>
> ./pre-inst-env guix environment --pure libfaketime --ad-hoc gcc-toolchain@10.3.0 gcc-toolchain@10.3.0:debug gdb
>
> In the pure environment, I confirmed I can build and run the hanging
>
> test via the following commands (I added -g in order to get debug
>
> symbols):
>
> make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix
>
> make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix test
>
> OK, so I can trigger the hang. Great! Next step, fire up GDB:
>
> --8<---------------cut here---------------start------------->8---
>
> [0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source/test
>
> $ gdb ./timetest
>
> GNU gdb (GDB) 10.2
>
> Copyright (C) 2021 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law.
>
> Type "show copying" and "show warranty" for details.
>
> This GDB was configured as "powerpc64le-unknown-linux-gnu".
>
> Type "show configuration" for configuration details.
>
> For bug reporting instructions, please see:
>
> https://www.gnu.org/software/gdb/bugs/.
>
> Find the GDB manual and other documentation resources online at:
>
> http://www.gnu.org/software/gdb/documentation/.
>
> For help, type "help".
>
> Type "apropos word" to search for commands related to "word"...
>
> Reading symbols from ./timetest...
>
> (gdb)
>
> --8<---------------cut here---------------end--------------->8---
>
> The debug symbols provided by gcc-toolchain@10.3.0:debug are under
>
> $GUIX_ENVIRONMENT/lib/debug. This is the value of GUIX_ENVIRONMENT:
>
> --8<---------------cut here---------------start------------->8---
>
> $ echo $GUIX_ENVIRONMENT
>
> /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile
>
> --8<---------------cut here---------------end--------------->8---
>
> By the way, this directory corresponds to glibc 2.33:
>
> --8<---------------cut here---------------start------------->8---
>
> $ realpath /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug
>
> /gnu/store/8akrlhc25d7xvi85gzvginw0vdi4zyg4-glibc-2.33-debug/lib/debug
>
> --8<---------------cut here---------------end--------------->8---
>
> Let's tell GDB where to find those debug symbols:
>
> (gdb) set debug-file-directory /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug
>
> Let's also tell GDB to set the environment variables that upstream
>
> recommended when running the test program:
>
> --8<---------------cut here---------------start------------->8---
>
> (gdb) set environment LD_PRELOAD=../src/libfaketime.so.1
>
> (gdb) set environment FAKETIME=-10d
>
> (gdb) set environment NO_FAKE_STAT=1
>
> --8<---------------cut here---------------end--------------->8---
>
> Now run it:
>
> --8<---------------cut here---------------start------------->8---
>
> (gdb) run
>
> Starting program: /tmp/guix-build-libfaketime-0.9.9.drv-0/source/test/timetest
>
> /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ../src/libfaketime.so.1) /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version` GLIBC_2.32' not found (required by /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libpthread.so.0)

Are you using Guix on a foreign distro? This line looks like your distro's normal libc.so was being used and it was from glibc-2.31 or older. The x86-64 systems I have that run pure Guix don't have any /lib*/ directories. You might try running gdb with LD_LIBRARY_PATH=/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib to have the Guix libc.so picked up before the other one. HTH

Cheers,
Kaelyn

Toggle quote (36 lines)
>
> /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libdl.so.2) /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version` GLIBC_2.32' not found (required by /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/librt.so.1)
>
> During startup program exited with code 1.
>
> (gdb)
>
> --8<---------------cut here---------------end--------------->8---
>
> Huh? What happened? I've double checked that I'm using gdb provided by
>
> Guix:
>
> --8<---------------cut here---------------start------------->8---
>
> $ type -P gdb
>
> /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/bin/gdb
>
> --8<---------------cut here---------------end--------------->8---
>
> I also tried running gdb by invoking it via that absolute file name, and
>
> it still errored out in the same way.
>
> I'm operating in a --pure environment. All the tools are provided by
>
> Guix. I'm surprised that /bin/sh and /lib are even mentioned above.
>
> If anyone can provide any advice, I'd be very grateful. I'm not sure
>
> how to proceed.
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Chris
T
T
Thiago Jung Bauermann wrote on 22 Jul 2021 20:35
8085623.jmDMpusFku@popigai
Hello,

Em quarta-feira, 21 de julho de 2021, às 11:31:25 -03, Kaelyn escreveu:
Toggle quote (5 lines)
> Hi,
>
> ??????? Original Message ???????
>
> On Wednesday, July 21st, 2021 at 1:08 AM, Chris Marusich
<cmmarusich@gmail.com> wrote:
Toggle quote (19 lines)
> > Now run it:
> >
> > --8<---------------cut here---------------start------------->8---
> >
> > (gdb) run
> >
> > Starting program:
> > /tmp/guix-build-libfaketime-0.9.9.drv-0/source/test/timetest
> >
> > /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not
> > found (required by ../src/libfaketime.so.1) /bin/sh:
> > /lib/powerpc64le-linux-gnu/libc.so.6: version` GLIBC_2.32' not found
> > (required by
> > /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libpthread.
> > so.0)
> Are you using Guix on a foreign distro? This line looks like your
> distro's normal libc.so was being used and it was from glibc-2.31 or
> older.

GDB uses the shell to launch the debugged program. That is probably where
‘/bin/sh’ is entering the picture here. I don’t know whether that has any
relation to your foreign distro’s libc being used.

The output of `help run` in GDB mentions that the shell is specified by the
‘$SHELL’ environment variable. Perhaps you have that set?

One way to see if this is the problem is to use the GDB command
`set startup-with-shell off` to make it launch the debugged program without
the shell.

Toggle quote (5 lines)
> The x86-64 systems I have that run pure Guix don't have any
> /lib*/ directories. You might try running gdb with
> LD_LIBRARY_PATH=/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/l
> ib to have the Guix libc.so picked up before the other one. HTH

Another alternative worth trying is the ‘--container’ option to ‘guix
environment’, to completely isolate GDB from the foreign distro. You might
want to add the coreutils package to the ‘--ad-hoc’ list so that you can
get amenities such as an ls command. :-)

--
Thanks,
Thiago
C
C
Chris Marusich wrote on 23 Jul 2021 07:34
(name . Kaelyn)(address . kaelyn.alexi@protonmail.com)
87v9511tla.fsf@gmail.com
Hi Kaelyn,

Thank you for the reply.

Kaelyn <kaelyn.alexi@protonmail.com> writes:

Toggle quote (7 lines)
> Are you using Guix on a foreign distro? This line looks like your
> distro's normal libc.so was being used and it was from glibc-2.31 or
> older. The x86-64 systems I have that run pure Guix don't have any
> /lib*/ directories. You might try running gdb with
> LD_LIBRARY_PATH=/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib
> to have the Guix libc.so picked up before the other one. HTH

Yes, I'm using Guix on a foreign distro. It isn't clear to me what is
trying to access the /lib directories. That's what I'm trying to figure
out. In a --pure environment using only Guix-built tools, one would
expect that I would not have to set LD_LIBRARY_PATH. However, if I
can't figure it out, that's another trick I can try.

--
Chris
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmD6VPEVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkad1/oQAJ4J8jNcBJnglAMTV/7lEGsFT8AS
Vg4wKqfuXZbOyu5YF2pfzkO684G9yAVBghh/WjDnS139ToWJakv6WNwSMfZz7mS/
cxuFuCj7qksbXrR/xrJ1qKvn3u7f0jmqiiGP8TtYoV8xBlRiMlpt/cJ/2H7lYyKI
bQEUd5hkZ2UagZdTzTzPfoacFv0/DCyetUxpJjr2vsVk4ZVWXnU1pF36R8phK9ob
ku5mU910gPgjXBnUOEoAxxIW0NYXQe+BQfBhl75HD69YOlsA5gfmtiBDXHQ67fXy
ne/3ppoXFtOhyog77EHMFbrbXiQZsBOqUO8WpAH0fF74QqMXg5DG1fPvAKjr+xw2
qjpJglQHTaYlsyIX4+2cPjiDIil5EM+1siBhEnKRfEQhltbIXbQ4BzUc3OOHx4am
pLGBQ2puN7YGklekI63Thh/A0V0gNJGWqFJA3Vu6hK3D0BJPC8krl/sflDxGqDst
5tCb3lfrXBbUuhJwRM6mj/7RFBk/CrEseojWLotPHsETcD0PTZhDV6ZJ48Un4sUs
DF9fnfV5dRuFWG4LNKB34CJeYyj9GJDxIKLCriwb1cQdtFm3KaTTtj++HmnsbW6G
3wbfLNNXV+sBZgZy8/MCyaBse6r9xUUEkjPIjuMFKKZomcTek1OfYpK+Za17DNK8
tk87vF+hq9alazyb
=3ciu
-----END PGP SIGNATURE-----

C
C
Chris Marusich wrote on 23 Jul 2021 08:01
(name . Thiago Jung Bauermann)(address . bauermann@kolabnow.com)
87r1fp1sc9.fsf@gmail.com
Thiago Jung Bauermann <bauermann@kolabnow.com> writes:

Toggle quote (11 lines)
> GDB uses the shell to launch the debugged program. That is probably where
> ‘/bin/sh’ is entering the picture here. I don’t know whether that has any
> relation to your foreign distro’s libc being used.
>
> The output of `help run` in GDB mentions that the shell is specified by the
> ‘$SHELL’ environment variable. Perhaps you have that set?
>
> One way to see if this is the problem is to use the GDB command
> `set startup-with-shell off` to make it launch the debugged program without
> the shell.

Thank you for this suggestion. When I ran "set startup-with-shell off",
gdb successfully launched the program.

It seems something in the Guix-built software is trying to run /bin/sh.
Perhaps there is stray hard-coded path in GDB or something that needs to
be fixed... In any case, I'm glad I can continue debugging!

Toggle quote (10 lines)
>> The x86-64 systems I have that run pure Guix don't have any
>> /lib*/ directories. You might try running gdb with
>> LD_LIBRARY_PATH=/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/l
>> ib to have the Guix libc.so picked up before the other one. HTH
>
> Another alternative worth trying is the ‘--container’ option to ‘guix
> environment’, to completely isolate GDB from the foreign distro. You might
> want to add the coreutils package to the ‘--ad-hoc’ list so that you can
> get amenities such as an ls command. :-)

When I tried "--container", gdb successfully launched the program. So
it's another viable work-around for the gdb issue.

As for the actual libfaketime bug, when it hung I pressed Control+C, and
here's the backtrace at that point:

Toggle snippet (7 lines)
(gdb) backtrace
#0 0x00007ffff7eccba0 in __futex_abstimed_wait_common64 (futex_word=0x7ffff7aaf1c0, expected=<optimized out>, clockid=<optimized out>, abstime=0x0, private=<optimized out>, cancel=<optimized out>) at ../sysdeps/nptl/futex-internal.c:74
#1 0x00007ffff7eb9934 in __pthread_clockjoin_ex (threadid=140737348563184, thread_return=0x7fffffffe2d0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:102
#2 0x00007ffff7eb9684 in __pthread_join (threadid=<optimized out>, thread_return=<optimized out>) at pthread_join.c:24
#3 0x0000000010001784 in main (argc=1, argv=0x7fffffffe718) at timetest.c:146

Here's the entire session in which I built the problematic test and
debugged it, including a full back trace with local variables:

Toggle snippet (195 lines)
[0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0
$ ~/guix-core-updates/pre-inst-env guix environment libfaketime --ad-hoc gcc-toolchain@10.3.0:debug gdb
[0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0
$ cd source/
[0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source
$ make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix clean
make -C src clean
make[1]: Entering directory '/tmp/guix-build-libfaketime-0.9.9.drv-0/source/src'
make[1]: Leaving directory '/tmp/guix-build-libfaketime-0.9.9.drv-0/source/src'
make -C test clean
make[1]: Entering directory '/tmp/guix-build-libfaketime-0.9.9.drv-0/source/test'
make[1]: Leaving directory '/tmp/guix-build-libfaketime-0.9.9.drv-0/source/test'
[0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source
$ make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix
make -C src all
make[1]: Entering directory '/tmp/guix-build-libfaketime-0.9.9.drv-0/source/src'
gcc -o libfaketime.o -c -std=gnu99 -Wall -Wextra -Werror -Wno-nonnull-compare -DFAKE_PTHREAD -DFAKE_STAT -DFAKE_UTIME -DFAKE_SLEEP -DFAKE_TIMERS -DFAKE_INTERNAL_CALLS -fPIC -DPREFIX='"'/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix'"' -DLIBDIRNAME='"'/lib/faketime'"' -DFORCE_MONOTONIC_FIX -g libfaketime.c
gcc -o libfaketime.so.1 -Wl,-soname,libfaketime.so.1 -lpthread -Wl,--version-script=libfaketime.map -shared libfaketime.o -ldl -lm -lrt
gcc -o libfaketimeMT.o -c -std=gnu99 -Wall -Wextra -Werror -Wno-nonnull-compare -DFAKE_PTHREAD -DFAKE_STAT -DFAKE_UTIME -DFAKE_SLEEP -DFAKE_TIMERS -DFAKE_INTERNAL_CALLS -fPIC -DPREFIX='"'/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix'"' -DLIBDIRNAME='"'/lib/faketime'"' -DFORCE_MONOTONIC_FIX -g -DPTHREAD_SINGLETHREADED_TIME libfaketime.c
gcc -o libfaketimeMT.so.1 -Wl,-soname,libfaketimeMT.so.1 -lpthread -Wl,--version-script=libfaketime.map -shared libfaketimeMT.o -ldl -lm -lrt
gcc -o faketime -std=gnu99 -Wall -Wextra -Werror -Wno-nonnull-compare -DFAKE_PTHREAD -DFAKE_STAT -DFAKE_UTIME -DFAKE_SLEEP -DFAKE_TIMERS -DFAKE_INTERNAL_CALLS -fPIC -DPREFIX='"'/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix'"' -DLIBDIRNAME='"'/lib/faketime'"' -DFORCE_MONOTONIC_FIX -g faketime.c -lpthread -Wl,--version-script=libfaketime.map -lrt
make[1]: Leaving directory '/tmp/guix-build-libfaketime-0.9.9.drv-0/source/src'
[0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source
$ make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix test
make -C src all
make[1]: Entering directory '/tmp/guix-build-libfaketime-0.9.9.drv-0/source/src'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/tmp/guix-build-libfaketime-0.9.9.drv-0/source/src'
make -C test all
make[1]: Entering directory '/tmp/guix-build-libfaketime-0.9.9.drv-0/source/test'
gcc -c -std=gnu99 -Wall -DFAKE_STAT -Werror -Wextra -DFORCE_MONOTONIC_FIX -g timetest.c
gcc -o timetest timetest.o -lrt -lpthread
./testframe.sh functests
# Begin Test Suites in functests

# Begin functests/test_exclude_mono.sh
# PLATFORM=linuxlike
out=1763825.60556745 When not faking monotonic time, timestamps should be different ref=1763826.62729077 - ok
# functests/test_exclude_mono.sh summary: 1 succeeded, 0 failed
# End functests/test_exclude_mono.sh - OK

# Begin functests/test_null.sh
out=0 () ref=1627019232 - ok
# functests/test_null.sh summary: 1 succeeded, 0 failed
# End functests/test_null.sh - OK

# Begin functests/test_true.sh
# functests/test_true.sh summary: 1 succeeded, 0 failed
# End functests/test_true.sh - OK

# Begin functests/test_walkone.sh
# PLATFORM=linuxlike
out=1 (secs since Epoch) - ok
out=2 (secs since Epoch) - ok
out=4 (secs since Epoch) - ok
out=8 (secs since Epoch) - ok
out=16 (secs since Epoch) - ok
out=32 (secs since Epoch) - ok
out=64 (secs since Epoch) - ok
out=128 (secs since Epoch) - ok
out=256 (secs since Epoch) - ok
out=512 (secs since Epoch) - ok
out=1024 (secs since Epoch) - ok
out=2048 (secs since Epoch) - ok
out=4096 (secs since Epoch) - ok
out=8192 (secs since Epoch) - ok
out=16384 (secs since Epoch) - ok
out=32768 (secs since Epoch) - ok
out=65536 (secs since Epoch) - ok
out=131072 (secs since Epoch) - ok
out=262144 (secs since Epoch) - ok
out=524288 (secs since Epoch) - ok
out=1048576 (secs since Epoch) - ok
out=2097152 (secs since Epoch) - ok
out=4194304 (secs since Epoch) - ok
out=8388608 (secs since Epoch) - ok
out=16777216 (secs since Epoch) - ok
out=33554432 (secs since Epoch) - ok
out=67108864 (secs since Epoch) - ok
out=134217728 (secs since Epoch) - ok
out=268435456 (secs since Epoch) - ok
out=536870912 (secs since Epoch) - ok
out=1073741824 (secs since Epoch) - ok
# functests/test_walkone.sh summary: 31 succeeded, 0 failed
# End functests/test_walkone.sh - OK

# Test Suites summary: 4 succeeded, 0 failed
# End Test Suites - OK

Running the test program with no faked time specified
$ LD_PRELOAD=../src/libfaketime.so.1 ./timetest
pthread_cond_timedwait: CLOCK_REALTIME test
(Intentionally sleeping 1 second...)
pthread_cond_timedwait: CLOCK_MONOTONIC test
(Intentionally sleeping 1 second..., see docs about CLOCK_MONOTONIC test)
^Cmake[1]: *** [Makefile:19: test] Interrupt
make: *** [Makefile:11: test] Interrupt

[130] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source
$ cd test/
[0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source/test
$ gdb ./timetest
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64le-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./timetest...
(gdb) set debug-file-directory /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug
(gdb) add-auto-load-safe-path /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libthread_db-1.0.so
(gdb) set environment LD_PRELOAD=../src/libfaketime.so.1
(gdb) set environment FAKETIME=-10d
(gdb) set environment NO_FAKE_STAT=1
(gdb) set startup-with-shell off
(gdb) run
Starting program: /tmp/guix-build-libfaketime-0.9.9.drv-0/source/test/timetest
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libthread_db.so.1".
[New Thread 0x7ffff7aaf0f0 (LWP 2140545)]
pthread_cond_timedwait: CLOCK_REALTIME test
(Intentionally sleeping 1 second...)
pthread_cond_timedwait: CLOCK_MONOTONIC test
(Intentionally sleeping 1 second..., see docs about CLOCK_MONOTONIC test)
^C
Thread 1 "timetest" received signal SIGINT, Interrupt.
0x00007ffff7eccba0 in __futex_abstimed_wait_common64 (futex_word=0x7ffff7aaf1c0, expected=<optimized out>, clockid=<optimized out>, abstime=0x0, private=<optimized out>, cancel=<optimized out>) at ../sysdeps/nptl/futex-internal.c:74
74 ../sysdeps/nptl/futex-internal.c: No such file or directory.
(gdb) backtrace
#0 0x00007ffff7eccba0 in __futex_abstimed_wait_common64 (futex_word=0x7ffff7aaf1c0, expected=<optimized out>, clockid=<optimized out>, abstime=0x0, private=<optimized out>, cancel=<optimized out>) at ../sysdeps/nptl/futex-internal.c:74
#1 0x00007ffff7eb9934 in __pthread_clockjoin_ex (threadid=140737348563184, thread_return=0x7fffffffe2d0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:102
#2 0x00007ffff7eb9684 in __pthread_join (threadid=<optimized out>, thread_return=<optimized out>) at pthread_join.c:24
#3 0x0000000010001784 in main (argc=1, argv=0x7fffffffe718) at timetest.c:146
(gdb) backtrace -full
#0 0x00007ffff7eccba0 in __futex_abstimed_wait_common64 (futex_word=0x7ffff7aaf1c0, expected=<optimized out>, clockid=<optimized out>, abstime=0x0, private=<optimized out>, cancel=<optimized out>) at ../sysdeps/nptl/futex-internal.c:74
r4 = 265
r7 = 0
_arg5 = 0
_arg2 = <optimized out>
r5 = 2140545
r8 = 4294967295
_arg6 = 4294967295
_arg3 = <optimized out>
r0 = 221
r3 = -512
r6 = 0
_arg4 = <optimized out>
_arg1 = <optimized out>
sc_cancel_oldtype = 0
sc_ret = <optimized out>
clockbit = <optimized out>
err = <optimized out>
op = <optimized out>
#1 0x00007ffff7eb9934 in __pthread_clockjoin_ex (threadid=140737348563184, thread_return=0x7fffffffe2d0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:102
ret = <optimized out>
_buffer = {__routine = 0x7ffff7eb97d0 <cleanup>, __arg = 0x7ffff7aaf518, __canceltype = -6000, __prev = 0x0}
tid = <optimized out>
pd = 0x7ffff7aaf0f0
self = <optimized out>
result = 0
pd_result = <optimized out>
#2 0x00007ffff7eb9684 in __pthread_join (threadid=<optimized out>, thread_return=<optimized out>) at pthread_join.c:24
No locals.
#3 0x0000000010001784 in main (argc=1, argv=0x7fffffffe718) at timetest.c:146
now = 140737488347536
tb = {time = 140737354082104, millitm = 1, timezone = 0, dstflag = 0}
tv = {tv_sec = 140737354081200, tv_usec = 1}
ts = {tv_sec = 140737354092312, tv_nsec = 0}
timerid1 = 0x0
timerid2 = 0x7ffff7f313ca
sev = {sigev_value = {sival_int = -134273224, sival_ptr = 0x7ffff7ff2738}, sigev_signo = -1358151624, sigev_notify = 0, _sigev_un = {_pad = {-7632, 32767, 1140867716, 32767, -134571396, 32767, -134251008, 32767, -7888, 32767,
-135299328, 32767}, _tid = -7632, _sigev_thread = {_function = 0x7fffffffe230, _attribute = 0x7fff44004284}}}
its = {it_interval = {tv_sec = 140737488347536, tv_nsec = 140737353288760}, it_value = {tv_sec = 140737488347512, tv_nsec = 7737577984389116719}}
mask = {__val = {4294967297, 140737488347472, 1, 0, 1, 140737354081200, 140737488347648, 0, 384, 140737353252608, 140737350926336, 140737350298984, 140737354086848, 0, 4294967295, 7883960601630828079}}
sa = {__sigaction_handler = {sa_handler = 0x31325f6d68735f65, sa_sigaction = 0x31325f6d68735f65}, sa_mask = {__val = {215624265780, 9, 0, 140737354076688, 0, 0, 0, 0, 0, 0, 1392, 140737353287368, 140737353293872,
140737353482696, 140737353288760, 140737353481312}}, sa_flags = -134274128, sa_restorer = 0x7fffffffe2b0}
buf = {st_dev = 140733797368452, st_ino = 140737353809984, st_nlink = 140737354104320, st_mode = 4294959792, st_uid = 32767, st_gid = 4294959992, __pad2 = 32767, st_rdev = 268633376, st_size = 0, st_blksize = 0,
st_blocks = 140737354076688, st_atim = {tv_sec = 140737488347824, tv_nsec = 140737488348952}, st_mtim = {tv_sec = 1, tv_nsec = 8}, st_ctim = {tv_sec = 0, tv_nsec = 140737352442432}, __glibc_reserved4 = 140737488347904,
__glibc_reserved5 = 8, __glibc_reserved6 = 268442956}
thread = 140737348563184
ret = 0x7fffffffe300
timer_getoverrun_timerid1 = -7816
timer_getoverrun_timerid2 = 32767
(gdb)

I'll forward this information to upstream and ask if they need more.
I'll also let them know which version of the libraries (e.g., glibc) are
being used, since they said it might help to know.

--
Chris
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmD6W0YVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkaddo0P/1DiEtdNUywcLEnkKkAbfct+mqem
q5xNmxqKGzGJIISlyQp2WoeWp9CL2XzeyEg4IrN3FvEP+2RPA8LYA4bD4LmE9/u1
6WSx1VRszBpfqTwKjQlp2Uyz6YxNkPG/dQsTz8mKEPVpeEk4WJL13QATbjrpKwdt
WDq583gNyn9naZqJ1HtPhw3d4oEnFaIcLfi4KwGkiPCsLI2XVZAwttkdRQoEU5nw
tvONCqzFMY8rVslrqwXHITH804jwip/sMMrLFcbvE2/nxTr/YhX7CHJ93BuPEfgk
hCyi1T/foxiNXpFhjtjGa3dRTvW3IW/QExlG4WYSrE1bQ8gjWHTJgqb1aiY22ftY
g8YavwUC+3C0Dqij5D9Z5nJVXR726S7QjuBC/4XhHNDkF8BmyhOQPQw7OeqHAAbO
u31DALHaIdbLs0RUcWAHXW9BxVdEKqa2/dxn+KTlG4uCbf5zYuMlsckMLPsveZfm
fnNv4avOF/sda1kcKWs0/1Co5Sq4O4bHIE+qBu9NZQLLFSzlQSxWuJmi2dHCQp+x
JRNUlz9L8qS6VVMaerbiz5JSR3yeZmqsAm4JJ82aFEwJeaK/nAKG6/1VRhcx7npP
LCsHI2dSJAbkLbV4Jui8Vwuz+61HUaepnrUxSlY5qrN3jwkHvWMFlPHTRY9P708F
2IpPqoGqRWpYUAIF
=js9c
-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 48941@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 48941
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch