Illegal Instruction in perl

tori

Cadet 4th Year
Dabei seit
Apr. 2009
Beiträge
75
Kurzfassung: Eine Perl-basierte Anwendung stürzt ab mit der Meldung "Ungültiger Maschinenbefehl" (Illegal Instruction). Die Stelle sieht so aus:
Code:
>> /usr/share/perl/5.14/XSLoader.pm:60:     @DynaLoader::dl_require_symbols = ($bootname);
>> /usr/share/perl/5.14/XSLoader.pm:62:     my $boot_symbol_ref;
>> /usr/share/perl/5.14/XSLoader.pm:71:     my $libref = dl_load_file($file, 0) or do {
Ungültiger Maschinenbefehl
Das System ist ein Raspberry Pi mit Raspbian, alle Pakete sind aktuell. Die besagte Anwendung ist ddclient.

Langversion: Ich wollte ddclient nutzen, das funktionierte aber nicht (ohne jegliche Fehlermeldung). Erst ein Start mit
Code:
ddclient -daemon=0 -noquiet -debug -verbose
brachte die Meldung "Ungültiger Maschinenbefehl" hervor. Im syslog usw. steht nichts darüber. Googlen nach "Illegal Instruction" förderte zutage, dass es die Meldung bei inkompatibler Architektur auftritt. Die Perl- und ddclient-Pakete stammen jedoch aus den offiziellen Raspbian-Repositories. Für das Debugging in Perl habe ich dann libdevel-trace-perl installiert und dabei kam obige Ausgabe zustande. Ich habe die Pakete bereits mehrfach neu installiert, sowohl Perl als auch ddclient. Selbst erstellt habe ich sie bisher noch nicht.

Frage 1: Wie bekomme ich ddclient zum Laufen? Was kann ich da noch machen?
Frage 2: Wenn ddclient sich nicht überreden lässt, welche Alternativen gibt es?
Frage 3: Die Stelle in ddclient an der das auftritt ist ziemlich spät (in geturl()), somit scheint ein Großteil von Perl zu funktionieren. Wie kann sowas dann eigentlich passieren?
 

entropie88

Lt. Junior Grade
Dabei seit
Juli 2011
Beiträge
304
Kurzfassung:
Frage 1: Wie bekomme ich ddclient zum Laufen? Was kann ich da noch machen?
perl selber cross compilen oder einfach abwarten werden andere sicher schnell auf dem Bugtracker melden.

Frage 2: Wenn ddclient sich nicht überreden lässt, welche Alternativen gibt es?
https://wiki.archlinux.org/index.php/Dynamic_DNS

Frage 3: Die Stelle in ddclient an der das auftritt ist ziemlich spät (in geturl()), somit scheint ein Großteil von Perl zu funktionieren. Wie kann sowas dann eigentlich passieren?
https://code.google.com/p/distcc/ kann schon mal passieren das eine Node in der falschen arch läuft.
 
Zuletzt bearbeitet:

mensch183

Captain
Dabei seit
Jan. 2008
Beiträge
3.666
Da der Fehler ausgerechnet bei geturl() auftreten soll, könnte es sein, dass der falsche Befehl nicht in Perl selbst sondern in einer vermutlich dynamisch reingelinkten (Crypto?)-bibliothek steckt. Dann müßte diese neu (mit den richtigen Optionen) gebaut werden, nicht Perl selbst.

Der quote von dl_load_file() deutet jedenfalls aufs Nachladen einer C-Bibliothek hin. Ich habe keine Ahnung, was genau Perl da lädt.

Paket neu bauen muss auch nicht zwingend helfen. Manche Software (insb. optimierte Bibliotheken) checkt gern zur Laufzeit den CPU-Typ und wirft je nach Ergebnis den passenden handoptimierten Assembler-Code an .... oder nicht passenden Asm-Code, der für die "illegal instruction" sorgt. In dem Fall reicht neu übersetzen nicht. Man muß patchen.

Also erstmal nachschauen, wo genau es kracht.
 
Zuletzt bearbeitet:

tori

Cadet 4th Year
Ersteller dieses Themas
Dabei seit
Apr. 2009
Beiträge
75
Vielen Dank für die Antworten.

Die Lösung sieht jetzt so aus: dnsdynamic.org bietet die Aktualisierung auch direkt per URL an:
https://www.dnsdynamic.org/api.php (ganz unten)

Dabei müssen bestimmte Zeichen in Benutzernamen und Passwort encodiert werden:
http://www.w3schools.com/tags/ref_urlencode.asp

Damit ich nicht den Umweg über Dateien machen muss sind nested commands recht nützlich:
http://tldp.org/LDP/abs/html/commandsub.html
Dabei immer darauf achten, dass sie in sh ausführbar sind, nicht in bash!

Anschließend gibt das Ganze einen cronjob: (crontab -e und dort dann ans Ende schreiben)
Code:
0 5 * * * curl -ks 'https://user%40name.org:password@www.dnsdynamic.org/api/?hostname=mydomain.dnsd.me&myip='`curl -s whatismyip.akamai.com`
Das Update findet um 5 Uhr morgens statt in dem Fall. Wenn man den Befehl mal selbst eingibt bekommt man den return-Code angezeigt. Bei einem "nochg" war das Update unnötig und zukünftige Updates dieser Art führen zu einer Sperrung. Andere Return-Codes sind hier aufgeführt: dyn[dot]com/support/developers/api/return-codes/
 
Zuletzt bearbeitet: (Return Code nochg + Link + &-Escape)
Top