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

C

CRCinAU

Renowned Member
May 4, 2020
145
38
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:
You must log in or register to reply here.
Top Bottom