Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Michael Tokarev]

14.07.2023 16:18, Ben Hutchings wrote:
..

I use QEMU to test klibc changes on as many architectures as possible.
For a long time I used QEMU 3.1 with some cherry-picked bug fixes.
All the GNU-built binaries would run successfully on that, but Clang-
built binaries for some architectures did not.

Switching klibc to the time64 kernel API forced me to update to QEMU
7.2.  This introduced regressions for shared-library executables for
armhf and riscv64.


that's definitely not good. The problem here seems to be that apparently
no one knows about these problems, so no one can fix them either.

For the very least, - since I know very little about actual emulation
internals myself, - maybe there's a way to bisect things?  Some simple
reproducer for the segfault, which don't use 64bit time_t so can run
on qemu 3.1 and 7.2?

Ben, I'd really love to have the bugs fixed. But I need some of your
knowledge for that too ;)

Thanks!

/mjt

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Ben Hutchings]

On Thu, 2023-07-13 at 22:27 +, Thorsten Glaser wrote:
> retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
> thanks
> 
> venkata.p...@toshiba-tsip.com dixit:
> 
> > Follow below steps to reproduce this issue
> > ```
> > $ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ 
> > http://deb.debian.org/debian/
> > $ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
> > $ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> > Segmentation fault
> > ```
> 
> Same when just copying klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so out
> of libklibc_2.0.12-1_armhf.deb into /lib/ and extracting fstype
> from klibc-utils_2.0.12-1_armhf.deb… however it works both on a
> real-metal ARM box (amdahl.d.o) and a statically(!) linked mksh
> against klibc :/
> 
> My guess here is that it’s, as usual, the fault of qemu-user,
> which has multiple outstanding emulation bugs, some of which
> affecting klibc-built binaries especially, though this, since
> a statically linked mksh works, is probably an issue with how
> qemu-user handles .interp *shrug*
[...]

I use QEMU to test klibc changes on as many architectures as possible.
For a long time I used QEMU 3.1 with some cherry-picked bug fixes.  
All the GNU-built binaries would run successfully on that, but Clang-
built binaries for some architectures did not.

Switching klibc to the time64 kernel API forced me to update to QEMU
7.2.  This introduced regressions for shared-library executables for
armhf and riscv64.

There is some more detail on this at


Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.



signature.asc
Description: This is a digitally signed message part

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Helge Deller]

Can you check if this patch fixes the problem:
https://patchew.org/QEMU/mvmpm55qnno@suse.de/
(linux-user: make sure brk(0) returns a page-aligned value,   from Andreas 
Schwab)
 Ursprüngliche Nachricht Von: Thorsten Glaser  
Datum: 14.07.23  00:48  (GMT+01:00) An: venkata.p...@toshiba-tsip.com, 
1040...@bugs.debian.org, pkg-qemu-de...@lists.alioth.debian.org Cc: 
dinesh.ku...@toshiba-tsip.com Betreff: Bug#1040981: klibc-utils: Segmentation 
fault while executin klibc binaries in armhf architecture under qemu-user 
retitle 1040981 klibc-utils: segfault executing armhf binaries under 
qemu-userthanksvenkata.p...@toshiba-tsip.com dixit:>Follow below steps to 
reproduce this issue>```>$ sudo debootstrap --arch=arm bookworm 
arm-bookworm-rootfs/ http://deb.debian.org/debian/>$ sudo chroot arm-bookworm/ 
apt-update && apt install -y klibc-utils>$ sudo chroot arm-bookworm/ 
/usr/lib/klibc/bin/fstype --help>qemu: uncaught target signal 11 (Segmentation 
fault) - core dumped>Segmentation fault>```Same when just copying 
klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so outof libklibc_2.0.12-1_armhf.deb into 
/lib/ and extracting fstypefrom klibc-utils_2.0.12-1_armhf.deb… however it 
works both on areal-metal ARM box (amdahl.d.o) and a statically(!) linked 
mkshagainst klibc :/My guess here is that it’s, as usual, the fault of 
qemu-user,which has multiple outstanding emulation bugs, some of whichaffecting 
klibc-built binaries especially, though this, sincea statically linked mksh 
works, is probably an issue with howqemu-user handles .interp *shrug*Since your 
one-stage debootstrap succeeds, can you not do theremaining steps booting into 
the image-under-preparation andrun them there? Here, qemu-system-armhf should 
probably suffice.I know, it’s just as a workaround, until the people in 
questionfigure out why this happens.bye,//mirabilos-- Solange man keine 
schmutzigen Tricks macht, und ich meine *wirklich*schmutzige Tricks, wie bei 
einer doppelt verketteten Liste beidePointer XORen und in nur einem Word 
speichern, funktioniert Boehm ganzhervorragend.   -- Andreas Bogk über 
boehm-gc in d.a.s.r

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Thorsten Glaser]

retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
thanks

venkata.p...@toshiba-tsip.com dixit:

>Follow below steps to reproduce this issue
>```
>$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ 
>http://deb.debian.org/debian/
>$ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
>$ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
>qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>Segmentation fault
>```

Same when just copying klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so out
of libklibc_2.0.12-1_armhf.deb into /lib/ and extracting fstype
from klibc-utils_2.0.12-1_armhf.deb… however it works both on a
real-metal ARM box (amdahl.d.o) and a statically(!) linked mksh
against klibc :/

My guess here is that it’s, as usual, the fault of qemu-user,
which has multiple outstanding emulation bugs, some of which
affecting klibc-built binaries especially, though this, since
a statically linked mksh works, is probably an issue with how
qemu-user handles .interp *shrug*

Since your one-stage debootstrap succeeds, can you not do the
remaining steps booting into the image-under-preparation and
run them there? Here, qemu-system-armhf should probably suffice.
I know, it’s just as a workaround, until the people in question
figure out why this happens.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r