Re: Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
Hi Adrian On Wed, 16 Feb 2022 at 13:36, John Paul Adrian Glaubitz wrote: > On 2/16/22 12:33, Christian Kastner wrote: > >> Bus errors are normally easy to spot. Just run the code in question through > >> GDB and see where it crashes. Then look at the backtrace with the debug > >> symbols installed. > >> > >> Usually it's a result of bad pointer arithmetics which should definitely be > >> fixed as such operations usually violate the C/C++ standards. > >> > >> I can have quick look. > > > > one of these errors has been reported in the past, and I already did > > some analysis way back then: > > > > https://github.com/scikit-learn/scikit-learn/issues/16443 > > > > Check the last comment. The relevant Cython code doesn't look wrong, so > > I guess the problem is with the binary result produced during build, as > > you point out. > > I'm happy to look at this issue but first the baseline issue must be fixed > as this is a Debian Policy violation. It was pointed out by Gard Spreemann [1], but I notice now that debian-arm was not in CC: > it seems superficially plausible that the march=native > invocations are just instances of the compiler being probed. I have also had a look and cannot see that '-march=native' is used in the actual builds on any of the architectures. It would be very much appreciated if the arm porters could take a look at this issue, as it still plagues the scikit-learn autopkgtests on armhf [2], and currently prevents quite a number of packages from being part of testing. It appears that armel [1] has the same error, so hopefully one fix could resolve both. Regards Graham [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003165#86 [2] https://ci.debian.net/packages/s/scikit-learn/testing/armhf/ [3] https://ci.debian.net/packages/s/scikit-learn/testing/armel/
Re: Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
Hi, On 2022-02-16 11:57, John Paul Adrian Glaubitz wrote: > Hello! > > On 2/16/22 11:36, Graham Inggs wrote: >> Is anyone able to help with the bus error on armhf please? > > Bus errors are normally easy to spot. Just run the code in question through > GDB and see where it crashes. Then look at the backtrace with the debug > symbols installed. > > Usually it's a result of bad pointer arithmetics which should definitely be > fixed as such operations usually violate the C/C++ standards. > > I can have quick look. one of these errors has been reported in the past, and I already did some analysis way back then: https://github.com/scikit-learn/scikit-learn/issues/16443 Check the last comment. The relevant Cython code doesn't look wrong, so I guess the problem is with the binary result produced during build, as you point out. Best, Christian
Re: Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
Hi Christian! On 2/16/22 12:33, Christian Kastner wrote: >> Bus errors are normally easy to spot. Just run the code in question through >> GDB and see where it crashes. Then look at the backtrace with the debug >> symbols installed. >> >> Usually it's a result of bad pointer arithmetics which should definitely be >> fixed as such operations usually violate the C/C++ standards. >> >> I can have quick look. > > one of these errors has been reported in the past, and I already did > some analysis way back then: > > https://github.com/scikit-learn/scikit-learn/issues/16443 > > Check the last comment. The relevant Cython code doesn't look wrong, so > I guess the problem is with the binary result produced during build, as > you point out. I'm happy to look at this issue but first the baseline issue must be fixed as this is a Debian Policy violation. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
