) at cifframe.m:196#4 0x00007ffff7055cf4 in -[GSFFIInvocation initWithMethodSignature:] (self=0x1002ac1c0, _cmd=<optimized out>,
, _cmd=<optimized out>) at NSRunLoop.m:759#9 0x00007ffff6aa41e8 in ?? () from
On 9/26/21 14:54, John Paul Adrian Glaubitz wrote:
Did you verify that downgrading the libffi package fixes the problem?
If yes, you may file an upstream bug here [1]. The powerpc-related changes I can
see at first glance are these [2].
My guess would be this change:
https://github.com/libffi/libffi/commit/4d6d2866ae43e55325e8ee96561221804602cd7a
I upgraded my iMac G5 to latest debian, including kernel 5.14 !
The good thing is that the new kernel boots and X11 comes up.
The bad news is lots of applications crash and they all have one thing in common, libffi.
So e.g. a build of ArcticFox fails:
multix@PPC970FX:~/code/Arctic-Fox$ ./mach build
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
Illegal instruction
[1] https://github.com/libffi/libffi
[2] https://github.com/libffi/libffi/search?o=desc&q=powerpc&s=author-date&type=commits
Hello!
On 9/26/21 14:36, Riccardo Mottola wrote:
I upgraded my iMac G5 to latest debian, including kernel 5.14 !
The good thing is that the new kernel boots and X11 comes up.
The bad news is lots of applications crash and they all have one
thing in
common, libffi.
So e.g. a build of ArcticFox fails:
multix@PPC970FX:~/code/Arctic-Fox$ ./mach build
/usr/bin/which: this version of `which' is deprecated; use `command
-v' in
scripts instead.
Illegal instruction
Did you verify that downgrading the libffi package fixes the problem?
That's a bit a similar issue with building libffi locally. In /usr/local
I am unsure it would be picked up. I can of course still do it and perhaps have GNUstep pick it up and do some tests there.
In the meanwhile, I'm setting up to configure and build libffi locally.
On 9/26/21 15:39, Riccardo Mottola wrote:
That's a bit a similar issue with building libffi locally. In
/usr/local
I am unsure it would be picked up. I can of course still do it and
perhaps
have GNUstep pick it up and do some tests there.
In the meanwhile, I'm setting up to configure and build libffi
locally.
You can build libffi locally and then make your application make use
of it
by setting LD_LIBRARY_PATH=/path/to/local/libffi so that your
application
picks it up from there, e.g.
$ LD_LIBRARY_PATH=/home/user/libffi/ python2.7
Would you like me to build the latest "release" of libffi ?
No I cannot, 3.4.2 (cleaned, reconfigured, installed) seems to work fine out of the box.
So either the release is not well tagged, or there is an issue with the Debian package.
On 9/26/21 19:31, Riccardo Mottola wrote:
Would you like me to build the latest "release" of libffi ?
Yes, please test the 3.4.2 release by checking out the "v3.4.2" tag:
$ git checkout v3.4.2
If you can reproduce the issue then, please start bisecting with:
No I cannot, 3.4.2 (cleaned, reconfigured, installed) seems to work fine out of the box.You could try rebuilding the libffi Debian package locally and see if that makes any
So either the release is not well tagged, or there is an issue with the Debian package.
difference. I'll check the build logs whether the package might have been built
with the compiler option "-mnative".
</body></html>
Hi,
I upgraded my iMac G5 to latest debian, including kernel 5.14 !
The good thing is that the new kernel boots and X11 comes up.
The bad news is lots of applications crash and they all have one thing
in common, libffi.
So e.g. a build of ArcticFox fails:
multix@PPC970FX:~/code/Arctic-Fox$ ./mach build
/usr/bin/which: this version of `which' is deprecated; use `command
-v' in scripts instead.
Illegal instruction
dmesg shows:
[18439.269485] python2.7[4993]: illegal instruction (4) at
7fffabff42fc nip 7fffabff42fc lr 7fffabff42ec code 1 in libffi.so.8.1.0[7fffabff0000+10000]
[18439.269547] python2.7[4993]: code: 60420000 3d205858 60000000
61295858 38800000 387e03c8 f9228590 4bffe119
[18439.269555] python2.7[4993]: code: e8410028 60000000 7fe3fb78
392285b8 <7c004eee> 60000000 39228950 7c004fae
GNUMail fails to start up:
Program received signal SIGILL, Illegal instruction.
0x00007ffff5d08970 in ?? () from
/usr/lib/powerpc64-linux-gnu/libffi.so.8
(gdb) bt
#0 0x00007ffff5d08970 in ?? () from
/usr/lib/powerpc64-linux-gnu/libffi.so.8
#1 0x00007ffff5d07f90 in ?? () from
/usr/lib/powerpc64-linux-gnu/libffi.so.8
#2 0x00007ffff5d02d10 in ?? () from
/usr/lib/powerpc64-linux-gnu/libffi.so.8
#3 0x00007ffff6d02be0 in cifframe_from_signature (info=<optimized
) at cifframe.m:196#4 0x00007ffff7055cf4 in -[GSFFIInvocation initWithMethodSignature:] (self=0x1002ac1c0, _cmd=<optimized out>,
aSignature=0x1002a8180) at GSFFIInvocation.m:299
#5 0x00007ffff6e8b130 in +[NSInvocation
invocationWithMethodSignature:] (self=<optimized out>,
_cmd=<optimized out>, _signature=0x1002a8180) at NSInvocation.m:332
#6 0x00007ffff6f5cf68 in +[NSRunLoop _runLoopForThread:]
(self=<optimized out>, _cmd=<optimized out>,
aThread=<optimized out>) at NSRunLoop.m:790
#7 0x00007ffff6f5a160 in +[NSRunLoop currentRunLoop]
(self=0x7ffff7328568 <_OBJC_Class_NSRunLoop>,
_cmd=<optimized out>) at NSRunLoop.m:827
#8 0x00007ffff6f5b4cc in +[NSRunLoop initialize] (self=<optimized
, _cmd=<optimized out>) at NSRunLoop.m:759#9 0x00007ffff6aa41e8 in ?? () from /usr/lib/powerpc64-linux-gnu/libobjc.so.4
#10 0x00007ffff6aa4368 in ?? () from /usr/lib/powerpc64-linux-gnu/libobjc.so.4
#11 0x00007ffff6aa4830 in ?? () from /usr/lib/powerpc64-linux-gnu/libobjc.so.4
#12 0x00007ffff24a4680 in -[XGServer(EventOps) setupRunLoopInputSourcesForMode:] (self=0x1003ec3d0,
I guess not a coincidence!
Riccardo
--
Sent with GNUMail from GNUstep on a Raspberry PI 4.
i too am having problems with libffi8 on a powermac g5
# dmesg
...
[ 16.257543] fail2ban-server[384]: illegal instruction (4) at
3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in libffi.so.8.1.0[3fffb427b000+c000]
...
# ls -l libffi*
-rw-r--r-- 1 root root 68696 Feb 20 2021 libffi.so.7.1.0
-rw-r--r-- 1 root root 68720 Sep 24 00:00 libffi.so.8.1.0
i went back to 7.1.0 and there are no more messages about illegal instructions
While out to a walk, I had the same idea.. I wasn't sure it would work
but "ldd" confirms that the local version of the library is picked up.
Thus I got latest git of libffi from the repository you usggested. Configured and built without any additional parameter.
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
And things works. Python does not crash and GNUstep works, as I am typing this right mail from my iMac.
yes please check that - I will access this computer only next weekend,
so for now no test, I only have my laptop with me, but 32bit might not
be affected.
after ./autogen.sh && ./configure && make i then copied the new libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to /usr/lib/powerpc64-linux-gnu and that solved it. no more illegal
instruction messages
Hello!
On 9/28/21 10:33, Cameron MacPherson wrote:
after ./autogen.sh && ./configure && make i then copied the new libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to /usr/lib/powerpc64-linux-gnu and that solved it. no more illegal instruction messages
Did you verify that it is actually using the proper version?
You need to make sure 100% that this version fixes it while the libffi.so.8.1.0 from the Debian package causes the crash.
Also, can you check whether passing "--disable-exec-static-tramp"
makes a difference?
We need to find out why the Debian package causes SIGILL and we
still don't know why. It gets particularly strange when the issue
cannot be reproduced with the upstream source.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
</div><div>september 28th is the one i just compiled replacing the one contained in the libff8 package. i dont know the standard way of verifying which library is being used.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><divdir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 1:40 AM John Paul Adrian Glaubitz <<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;
Hello!
On 9/28/21 06:18, Cameron MacPherson wrote:
i too am having problems with libffi8 on a powermac g5
# dmesg
...
[ 16.257543] fail2ban-server[384]: illegal instruction (4) at 3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in libffi.so.8.1.0[3fffb427b000+c000]
...
# ls -l libffi*
-rw-r--r-- 1 root root 68696 Feb 20 2021 libffi.so.7.1.0
-rw-r--r-- 1 root root 68720 Sep 24 00:00 libffi.so.8.1.0
i went back to 7.1.0 and there are no more messages about illegal instructions
Could you please help debugging this? I'm currently not at home and
don't have access to my Powerbook G4.
Please try building libffi from git as I'm still a bit skeptical that
Ricardo built the upstream version properly. I don't see any reason
why the regression shouldn't be a result of an upstream change but in
the Debian package as the Debian package doesn't do anything special.
$ apt build-dep libffi
$ git clone https://github.com/libffi/libffi.git
$ cd libffi
$ ./autogen.sh && ./configure && make
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
i ran apt install --reinstall libffi8, restarted the system and the
following messages reappeared
[ 16.874069] fail2ban-server[384]: illegal instruction (4) at
3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90 code 1 in libffi.so.8.1.0[3fff7ef8d000+c000]
[ 16.874154] fail2ban-server[384]: code: b1090008 f9490000 4e800020 00000000 00000000 00000000 60000000 60420000
[ 16.874176] fail2ban-server[384]: code: 81230000 712a0008 41820018 39230004 <7c004eee> 39230020 7c004fae 4bfffaf4
after rm -rf ~/libffi, git clone, autogen, this time i ran ./configure with --disable-exec-static-tramp and then copied the new libffi.so.8 to /usr/lib/powerpc64-linux-gnu/ once again restarted the system and no more messages on the console or in the logs about libfffi
september 28th is the one i just compiled replacing the one contained in
the libff8 package. i dont know the standard way of verifying which
library is being used.
i recompiled everything with gcc-10 and there is no change vs gcc version 11
after running the commands you listed i repeated my process with the new libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them work.
i am using gcc 11.2.0-7
Hi Cameron!
On 9/28/21 10:59, Cameron MacPherson wrote:
i ran apt install --reinstall libffi8, restarted the system and the following messages reappeared
[ 16.874069] fail2ban-server[384]: illegal instruction (4) at 3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90 code 1 in libffi.so.8.1.0[3fff7ef8d000+c000]
[ 16.874154] fail2ban-server[384]: code: b1090008 f9490000 4e800020 00000000 00000000 00000000 60000000 60420000
[ 16.874176] fail2ban-server[384]: code: 81230000 712a0008 41820018 39230004 <7c004eee> 39230020 7c004fae 4bfffaf4
after rm -rf ~/libffi, git clone, autogen, this time i ran ./configurewith
--disable-exec-static-tramp and then copied the new libffi.so.8 to /usr/lib/powerpc64-linux-gnu/ once again restarted the system and no more messages on the console or in the logs about libfffi
OK, this sounds like a good verification. Thanks for testing this for me.
Can you make another check and try the v3.4.2 upstream tag?
$ make clean
$ git clean -df
$ git checkout v3.4.2
$ ./autogen.sh && ./configure && make
and try again? Maybe the issue was fixed between v3.4.2 and HEAD.
september 28th is the one i just compiled replacing the one contained in the libff8 package. i dont know the standard way of verifying which library is being used.
You can verify the library being using with the `ldd` command.
For example:
$ ldd `which python2.7`
So, my next guess is that there is something wrong with the Debian source package. Maybe it's actually not version 3.4.2 that is being used.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 9/28/21 11:22, Cameron MacPherson wrote:
after running the commands you listed i repeated my process with the new libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of themwork.
i am using gcc 11.2.0-7
Ah, the compiler is a good point.
Try building with gcc-10 instead by setting CC=gcc-10 after installing
the gcc-10 package.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
after building and installing it locally using your commands (i had to add --no-sign to dpkg-buildpackage) it works. no illegal instructions
Hi Cameron!
On 9/28/21 11:38, Cameron MacPherson wrote:
i recompiled everything with gcc-10 and there is no change vs gccversion 11
As a last test, can you try rebuilding the Debian package locally and test that?
$ apt-get install devscripts
$ dget -u https://deb.debian.org/debian/pool/main/libf/libffi/libffi_3.4.2-2.dsc
$ apt-get build-dep libffi
$ cd libffi-3.4.2
$ dpkg-buildpackage -B
Then just install the package with "dpkg -i libffi_3.4.2-2_powerpc.deb"
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Cameron!<br>
after building and installing it locally using your commands (i had to add >> --no-sign to dpkg-buildpackage) it works. no illegal instructions
Well, that's becoming intesting now. I'm going to have the packages rebuilt on the buildds now.
On Sep 28, 2021, at 3:14 PM, Riccardo Mottola <riccardo.mottola@libero.it> wrote:
Hello Adrian
John Paul Adrian Glaubitz wrote:
$ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb
$ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb
For ppc64:
$ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb
$ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb
I can only try on G4 now (and eventually later on G3). However, the
packages mentioned to not exist anymore, did you move them or uploaded
them elsewhere?
http://incoming.ports.debian.org/buildd/packages/sid/main/
</div></blockquote><br><div>It’s been moved:</div><div><br></div><div>> <a href="http://incoming.ports.debian.org/buildd/packages/sid/main/">http://incoming.ports.debian.org/buildd/packages/sid/main/</a></div><div><br></div><div>Adrian</div></body></html>
$ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb
$ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb
For ppc64:
$ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb
$ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb
It’s been moved:
http://incoming.ports.debian.org/buildd/packages/sid/main/
On 9/28/21 12:58, John Paul Adrian Glaubitz wrote:> On 9/28/21 12:55,
Cameron MacPherson wrote:
addafter building and installing it locally using your commands (i had to
--no-sign to dpkg-buildpackage) it works. no illegal instructions
Well, that's becoming intesting now. I'm going to have the packagesrebuilt
on the buildds now.
Can you try whether this package works?
$ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb
$ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb
For ppc64:
$ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb
$ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb
Although the ppc64 version was built on the same buildd as the same problematic
version while the powerpc version was now built on another buildd.
So, if the problem is fixed on powerpc now, but persists on ppc64, we might have a culprit.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
OK. I'm regenerating the chroots on the build servers now and then
trigger another rebuild of the package. If that still doesn't help,
we know there is some runtime detection which enables these instructions during build and I have to start looking into the source code.
http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi8_3.4.2-1_powerpc.deb
http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi8_3.4.2-1_ppc64.deb
http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi-dev_3.4.2-1_powerpc.deb
http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi-dev_3.4.2-1_ppc64.deb
I did this on my PowerBook G4 .
I had some issues with build-dep - it doesn't like my deb-src in the
sources file:
apt-get build-dep libffi
Reading package lists... Done
E: You must put some 'deb-src' URIs in your sources.list
I have:
deb-src http://deb.debian.org/debian unstable main
deb-src http://deb.debian.org/debian experimental main
do we have our own for "ports" ? anyway, I solved dependencies manually.
OK. I'm regenerating the chroots on the build servers now and then
trigger another rebuild of the package. If that still doesn't help,
we know there is some runtime detection which enables these instructions during build and I have to start looking into the source code.
On Tue, Sep 28, 2021 at 09:34:23PM +0200, John Paul Adrian Glaubitz wrote:
OK. I'm regenerating the chroots on the build servers now and then
trigger another rebuild of the package. If that still doesn't help,
we know there is some runtime detection which enables these instructions during build and I have to start looking into the source code.
Would this be a problem:
powerpc*)
cputype=`((grep cpu /proc/cpuinfo | head -n 1 | cut -d: -f2 | cut -d, -f1 | $SED 's/ //g') ; /usr/bin/machine ; /bin/machine; grep CPU /var/run/dmesg.boot | head -n 1 | cut -d" " -f2) 2> /dev/null`
cputype=`echo $cputype | $SED -e 's/ppc//g;s/ *//g'`
case $cputype in
*750*) ax_gcc_arch="750 G3" ;;
*740[[0-9]]*) ax_gcc_arch="$cputype 7400 G4" ;;
*74[[4-5]][[0-9]]*) ax_gcc_arch="$cputype 7450 G4" ;;
*74[[0-9]][[0-9]]*) ax_gcc_arch="$cputype G4" ;;
*970*) ax_gcc_arch="970 G5 power4";;
*POWER4*|*power4*|*gq*) ax_gcc_arch="power4 970";;
*POWER5*|*power5*|*gr*|*gs*) ax_gcc_arch="power5 power4 970";;
603ev|8240) ax_gcc_arch="$cputype 603e 603";;
*POWER7*) ax_gcc_arch="power7";;
*POWER8*) ax_gcc_arch="power8";;
*POWER9*) ax_gcc_arch="power9";;
*POWER10*) ax_gcc_arch="power10";;
*) ax_gcc_arch=$cputype ;;
esac
ax_gcc_arch="$ax_gcc_arch powerpc"
;;
I saw that in m4/ax_gcc_archflag.m4
I guess related would be this configure option:
--with-gcc-arch=<arch> use architecture <arch> for gcc -march/-mtune,
instead of guessing
Yes. And this is not acceptable because they are manipulating the baseline.
Thanks for catching this. This is our bug!
Hi!
On 9/28/21 21:34, John Paul Adrian Glaubitz wrote:
OK. I'm regenerating the chroots on the build servers now and then
trigger another rebuild of the package. If that still doesn't help,
we know there is some runtime detection which enables these instructions during build and I have to start looking into the source code.
In the meantime, could you please perform another experiment and check whether
the libffi_3.4.2-1 package is affected as well?
You can fetch it from here:
powerpc:
http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi8_3.4.2-1_powerpc.deb
ppc64:
http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi8_3.4.2-1_ppc64.deb
The -dev packages can be found here if necessary:
powerpc:
http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi-dev_3.4.2-1_powerpc.deb
ppc64:
http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi-dev_3.4.2-1_ppc64.deb
If these package work, we know it's a bug with the build environment (compiler, binutils etc).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Yes. And this is not acceptable because they are manipulating the baseline.
i can confirm that the ppc64 snapshot packages work without illegal instructions
https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=powerpc&ver=3.4.2-1&stamp=1626443428&raw=0
https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=powerpc&ver=3.4.2-2&stamp=1632868252&raw=0
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 87:35:59 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,163 |