proxmox-backup-client-static - Floating point exception (core dumped)

C

CRCinAU

Renowned Member
May 4, 2020
162
43
68
crc.id.au
I've tried extracting the proxmox-backup-client-static deb and copying the files to a Fedora 42 machine.

A number of functions seem to fail with an error of "Floating point exception (core dumped)".

ie:

Code: 
[root@<$hostname> bin]# proxmox-backup-client task list
Floating point exception (core dumped)
[root@<$hostname> bin]# proxmox-backup-client list
Floating point exception (core dumped)
[root@<$hostname> bin]# proxmox-backup-client backup root.pxar:/ --ns <$hostname>
Starting backup: [<$hostname>]:host/<$hostname>/2025-06-23T04:38:27Z  
Client name: <$hostname>  
Starting backup protocol: Mon Jun 23 14:38:27 2025  
Floating point exception (core dumped)
[root@<$hostname> bin]# proxmox-backup-client benchmark
Floating point exception (core dumped)
[root@<$hostname> bin]# proxmox-backup-client list
Floating point exception (core dumped)
[root@<$hostname> bin]#

dmesg shows the following traps:
Code: 
[116029.270334] traps: tokio-runtime-w[87560] trap divide error ip:7f167b34c57f sp:7f167b5f98a0 error:0 in libc.so.6[14357f,7f167b209000+16f000]
[116066.515026] traps: tokio-runtime-w[87605] trap divide error ip:7fbd7f54c57f sp:7fbd7f7f98a0 error:0 in libc.so.6[14357f,7fbd7f409000+16f000]
[116127.089960] traps: tokio-runtime-w[87727] trap divide error ip:7fde4bd4d57f sp:7fde4bffa8a0 error:0 in libc.so.6[14357f,7fde4bc0a000+16f000]
[116166.918228] traps: tokio-runtime-w[87780] trap divide error ip:7f6442b4d57f sp:7f6442dfa8a0 error:0 in libc.so.6[14357f,7f6442a0a000+16f000]
[116274.926874] traps: tokio-runtime-w[87958] trap divide error ip:7f980fd4d57f sp:7f980fffa8a0 error:0 in libc.so.6[14357f,7f980fc0a000+16f000]
[116289.910031] traps: tokio-runtime-w[87982] trap divide error ip:7f800254c57f sp:7f80027f98a0 error:0 in libc.so.6[14357f,7f8002409000+16f000]
[116294.747996] traps: tokio-runtime-w[88004] trap divide error ip:7f526934c57f sp:7f52695f98a0 error:0 in libc.so.6[14357f,7f5269209000+16f000]
[116335.564178] traps: tokio-runtime-w[88047] trap divide error ip:7fc7f3b4f57f sp:7fc7f3dfc8a0 error:0 in libc.so.6[14357f,7fc7f3a0c000+16f000]
[116342.757441] traps: tokio-runtime-w[88069] trap divide error ip:7fd57214d57f sp:7fd5723fa8a0 error:0 in libc.so.6[14357f,7fd57200a000+16f000]
[116354.175668] traps: tokio-runtime-w[88091] trap divide error ip:7f7740d4d57f sp:7f7740ffa8a0 error:0 in libc.so.6[14357f,7f7740c0a000+16f000]
[116440.153182] traps: tokio-runtime-w[88163] trap divide error ip:7ff6e274c57f sp:7ff6e29f98a0 error:0 in libc.so.6[14357f,7ff6e2609000+16f000]
[116447.030530] traps: tokio-runtime-w[88193] trap divide error ip:7f7012d4d57f sp:7f7012ffa8a0 error:0 in libc.so.6[14357f,7f7012c0a000+16f000]
[116456.950714] traps: tokio-runtime-w[88215] trap divide error ip:7f3dcb94c57f sp:7f3dcbbf98a0 error:0 in libc.so.6[14357f,7f3dcb809000+16f000]

Is this expected to work?

EDIT: It seems if I unset the env variables PBS_REPOSITORY and PBS_PASSWORD, then some commands no longer crash - but that defeats the purpose of them...
 
Last edited:
Thanks - happy to test a static binary of `proxmox-backup-client` and `pxar` if you can provide one somewhere as a result of that patch.
 
I can't reproduce this in a Fedora 42 container using the 3.4.2-1 binary from the pbs-client repository.. anything special or noteworthy about your setup?
 
CRCinAU said:
EDIT: It seems if I unset the env variables PBS_REPOSITORY and PBS_PASSWORD, then some commands no longer crash - but that defeats the purpose of them...
Click to expand...

do you mean by that that if you provide the repository using `--repository` and the password interactively or by some other non-env means, it works? that would point fairly directly to the environment handling code
 
fabian said:
I can't reproduce this in a Fedora 42 container using the 3.4.2-1 binary from the pbs-client repository.. anything special or noteworthy about your setup?
Click to expand...

Interesting.

Would kernel version matter?

Code: 
$ cat /proc/version
Linux version 6.15.2-200.fc42.x86_64 (mockbuild@68257c1a2c9d417aaa957cc59746e9d9) (gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2), GNU ld version 2.44-3.fc42) #1 SMP PREEMPT_DYNAMIC Tue Jun 10 15:17:23 UTC 2025

Just about to update to 6.15.3 from: https://koji.fedoraproject.org/koji/buildinfo?buildID=2734591

It's an embedded board with an Intel N100 CPU - so not a full-fat CPU...
 
I'll retry using a VM to make sure
 
fabian said:
do you mean by that that if you provide the repository using `--repository` and the password interactively or by some other non-env means, it works? that would point fairly directly to the environment handling code
Click to expand...

Hmmmm - stupid question - when I provide the repository via --repository and not the env, it gives me an error:

Code: 
Error: error building client for repository <repository> - API token secret must be provided!

I can't seem to figure out a way to get the client to prompt for this secret. Setting PBS_PASSWORD still causes a core dump.
 
ah, for tokens that is indeed the only way. but it works for me with a token as well in the container, so that's probably not it.
 
Gotcha - I just tried with the `root@pam` account, that did prompt for a password - but that still core dumped.

EDIT: I did try to send you a DM with the full datastore, repository and namespace strings to not have them archived online forever, but seems I'm not allowed to send DMs to you :)

I was wondering if a . in the namespace could also be an issue - but testing again with no namespace and the root@pam user still resulted in a core dump (with no env set)

EDIT 2: Seems like no difference in running kernel 6.15.3
 
Last edited:
Last edited:
ah, that is only on our internal staging repository so far. I can reproduce it now (with either version, in a VM and CT) - it triggers as soon as the client attempts DNS resolution. you can probably work around it by specifying the IP instead for now (at least that works for all my test instances).
 
  • Like
Reactions: CRCinAU
Yep - I can confirm that using the IP address instead of fqdn seems to function. I'm wondering if the FQDN is being resolved as an IPv6 address and is somehow confusing the : in the resulting repository string?

However, I tried both IPv4 and IPv6 addresses - enclosing the IPv6 address in square brackets, and both seemed to work with no crash.
 
Last edited:
no, the issue is that DNS resolution using glibc and static linking are a bad match. we implemented an internal DNS resolution feature for that reason, but the build bug that the patch I linked fixes means that that is currently not in effect. the patch does fix the issue, I'll see about getting a fixed static package uploaded.
 
  • Like
Reactions: CRCinAU
No rush - I've been experimenting with PBS over the weekend, and this is the first non-pve host that I'm playing with.

I'm guessing most people haven't hit this yet - and its really not critical for me, so it certainly isn't a breaking thing for me (and I guess nobody else as I couldn't find any other bug report on this).
 
You must log in or register to reply here.
Top Bottom