Doxygen uses popen to run filters. Is there an issue with using popen
to run perl scripts on the buildds for m68k and sh4?
The reason I ask is that I found this report in BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974004
which seems to be a similar issue.
Popen will fork and exec the perl script as:
/bin/sh -c "./perlscript.pl arg"
where ./perlscript.pl is a text file with a #!/usr/bin/perl shebang.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974004
Hi!
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974004
Normally, since qemu v6.0.0 you can preserve argv[0]:
(...)
You need also kernel v5.12:
On 4/27/22 11:04, Laurent Vivier wrote:
Normally, since qemu v6.0.0 you can preserve argv[0]:
(...)
You need also kernel v5.12:
OK, I'm installing QEMU 6.2 and kernel 5.16 from backports on all QEMU buildds now. Let's see if that helps.
[1] https://github.com/zatrazz/glibc/tree/azanella/redir-refactor
Hi!
On 4/27/22 11:19, John Paul Adrian Glaubitz wrote:
On 4/27/22 11:04, Laurent Vivier wrote:
Normally, since qemu v6.0.0 you can preserve argv[0]:
(...)
You need also kernel v5.12:
OK, I'm installing QEMU 6.2 and kernel 5.16 from backports on all QEMU
buildds now. Let's see if that helps.
Tested with QEMU 7.0 and glibc patches from [1], still fails.
Need to keep digging.
Adrian
[1] https://github.com/zatrazz/glibc/tree/azanella/redir-refactor
Did you configure binfmt_misc to preserve argv0 [2] ?
$ cat /proc/sys/fs/binfmt_misc/qemu-m68k
enabled
interpreter //qemu-m68k
flags: POC
offset 0
magic 7f454c4601020100000000000000000000020004
mask fffffffffffffe00fffffffffffffffffffeffff
No, the 'F' means 'fix-binary':
The interpreter is loaded in memory once when the binfmt_misc is configured (when
the configuration is written to /proc/sys/fs/binfmt_misc/register) from the host
filesystem. So you don't need to put it in the chroot.
Hi Laurent!
The issue can be reproduced on a freshly installed Debian system.
Is the problem the additional "F" flag?
glaubitz@z6:/tmp/test> cat /proc/sys/fs/binfmt_misc/qemu-m68k
enabled
interpreter /usr/libexec/qemu-binfmt/m68k-binfmt-P
flags: POCF
offset 0
magic 7f454c4601020100000000000000000000020004
mask ffffffffffffff00fffffffffffffffffffeffff
glaubitz@z6:/tmp/test>
Adrian
Hi!
On 5/12/22 18:10, Laurent Vivier wrote:
The flags are correct.
This can be tested with:
$ sudo chroot m68k-chroot sh -c 'echo $0'
sh
if the argument is not properly managed, you would have "/usr/bin/sh".
OK, this is working properly:
root@z6:/srv/chroot> chroot unstable-m68k-sbuild/ sh -c 'echo $0'
sh
root@z6:/srv/chroot>
I guess it's related to the glibc issue then [1].
Adrian
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
On 5/12/22 17:45, Laurent Vivier wrote:
No, the 'F' means 'fix-binary':
The interpreter is loaded in memory once when the binfmt_misc is configured (when
the configuration is written to /proc/sys/fs/binfmt_misc/register) from the host
filesystem. So you don't need to put it in the chroot.
So, the flags are correct then? Is there any way to properly test the argument issue?
Adrian
The flags are correct.
This can be tested with:
$ sudo chroot m68k-chroot sh -c 'echo $0'
sh
if the argument is not properly managed, you would have "/usr/bin/sh".
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
I guess it's related to the glibc issue then [1].
You can try by mounting your chroot on a non ext4 partition. It works well with btrfs.
Ext4 stores a hash in a field that is normally an index, so a 64bit (host kernel long) hash cannot be passed to the 32bit guest.
btrfs uses it as a real index, so it will overflow only with 2³² entries.
Le 12/05/2022 à 17:51, John Paul Adrian Glaubitz a écrit :
On 5/12/22 17:45, Laurent Vivier wrote:
No, the 'F' means 'fix-binary':
The interpreter is loaded in memory once when the binfmt_misc is configured (when
the configuration is written to
/proc/sys/fs/binfmt_misc/register) from the host
filesystem. So you don't need to put it in the chroot.
So, the flags are correct then? Is there any way to properly test
the argument issue?
Adrian
The flags are correct.
This can be tested with:
$ sudo chroot m68k-chroot sh -c 'echo $0'
sh
if the argument is not properly managed, you would have
"/usr/bin/sh".
Thanks,
Laurent
I have noticed that in addition to m68k and sh4, the builds also fail
in the same way on the hppa host known as pasta, but when given back
and run on a different hppa host they succeed.
E.g.
https://buildd.debian.org/status/logs.php?pkg=globus-common&arch=hppa
One failure on pasta - give back succeded on pacific
https://buildd.debian.org/status/logs.php?pkg=globus-gass-transfer&arch=hppa Two failures on pasta - third attempt on physik succeeded
Is this related?
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
Hi Matthias!
On 5/16/22 10:24, Mattias Ellert wrote:
I have noticed that in addition to m68k and sh4, the builds also fail
in the same way on the hppa host known as pasta, but when given back
and run on a different hppa host they succeed.
E.g.
https://buildd.debian.org/status/logs.php?pkg=globus-common&arch=hppa
One failure on pasta - give back succeded on pacific
https://buildd.debian.org/status/logs.php?pkg=globus-gass-transfer&arch=hppa >> Two failures on pasta - third attempt on physik succeeded
Is this related?
pasta is using a similar setup like m68k and sh4.
The underlying bug is an issue with glibc and ext4 [1] and can be resolved
by switching the buildroot to btrfs. I have verified that this fixes the issue.
QEMU's sh4 system emulation only has 64 megs ram, but you can add as much swap
space as you like and the compiler's been happy with it so far. (Even when it gets a little thrashy, it stays in the host's page cache so it's all memory-to-memory copying. I have a todo item to map some more memory into the virtual board and kernel, but both sides involve a lot of digging.) The m68k board I'm using has 256 megs ram, that's generally enough for a -j1 build. (Or
even -j3 with distcc calling out to the cross compiler running on the host's loopback instead of running in the emulator.) I haven't tried to get an hppa system working yet because musl doesn't support it.
Hi Matthias!
On 5/16/22 10:24, Mattias Ellert wrote:
I have noticed that in addition to m68k and sh4, the builds also
fail
in the same way on the hppa host known as pasta, but when given
back
and run on a different hppa host they succeed.
E.g.
https://buildd.debian.org/status/logs.php?pkg=globus-common&arch=hppa
One failure on pasta - give back succeded on pacific
https://buildd.debian.org/status/logs.php?pkg=globus-gass-transfer&arch=hppa
Two failures on pasta - third attempt on physik succeeded
Is this related?
pasta is using a similar setup like m68k and sh4.
The underlying bug is an issue with glibc and ext4 [1] and can be
resolved
by switching the buildroot to btrfs. I have verified that this fixes
the
issue.
I will do that later this week when I find the time.
Adrian
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
On May 23, 2022, at 9:43 AM, Mattias Ellert <mattias.ellert@physics.uu.se> wrote:
mån 2022-05-16 klockan 10:28 +0200 skrev John Paul Adrian Glaubitz:
Hi Matthias!
On 5/16/22 10:24, Mattias Ellert wrote:
I have noticed that in addition to m68k and sh4, the builds also
fail
in the same way on the hppa host known as pasta, but when given
back
and run on a different hppa host they succeed.
E.g.
https://buildd.debian.org/status/logs.php?pkg=globus-common&arch=hppa
One failure on pasta - give back succeded on pacific
https://buildd.debian.org/status/logs.php?pkg=globus-gass-transfer&arch=hppa
Two failures on pasta - third attempt on physik succeeded
Is this related?
pasta is using a similar setup like m68k and sh4.
The underlying bug is an issue with glibc and ext4 [1] and can be
resolved
by switching the buildroot to btrfs. I have verified that this fixes
the
issue.
I will do that later this week when I find the time.
Adrian
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
Was this implemented?
Mainly I'm asking if there is any point in clicking the give-back link
on the builds that failed with the old set-up.
Hi Matthias!
On May 23, 2022, at 9:43 AM, Mattias Ellert
<mattias.ellert@physics.uu.se> wrote:
mån 2022-05-16 klockan 10:28 +0200 skrev John Paul Adrian
Glaubitz:
Hi Matthias!
On 5/16/22 10:24, Mattias Ellert wrote:
I have noticed that in addition to m68k and sh4, the builds
also
fail
in the same way on the hppa host known as pasta, but when given
back
and run on a different hppa host they succeed.
E.g. https://buildd.debian.org/status/logs.php?pkg=globus-common&arch=hppa One failure on pasta - give back succeded on pacific
https://buildd.debian.org/status/logs.php?pkg=globus-gass-transfer&arch=hppa
Two failures on pasta - third attempt on physik succeeded
Is this related?
pasta is using a similar setup like m68k and sh4.
The underlying bug is an issue with glibc and ext4 [1] and can be resolved
by switching the buildroot to btrfs. I have verified that this
fixes
the
issue.
I will do that later this week when I find the time.
Adrian
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
Was this implemented?
Mainly I'm asking if there is any point in clicking the give-back
link
on the builds that failed with the old set-up.
Sorry, not yet, I had a busy week.
I’ll try to get it done this week and will let you know.
Adrian
Any news?Was this implemented?
Mainly I'm asking if there is any point in clicking the give-back
link
on the builds that failed with the old set-up.
Sorry, not yet, I had a busy week.
I’ll try to get it done this week and will let you know.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 37:54:24 |
| Calls: | 6,648 |
| Files: | 12,193 |
| Messages: | 5,329,235 |