Illegal instruction in json.rb after upgrade to 15.2.0-ce

Summary

After upgrading to version 15.2.0-ce, GitLab is inaccessible, reporting that "GitLab is taking too much time to respond" (502). According to the logs, this is caused by an illegal instruction in /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/json.rb:97.

Steps to reproduce

Upgrade an Omnibus installation on Debian 11 to version 15.2.0-ce and try to access the login page.

What is the current bug behavior?

HTTP error 502: "Whoops, GitLab is taking too much time to respond."

What is the expected correct behavior?

Login page loads normally.

Relevant logs and/or screenshots

==> /var/log/gitlab/sidekiq/current <==
{"severity":"INFO","time":"2022-07-23T20:02:44.643Z","message":"GitLab reliable fetch activated!"}
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/json.rb:97: [BUG] Illegal instruction at 0x00007fd6f4ed45e9
ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-linux]

Results of GitLab environment info

Expand for output related to GitLab environment info
System information
System:		Debian 11
Current User:	git
Using RVM:	no
Ruby Version:	2.7.5p203
Gem Version:	3.1.4
Bundler Version:2.3.15
Rake Version:	13.0.6
Redis Version:	6.2.7
Sidekiq Version:6.4.0
Go Version:	unknown

GitLab information
Version:	15.2.0
Revision:	a876afc5fd8
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	13.6
URL:		https://HOST_REDACTED
HTTP Clone URL:	https://HOST_REDACTED/some-group/some-project.git
SSH Clone URL:	git@HOST_REDACTED:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers: 

GitLab Shell
Version:	14.9.0
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell

lscpu outout

Expand for lscpu output
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   36 bits physical, 48 bits virtual
CPU(s):                          2
On-line CPU(s) list:             0,1
Thread(s) per core:              1
Core(s) per socket:              2
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           23
Model name:                      Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
Stepping:                        10
CPU MHz:                         3007.719
CPU max MHz:                     3003.0000
CPU min MHz:                     2003.0000
BogoMIPS:                        6015.43
Virtualization:                  VT-x
L1d cache:                       64 KiB
L1i cache:                       64 KiB
L2 cache:                        6 MiB
NUMA node0 CPU(s):               0,1
Vulnerability Itlb multihit:     KVM: Mitigation: VMX disabled
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX EPT disabled
Vulnerability Mds:               Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Mmio stale data:   Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Retpolines, STIBP disabled, RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nop
                                 l cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm

Workaround

See #368656 (comment 1038092684).

Edited by Stan Hu