Crashes after upgrading to GMP 6.20+

[Michael Maroszek]

Hi Torbjörn,

sorry for the version confusion. I meant 6.2.0 and 6.2.1.

I am compiling using GitHub Actions which are running on Azure (
https://docs.microsoft.com/de-de/azure/virtual-machines/dv2-dsv2-series#dsv2-series)
which is using Broadwell. Therefore the configure output is correct to
assume Broadwell.

As far as I have properly understood, the --enable-fat option should allow
GMP to also work flawlessly on the Celeron i mentioned by selecting the
appropriate optimization during runtime.

But it does not, it quits with a SIGILL.

Thread 11 "foo" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fffe37fe700 (LWP 9609)]
0x00005555571661db in __gmpn_set_str ()
(gdb)

Here is a more complete stacktrace:
#0  0x00005555571661db in __gmpn_set_str ()
#1  0x000055555715d90f in __gmpz_set_str ()
#2  0x0000555556e24c6c in convert_to_gmp (gmpnumber=0x7fffe2060c08,
val=<optimized out>, base=<optimized out>)
    at /home/php-7.3.0/ext/gmp/gmp.c:748
#3  0x0000555556e26ff6 in zif_gmp_init (execute_data=<optimized out>,
return_value=0x7fffe201c800)
    at /home/php-7.3.0/ext/gmp/gmp.c:1056
#4  0x000055555712b3c7 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at
/home/php-7.3.0/Zend/zend_vm_execute.h:690
#5  execute_ex (ex=0x7fffcc25cd50) at
/home/php-7.3.0/Zend/zend_vm_execute.h:55418
#6  0x0000555557130a30 in zend_execute (op_array=op_array at entry=0x7fffe2070000,
return_value=0x0, return_value at entry=0x7fffecd616a0)
    at /home/php-7.3.0/Zend/zend_vm_execute.h:60834
#7  0x000055555709e364 in zend_execute_scripts (type=type at entry=8,
retval=0x7fffecd616a0, retval at entry=0x0, file_count=-503200000,
    file_count at entry=3) at /home/php-7.3.0/Zend/zend.c:1568
#8  0x000055555703266e in php_execute_script (primary_file=0x7fffe3ffd490)
at /home/php-7.3.0/main/main.c:2630

Does that help?

The code works flawlessly on the Boardwell architecture (and a lot more!).
The issue arises only on the mentioned Celeron.

Michael

Am Di., 27. Apr. 2021 um 10:19 Uhr schrieb Torbjörn Granlund <tg at gmplib.org
>:

> Michael Maroszek <paresy at gmail.com> writes:
>
>   i am using an unpatched gmplib version and the problem was introduced
> with
>   version 6.20 (still exists in 6.21). Reverting to 6.1.2 solves the
> problem.
>
> There are no GMP versions 6.20 or 6.21.  Are these PHP releases, perhaps?
>
>   The problem does not happen on all systems. Only a few users are
> affected,
>   which use a specific NAS (and therefore CPU). Our app is running inside a
>   docker container and there seems to be at least one related bug report on
>   GitHub: https://github.com/home-assistant/core/issues/44538
>
>   The affected CPU is: Intel Celeron J3455
>
> A CPU model GMP knows of.  GMP matches it as goldmont.
>
>   Unfortunately i don't have a full example app yet. It happens when using
>   the GMP functions in PHP. If definitely required I would do the work and
>   create a plain c app, but as far as i have seen the crash directly
> happens
>   when using the gmp functions. (The crash always happens - it seems like
> the
>   "fat" code doesn't detect the target system properly and uses an invalid
>   optimization)
>
> These are guesses.  I strongly suggest that you debug it.
>
> Also, "crash" is is unnecessarily vague.
>
>   #0    Object "/usr/bin/foo", at 0x55e4ff7368d9, in __gmpz_set_str
>
>   2021-04-01T12:29:38.2070642Z checking build system type...
>   broadwell-pc-linux-gnu
>
> If it is matched as broadwell-pc-linux-gnu, somebody is lying.  That's
> hardly what the cpuid instruction on a J3455 returns.
>
> --
> Torbjörn
> Please encrypt, key id 0xC8601622
>