Re: Signal 4 (ILL) caught by ps in mock

[Christoph Junghans]

On Mon, Feb 17, 2020 at 3:45 AM Dan Horák  wrote:
>
> On Mon, 17 Feb 2020 11:26:30 +0100
> Petr Pisar  wrote:
>
> > On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote:
> > > On Fri, Feb 14, 2020 at 10:37 AM Dan Horák  wrote:
> > > >
> > > > On Fri, 14 Feb 2020 10:28:10 -0700
> > > > Christoph Junghans  wrote:
> > > >
> > > > > >>
> > > > > >> In your case procps-ng package seems to be miscompiled (or
> > > > > >> run on an incopatible hardware). I recommend getting a shell
> > > > > >> in the mock enviroment (mock --shell) and investigeting
> > > > > >> whether the ps program works there).
> > > > > >
> > > > > > Ok, I will try that and report back.
> > > > > It is indeed broken in shell as well:
> > > > >  sh-5.0# ps
> > > > >
> > > > > Signal 4 (ILL) caught by ps (3.3.15).
> > > > > /usr/bin/ps:ps/display.c:66: please report this bug
> > > > > Segmentation fault (core dumped)
> > > >
> > > > works (no crash) on my Power9 system, but it could be a P9
> > > > instruction sneaked into the binary and crashing on Power8
> > > > systems. I'll take a look, but if you could file a bug (with me
> > > > in CC), it would be helpful.
> > > just to make sure, I am running this in mock on the following
> > > system: $ cat /proc/cpuinfo
> > > processor : 0
> > > vendor_id : GenuineIntel
> > > cpu family : 6
> > > model : 142
> > > model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
> >
> > Then you actually run the PowerPC ps binary in QEMU emulator. Could
> > you show the /proc/cpuinfo from inside of the mock environment?
>
> first I suggest to use the latest qemu from the virt-preview repo [1]
> and if it still SIGILLs, then report a bugu against qemu. I don't see
> any problem with "ps" on (real) Power8 or Power9 hw, so most likely it's
> an emulation bug.
Updating qemu-common to 2:4.2.0-4 fixed the issue.

Christoph
>
> [1]
> https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview/
>
>
>
> Dan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Signal 4 (ILL) caught by ps in mock

[Christoph Junghans]

On Mon, Feb 17, 2020 at 3:27 AM Petr Pisar  wrote:
>
> On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote:
> > On Fri, Feb 14, 2020 at 10:37 AM Dan Horák  wrote:
> > >
> > > On Fri, 14 Feb 2020 10:28:10 -0700
> > > Christoph Junghans  wrote:
> > >
> > > > >>
> > > > >> In your case procps-ng package seems to be miscompiled (or run on
> > > > >> an incopatible hardware). I recommend getting a shell in the mock
> > > > >> enviroment (mock --shell) and investigeting whether the ps program
> > > > >> works there).
> > > > >
> > > > > Ok, I will try that and report back.
> > > > It is indeed broken in shell as well:
> > > >  sh-5.0# ps
> > > >
> > > > Signal 4 (ILL) caught by ps (3.3.15).
> > > > /usr/bin/ps:ps/display.c:66: please report this bug
> > > > Segmentation fault (core dumped)
> > >
> > > works (no crash) on my Power9 system, but it could be a P9 instruction
> > > sneaked into the binary and crashing on Power8 systems. I'll take a
> > > look, but if you could file a bug (with me in CC), it would be helpful.
> > just to make sure, I am running this in mock on the following system:
> > $ cat /proc/cpuinfo
> > processor : 0
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 142
> > model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
>
> Then you actually run the PowerPC ps binary in QEMU emulator. Could you show
> the /proc/cpuinfo from inside of the mock environment?
It is the same inside mock!
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Signal 4 (ILL) caught by ps in mock

[Dan Horák]

On Mon, 17 Feb 2020 11:26:30 +0100
Petr Pisar  wrote:

> On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote:
> > On Fri, Feb 14, 2020 at 10:37 AM Dan Horák  wrote:
> > >
> > > On Fri, 14 Feb 2020 10:28:10 -0700
> > > Christoph Junghans  wrote:
> > >
> > > > >>
> > > > >> In your case procps-ng package seems to be miscompiled (or
> > > > >> run on an incopatible hardware). I recommend getting a shell
> > > > >> in the mock enviroment (mock --shell) and investigeting
> > > > >> whether the ps program works there).
> > > > >
> > > > > Ok, I will try that and report back.
> > > > It is indeed broken in shell as well:
> > > >  sh-5.0# ps
> > > >
> > > > Signal 4 (ILL) caught by ps (3.3.15).
> > > > /usr/bin/ps:ps/display.c:66: please report this bug
> > > > Segmentation fault (core dumped)
> > >
> > > works (no crash) on my Power9 system, but it could be a P9
> > > instruction sneaked into the binary and crashing on Power8
> > > systems. I'll take a look, but if you could file a bug (with me
> > > in CC), it would be helpful.
> > just to make sure, I am running this in mock on the following
> > system: $ cat /proc/cpuinfo
> > processor : 0
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 142
> > model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
> 
> Then you actually run the PowerPC ps binary in QEMU emulator. Could
> you show the /proc/cpuinfo from inside of the mock environment?

first I suggest to use the latest qemu from the virt-preview repo [1]
and if it still SIGILLs, then report a bugu against qemu. I don't see
any problem with "ps" on (real) Power8 or Power9 hw, so most likely it's
an emulation bug.

[1]
https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview/



Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Signal 4 (ILL) caught by ps in mock

[Petr Pisar]

On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote:
> On Fri, Feb 14, 2020 at 10:37 AM Dan Horák  wrote:
> >
> > On Fri, 14 Feb 2020 10:28:10 -0700
> > Christoph Junghans  wrote:
> >
> > > >>
> > > >> In your case procps-ng package seems to be miscompiled (or run on
> > > >> an incopatible hardware). I recommend getting a shell in the mock
> > > >> enviroment (mock --shell) and investigeting whether the ps program
> > > >> works there).
> > > >
> > > > Ok, I will try that and report back.
> > > It is indeed broken in shell as well:
> > >  sh-5.0# ps
> > >
> > > Signal 4 (ILL) caught by ps (3.3.15).
> > > /usr/bin/ps:ps/display.c:66: please report this bug
> > > Segmentation fault (core dumped)
> >
> > works (no crash) on my Power9 system, but it could be a P9 instruction
> > sneaked into the binary and crashing on Power8 systems. I'll take a
> > look, but if you could file a bug (with me in CC), it would be helpful.
> just to make sure, I am running this in mock on the following system:
> $ cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 142
> model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz

Then you actually run the PowerPC ps binary in QEMU emulator. Could you show
the /proc/cpuinfo from inside of the mock environment?

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Signal 4 (ILL) caught by ps in mock

[Christoph Junghans]

On Fri, Feb 14, 2020 at 10:37 AM Dan Horák  wrote:
>
> On Fri, 14 Feb 2020 10:28:10 -0700
> Christoph Junghans  wrote:
>
> > >>
> > >> In your case procps-ng package seems to be miscompiled (or run on
> > >> an incopatible hardware). I recommend getting a shell in the mock
> > >> enviroment (mock --shell) and investigeting whether the ps program
> > >> works there).
> > >
> > > Ok, I will try that and report back.
> > It is indeed broken in shell as well:
> >  sh-5.0# ps
> >
> > Signal 4 (ILL) caught by ps (3.3.15).
> > /usr/bin/ps:ps/display.c:66: please report this bug
> > Segmentation fault (core dumped)
>
> works (no crash) on my Power9 system, but it could be a P9 instruction
> sneaked into the binary and crashing on Power8 systems. I'll take a
> look, but if you could file a bug (with me in CC), it would be helpful.
just to make sure, I am running this in mock on the following system:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
stepping : 9
cpu MHz : 3504.000
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm
constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq
pni pclmulqdq monitor ssse3 cx16 pcid sse4_1 sse4_2 movbe popcnt aes
xsave avx rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single
pti fsgsbase avx2 invpcid rdseed clflushopt md_clear flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
swapgs itlb_multihit
bogomips : 7008.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

Christoph
>
>
> Dan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Signal 4 (ILL) caught by ps in mock

[Dan Horák]

On Fri, 14 Feb 2020 10:28:10 -0700
Christoph Junghans  wrote:

> >>
> >> In your case procps-ng package seems to be miscompiled (or run on
> >> an incopatible hardware). I recommend getting a shell in the mock
> >> enviroment (mock --shell) and investigeting whether the ps program
> >> works there).
> >
> > Ok, I will try that and report back.
> It is indeed broken in shell as well:
>  sh-5.0# ps
> 
> Signal 4 (ILL) caught by ps (3.3.15).
> /usr/bin/ps:ps/display.c:66: please report this bug
> Segmentation fault (core dumped)

works (no crash) on my Power9 system, but it could be a P9 instruction
sneaked into the binary and crashing on Power8 systems. I'll take a
look, but if you could file a bug (with me in CC), it would be helpful.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Signal 4 (ILL) caught by ps in mock

[Christoph Junghans]

On Fri, Feb 14, 2020 at 6:38 AM Christoph Junghans 
wrote:
>
>
>
> On Fri, Feb 14, 2020, 00:16 Petr Pisar  wrote:
>>
>> On Thu, Feb 13, 2020 at 07:48:22PM -0700, Christoph Junghans wrote:
>> > when running "mock -r fedora-rawhide-ppc64le --no-clean
>> > gromacs-2019.5-2.fc32.1.src.rpm"
>> > I am getting the following error:
>> > Signal 4 (ILL) caught by ps (3.3.15).
>> > /usr/bin/ps:ps/display.c:66: please report this bug
>> >
>> > I tried a couple of different src.rpm with the same result.
>> > This is mock 1.4.21 on f31.
>> >
>> > Has anybody else seen this?
>> >
>> Not exactly, but if you check Koji build history for gromacs package
>> . You
will
>> find out that the build failed during F32 mass rebuild
>>  on
ppc64le and
>> aarch64. The ppc64le failure is:
>
> That was exactly the reason why I was looking into building this ppc64le
;-) But unfortunately the Signal 4 shows up before it even gets to the
CMake part.
>
>>
>> -- Performing Test CXX_mvsx_COMPILE_WORKS - Failed
>> -- Flag was accepted, but it did not build test source (this could be
due to either the compiler or binutils)
>> -- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED
>> -- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED - Success
>> -- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS
>> -- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS - Failed
>> -- Flag was accepted, but it did not build test source (this could be
due to either the compiler or binutils)
>> -- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED
>> -- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED - Failed
>> -- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS
>> -- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS - Failed
>> -- Could not find any flag to build test source (this could be due to
either the compiler or binutils)
>> CMake Error at cmake/gmxManageSimd.cmake:51 (message):
>>   Cannot find IBM VSX compiler flag.  Use a newer compiler, or disable
SIMD
>>   support (slower).
>> Call Stack (most recent call first):
>>   cmake/gmxManageSimd.cmake:265
(gmx_give_fatal_error_when_simd_support_not_found)
>>   CMakeLists.txt:719 (gmx_manage_simd)
>> -- Configuring incomplete, errors occurred!
>> See also
"/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeOutput.log".
>> See also
"/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeError.log".
>>
>> Koschei history 
claims the
>> build started to fail with these changes
>> . It's probably a
triggered by
>> an upgrade of GCC to 10 version.
>>
>> SIGILL means the processor met an instruction it does not understand.
>>
>> In your case procps-ng package seems to be miscompiled (or run on an
>> incopatible hardware). I recommend getting a shell in the mock enviroment
>> (mock --shell) and investigeting whether the ps program works there).
>
> Ok, I will try that and report back.
It is indeed broken in shell as well:
 sh-5.0# ps

Signal 4 (ILL) caught by ps (3.3.15).
/usr/bin/ps:ps/display.c:66: please report this bug
Segmentation fault (core dumped)


>
>>
>> My gut feeling is that GCC 10 started to omit new instructions and your
>> hardware is not compatible with them. Can you reproduce it on one of
these
>> machines
>> <
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
>?
>
> Using these machines might be the easiest way the track down the gromacs
issue, thanks for the reminder that we have these resources.
>
> Christoph
>
>>
>> -- Petr
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Signal 4 (ILL) caught by ps in mock

[Christoph Junghans]

On Fri, Feb 14, 2020, 00:16 Petr Pisar  wrote:

> On Thu, Feb 13, 2020 at 07:48:22PM -0700, Christoph Junghans wrote:
> > when running "mock -r fedora-rawhide-ppc64le --no-clean
> > gromacs-2019.5-2.fc32.1.src.rpm"
> > I am getting the following error:
> > Signal 4 (ILL) caught by ps (3.3.15).
> > /usr/bin/ps:ps/display.c:66: please report this bug
> >
> > I tried a couple of different src.rpm with the same result.
> > This is mock 1.4.21 on f31.
> >
> > Has anybody else seen this?
> >
> Not exactly, but if you check Koji build history for gromacs package
> . You will
> find out that the build failed during F32 mass rebuild
>  on ppc64le
> and
> aarch64. The ppc64le failure is:
>
That was exactly the reason why I was looking into building this ppc64le
;-) But unfortunately the Signal 4 shows up before it even gets to the
CMake part.


> -- Performing Test CXX_mvsx_COMPILE_WORKS - Failed
> -- Flag was accepted, but it did not build test source (this could be due
> to either the compiler or binutils)
> -- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED
> -- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED - Success
> -- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS
> -- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS - Failed
> -- Flag was accepted, but it did not build test source (this could be due
> to either the compiler or binutils)
> -- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED
> -- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED - Failed
> -- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS
> -- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS - Failed
> -- Could not find any flag to build test source (this could be due to
> either the compiler or binutils)
> CMake Error at cmake/gmxManageSimd.cmake:51 (message):
>   Cannot find IBM VSX compiler flag.  Use a newer compiler, or disable SIMD
>   support (slower).
> Call Stack (most recent call first):
>   cmake/gmxManageSimd.cmake:265
> (gmx_give_fatal_error_when_simd_support_not_found)
>   CMakeLists.txt:719 (gmx_manage_simd)
> -- Configuring incomplete, errors occurred!
> See also
> "/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeOutput.log".
> See also
> "/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeError.log".
>
> Koschei history 
> claims the
> build started to fail with these changes
> . It's probably a
> triggered by
> an upgrade of GCC to 10 version.
>
> SIGILL means the processor met an instruction it does not understand.
>
> In your case procps-ng package seems to be miscompiled (or run on an
> incopatible hardware). I recommend getting a shell in the mock enviroment
> (mock --shell) and investigeting whether the ps program works there).
>
Ok, I will try that and report back.


> My gut feeling is that GCC 10 started to omit new instructions and your
> hardware is not compatible with them. Can you reproduce it on one of these
> machines
> <
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> >?

Using these machines might be the easiest way the track down the gromacs
issue, thanks for the reminder that we have these resources.

Christoph


> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Signal 4 (ILL) caught by ps in mock

[Petr Pisar]

On Thu, Feb 13, 2020 at 07:48:22PM -0700, Christoph Junghans wrote:
> when running "mock -r fedora-rawhide-ppc64le --no-clean
> gromacs-2019.5-2.fc32.1.src.rpm"
> I am getting the following error:
> Signal 4 (ILL) caught by ps (3.3.15).
> /usr/bin/ps:ps/display.c:66: please report this bug
> 
> I tried a couple of different src.rpm with the same result.
> This is mock 1.4.21 on f31.
> 
> Has anybody else seen this?
> 
Not exactly, but if you check Koji build history for gromacs package
. You will
find out that the build failed during F32 mass rebuild
 on ppc64le and
aarch64. The ppc64le failure is:

-- Performing Test CXX_mvsx_COMPILE_WORKS - Failed
-- Flag was accepted, but it did not build test source (this could be due to 
either the compiler or binutils)
-- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED
-- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED - Success
-- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS
-- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS - Failed
-- Flag was accepted, but it did not build test source (this could be due to 
either the compiler or binutils)
-- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED
-- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED - Failed
-- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS
-- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS - Failed
-- Could not find any flag to build test source (this could be due to either 
the compiler or binutils)
CMake Error at cmake/gmxManageSimd.cmake:51 (message):
  Cannot find IBM VSX compiler flag.  Use a newer compiler, or disable SIMD
  support (slower).
Call Stack (most recent call first):
  cmake/gmxManageSimd.cmake:265 
(gmx_give_fatal_error_when_simd_support_not_found)
  CMakeLists.txt:719 (gmx_manage_simd)
-- Configuring incomplete, errors occurred!
See also 
"/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeOutput.log".
See also 
"/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeError.log".

Koschei history  claims the
build started to fail with these changes
. It's probably a triggered by
an upgrade of GCC to 10 version.

SIGILL means the processor met an instruction it does not understand.

In your case procps-ng package seems to be miscompiled (or run on an
incopatible hardware). I recommend getting a shell in the mock enviroment
(mock --shell) and investigeting whether the ps program works there).

My gut feeling is that GCC 10 started to omit new instructions and your
hardware is not compatible with them. Can you reproduce it on one of these
machines
?

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org