Ungültigen Maschinenbefehl rausfinden

[Marco Moock]

Hallo zusammen!

Ich habe nen Intel(R) Celeron(R) J4125 und wenn ich den TS3-Client
starte und verbinde, stürzt die Software ab und ich bekomme die
Meldung, dass es ein ungültiger Maschinenbefehl sei.

Die Architektur 8amd64) passt. Ich vermute, dass die so kompiliert
haben, dass Befehlssätze genutzt werden, die mein Prozessor nicht hat.
Da würde ich gerne mehr drüber rausfinden und wissen, welcher Befehl da
genutzt wird und welchen Befehlssatz ich dafür bräuchte, ggf. um das
dem TS-Support mitzuteilen.

Die CPU ist von 2019, daher kommt mir das schon komisch vor.

2023-07-15 17:26:13.389396|INFO |ClientUI |1 |Initiating connection: 217.160.67.148:9987
Breakpad crash /home/m/.ts3client/crashdumps/b041356d-d0f1-4cb7-2800e3af-ac35585c.dmp
Starting Error Reporter: /home/m/Downloads/TeamSpeak3-Client-linux_amd64/error_report
[{WIFSIGNALED(s) && WTERMSIG(s) == SIGILL}], 0, NULL) = 11925
rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f4af6477510}, {sa_handler=0x565279b740b0, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f4af6477510}, 8) = 0
ioctl(2, TIOCGWINSZ, {ws_row=60, ws_col=202, ws_xpixel=1216, ws_ypixel=784}) = 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2996, ...}, AT_EMPTY_PATH) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2996
read(3, "", 4096) = 0
close(3) = 0
openat(AT_FDCWD, "/usr/share/locale/de_DE.UTF-8/LC_MESSAGES/bash.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de_DE.utf8/LC_MESSAGES/bash.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de_DE/LC_MESSAGES/bash.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de.UTF-8/LC_MESSAGES/bash.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de.utf8/LC_MESSAGES/bash.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de/LC_MESSAGES/bash.mo", O_RDONLY) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=125828, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 125828, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4af6419000
close(3) = 0
newfstatat(2, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x2), ...}, AT_EMPTY_PATH) = 0
openat(AT_FDCWD, "/usr/share/locale/de_DE.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de_DE.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de_DE/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de/LC_MESSAGES/libc.mo", O_RDONLY) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=150765, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 150765, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4af63f4000
close(3) = 0
write(2, "Downloads/TeamSpeak3-Client-linu"...,
137Downloads/TeamSpeak3-Client-linux_amd64/ts3client_runscript.sh:
Zeile 11: 11925 Ungültiger Maschinenbefehl ./ts3client_linux_amd64 $@

Das ist, was ich mit strace bekomme und beinhaltet den Crash-Zeitpunkt.

--
Gruß
Marco

[Tim Ritberg]

Am 15.07.23 um 19:32 schrieb Marco Moock:

> Hallo zusammen!
>
> Ich habe nen Intel(R) Celeron(R) J4125 und wenn ich den TS3-Client
> starte und verbinde, stürzt die Software ab und ich bekomme die
> Meldung, dass es ein ungültiger Maschinenbefehl sei.

illegal opcode?

> Die Architektur 8amd64) passt. Ich vermute, dass die so kompiliert
> haben, dass Befehlssätze genutzt werden, die mein Prozessor nicht hat.
> Da würde ich gerne mehr drüber rausfinden und wissen, welcher Befehl da
> genutzt wird und welchen Befehlssatz ich dafür bräuchte, ggf. um das
> dem TS-Support mitzuteilen.
>
> Die CPU ist von 2019, daher kommt mir das schon komisch vor.

Ich weiss nicht, ob das heuzutage noch geht, aber die CPU könnte in
einem Datenbereich gelandet sein.
Bevor wir die Upcodes schecken, vielleicht hilft das:

https://stackoverflow.com/questions/10354147/find-which-assembly-instruction-caused-an-illegal-instruction-error-without-debu

Tim

[Stefan Reuther]

Am 15.07.2023 um 19:32 schrieb Marco Moock:
> Die Architektur 8amd64) passt. Ich vermute, dass die so kompiliert
> haben, dass Befehlssätze genutzt werden, die mein Prozessor nicht hat.
> Da würde ich gerne mehr drüber rausfinden und wissen, welcher Befehl da
> genutzt wird und welchen Befehlssatz ich dafür bräuchte, ggf. um das
> dem TS-Support mitzuteilen.

[...]

> Das ist, was ich mit strace bekomme und beinhaltet den Crash-Zeitpunkt.

Kannst du die ts3client_linux_amd64 im Debugger laufen lassen ('gdb -ex
r --args' vor den Aufruf schreiben)? Alternativ ein Core schreiben
lassen und das im Debugger anschauen.

'disas $pc, $pc+20' am Prompt (gdb) sollte dann sagen, was er für einen
Befehl gefunden hat. Neben der Möglichkeit, dass das Programm einen
Befehl benutzt, den dein Prozessor nicht kann, gibt es auch die
Möglichkeit, dass er einfach irgendwohin gesprungen ist, wo kein Code liegt.


Stefan

[Bonita Montero]

Am 15.07.2023 um 19:32 schrieb Marco Moock:

> Hallo zusammen!
>
> Ich habe nen Intel(R) Celeron(R) J4125 und wenn ich den TS3-Client
> starte und verbinde, stürzt die Software ab und ich bekomme die
> Meldung, dass es ein ungültiger Maschinenbefehl sei.
>
> Die Architektur 8amd64) passt. Ich vermute, dass die so kompiliert
> haben, dass Befehlssätze genutzt werden, die mein Prozessor nicht hat.
> Da würde ich gerne mehr drüber rausfinden und wissen, welcher Befehl da
> genutzt wird und welchen Befehlssatz ich dafür bräuchte, ggf. um das
> dem TS-Support mitzuteilen.

Ich mein wenn Du nix dran ändern kannst an diesem nicht unterstützten
Maschinenbefehl dann bringt dir diese Erkenntnis doch gar nichts.

[Marco Moock]

2023-07-16 07:53:33.094726|INFO |ClientUI |1 |Initiating connection: 217.160.67.148:9987
[New Thread 0x7fff94ff96c0 (LWP 12867)]

Thread 1 "ts3client_linux" received signal SIGILL, Illegal instruction.
0x0000555556cdf7d0 in ?? ()
(gdb) disas $pc, $pc+20
Dump of assembler code from 0x555556cdf7d0 to 0x555556cdf7e4:
=> 0x0000555556cdf7d0: vxorps %xmm0,%xmm0,%xmm0
0x0000555556cdf7d4: vmovups %ymm0,0x1c(%rdi)
0x0000555556cdf7d9: vmovups %ymm0,(%rdi)
0x0000555556cdf7dd: vmovaps -0x14988a5(%rip),%xmm0 # 0x555555846f40
End of assembler dump.
(gdb)

Dürfte dann AVX-512 sein, was meine CPU nicht hat. Ich melde das mal
Teamspeak. Mal gespannt, ob die das interessiert, da heute viele CPUs
das haben.

[Bonita Montero]

Am 16.07.2023 um 09:56 schrieb Marco Moock:

> Thread 1 "ts3client_linux" received signal SIGILL, Illegal instruction.
> 0x0000555556cdf7d0 in ?? ()
> (gdb) disas $pc, $pc+20
> Dump of assembler code from 0x555556cdf7d0 to 0x555556cdf7e4:
> => 0x0000555556cdf7d0: vxorps %xmm0,%xmm0,%xmm0
> 0x0000555556cdf7d4: vmovups %ymm0,0x1c(%rdi)
> 0x0000555556cdf7d9: vmovups %ymm0,(%rdi)
> 0x0000555556cdf7dd: vmovaps -0x14988a5(%rip),%xmm0 # 0x555555846f40
> End of assembler dump.
> (gdb)
>

> Dürfte dann AVX-512 sein, ...

Nein, AVX einfach, nichtmal AVX2. AVX-512 ists wenn zmm-Register
genutzt werden. Aber was solls, Du kannst eh nix dran ändern, von
daher ist das eigentlich egal, das zu untersuchen.

[Marco Moock]

Am 16.07.2023 um 09:56:47 Uhr schrieb Marco Moock:

> Dürfte dann AVX-512 sein, was meine CPU nicht hat. Ich melde das mal
> Teamspeak. Mal gespannt, ob die das interessiert, da heute viele CPUs
> das haben.

Es gibt noch einen User, der das Problem hat:
https://community.teamspeak.com/t/teamspeak-3-6-0-crashing-when-connecting-to-a-server-on-linux/41899

[Marco Moock]

Am 16.07.2023 um 10:07:48 Uhr schrieb Bonita Montero:

> Aber was solls, Du kannst eh nix dran ändern, von
> daher ist das eigentlich egal, das zu untersuchen.

Teamspeak kann das, dazu müssen die aber wissen, was das Problem ist.
Wenn die die Software auf CPUs testen, die AVX können (meine kann
nichts von AVX), fällt das Problem natürlich nicht auf.

[Bonita Montero]

Ich geh mal davon aus, dass das Absicht ist, denn die werden sicher
entsprechend vielfach Rückmeldung über dieses "Problem" kriegen.

[Bonita Montero]

Das kann man sich ja denken, dass es davon ne Menge geben muss, denn
CPUs die kein AVX unterstützen gibts sicher noch einige im Einsatz.
Ich weiß auch gar nicht was das soll, denn TeamSpeak ist sicher kein
CPU-Hog, dass das AVX benötigen würde.

[Tim Ritberg]

Am 16.07.23 um 10:23 schrieb Bonita Montero:

> Das kann man sich ja denken, dass es davon ne Menge geben muss, denn
> CPUs die kein AVX unterstützen gibts sicher noch einige im Einsatz.
> Ich weiß auch gar nicht was das soll, denn TeamSpeak ist sicher kein
> CPU-Hog, dass das AVX benötigen würde.

Nennt sich x86-64-v4 und ist das höchste der Gefühle an CPU-Features:
https://de.wikipedia.org/wiki/X64#Weiterentwicklung

Auf Englisch "Microarchitecture levels"
x86-64-v4
(AVX-512's general-purpose subset)
Skylake-X, Skylake-SP (2017)
Zen 4 (2022)


Da sind so einige gearscht...

Tim

[Bonita Montero]

Am 16.07.2023 um 10:49 schrieb Tim Ritberg:
> Am 16.07.23 um 10:23 schrieb Bonita Montero:
>
>> Das kann man sich ja denken, dass es davon ne Menge geben muss, denn
>> CPUs die kein AVX unterstützen gibts sicher noch einige im Einsatz.
>> Ich weiß auch gar nicht was das soll, denn TeamSpeak ist sicher kein
>> CPU-Hog, dass das AVX benötigen würde.
>
> Nennt sich x86-64-v4 und ist das höchste der Gefühle an CPU-Features:
> https://de.wikipedia.org/wiki/X64#Weiterentwicklung

Ist ja eben die Sache, dass es kein AVX-512 (von dem es noch ein
halbes Dutzend Varianten gibt) benötigt und somit nicht x64-v4 ist.
Aber es spielt auch keine Rolle welches AVX die benötigen - das tut
an der Stelle einfach nicht not.

[Tim Ritberg]

Am 16.07.23 um 11:06 schrieb Bonita Montero:

> Ist ja eben die Sache, dass es kein AVX-512 (von dem es noch ein
> halbes Dutzend Varianten gibt) benötigt und somit nicht x64-v4 ist.
> Aber es spielt auch keine Rolle welches AVX die benötigen - das tut
> an der Stelle einfach nicht not.

pfff, das ist für die User Experience :-D

Tim