Hallo,
Ich habe ein Problem mit apt-ftparchive unter Debian. Wird das Programm via cron-Job aufgerufen, dann wirft es Fehlermeldungen wie
E: Sub-process gzip returned an error code (100)
Rufe ich das Programm aber von der Konsole auf, funktioniert alles. gzip ist natürlich installiert. Nun wurde mir vorgeschlagen, mittels gdb mal einen Blick auf den Stacktrace zu werfen. Wie muss ich gdb jetzt in den cron-job einbinden? Ich vermute mal mittels -batch und -x|-command. Der Fehler wird von dann von apt-pkg/contrib/fileutl.cc (Zeile 390) auf stderr ausgegeben (müsste ich da einen Break-Point setzen? - wahrschenlich müsste ich eher beim Aufruf von gzip den Break-Point setzen, richtig?). Könnte mir jemand bei dem Problem behilflich sein? Das Problem hindert aktuell debarchiver am korrekten Funktionieren und das ist sehr lästig. Allerdings bin ich beim Debuggen nicht so versiert.
MfG Daniel
Hallo Daniel,
Daniel Leidert schrieb:
Ich habe ein Problem mit apt-ftparchive unter Debian. Wird das Programm via cron-Job aufgerufen, dann wirft es Fehlermeldungen wie
E: Sub-process gzip returned an error code (100)
Rufe ich das Programm aber von der Konsole auf, funktioniert alles. gzip ist natürlich installiert. Nun wurde mir vorgeschlagen, mittels gdb mal einen Blick auf den Stacktrace zu werfen. Wie muss ich gdb jetzt in den cron-job einbinden? Ich vermute mal mittels -batch und -x|-command. Der Fehler wird von dann von apt-pkg/contrib/fileutl.cc (Zeile 390) auf stderr ausgegeben (müsste ich da einen Break-Point setzen? - wahrschenlich müsste ich eher beim Aufruf von gzip den Break-Point setzen, richtig?). Könnte mir jemand bei dem Problem behilflich sein? Das Problem hindert aktuell debarchiver am korrekten Funktionieren und das ist sehr lästig. Allerdings bin ich beim Debuggen nicht so versiert.
Bevor Du dich mit gdb auseinandersetzt, probiere mal strace. Damit bekommst Du alle Systemaufrufe deines Programmes zu sehen. Der Aufruf sollte in etwa so erfolgen: strace -f apt-ftparchive 2> /tmp/strace.log
Im Output selbst stehen dann auch die Returncodes der Systemaufrufe. Meist findet man dann ein ENOPERM, was auf ein Recteproblem hinweist.
Wenn Du doch gdb einsetzen willst, dann brauchst Du wahrscheinlich eine Datei in der der breakpoint gesetzt wird, das Programm gestartet und anschließend ein Backtrace ausgegeben wird:
Ich habe zur Zeit kein Linux zur Hand, aber es sollte in etwa so aussehen:
break apt-pkg/contrib/fileutl.cc:390 run bt (evtl. auch btfull oder so ähnlich) disable 1 (Breakpoint 1 deaktivieren) continue
Dieses Script gibst Du dem gdb mit (ich glaube mit -x). Bevor Du das alles in die Crontab einträgst, solltest Du es erst mal im gdb selbst ausprobieren. apt-ftparchive sollte auf jeden Fall mit Debugsymbolen versehen sein (-ggdb beim Übersetzen).
Viel Erfolg bei der Suche, Gregor
Am Montag, den 28.11.2005, 15:34 +0100 schrieb Gregor Jasny:
Daniel Leidert schrieb:
Ich habe ein Problem mit apt-ftparchive unter Debian. Wird das Programm via cron-Job aufgerufen, dann wirft es Fehlermeldungen wie
E: Sub-process gzip returned an error code (100)
Rufe ich das Programm aber von der Konsole auf, funktioniert alles. gzip ist natürlich installiert. Nun wurde mir vorgeschlagen, mittels gdb mal einen Blick auf den Stacktrace zu werfen. Wie muss ich gdb jetzt in den cron-job einbinden? Ich vermute mal mittels -batch und -x|-command. Der Fehler wird von dann von apt-pkg/contrib/fileutl.cc (Zeile 390) auf stderr ausgegeben (müsste ich da einen Break-Point setzen? - wahrschenlich müsste ich eher beim Aufruf von gzip den Break-Point setzen, richtig?). Könnte mir jemand bei dem Problem behilflich sein? Das Problem hindert aktuell debarchiver am korrekten Funktionieren und das ist sehr lästig. Allerdings bin ich beim Debuggen nicht so versiert.
Bevor Du dich mit gdb auseinandersetzt, probiere mal strace.
Danke. Natürlich hast du Recht. Manchmal übersieht man das offensichtliche.
Damit bekommst Du alle Systemaufrufe deines Programmes zu sehen. Der Aufruf sollte in etwa so erfolgen: strace -f apt-ftparchive 2> /tmp/strace.log
Klar. Allerdings mit -o.
Im Output selbst stehen dann auch die Returncodes der Systemaufrufe. Meist findet man dann ein ENOPERM, was auf ein Recteproblem hinweist.
Nein. Das ist es nicht. Das ist es:
[..]
./cron.9880:52:execve("/usr/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.9880:53:execve("/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.9881:52:execve("/usr/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.9881:53:execve("/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.9882:52:execve("/usr/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.9882:53:execve("/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.9886:52:execve("/usr/bin/gzgzg4é^P^A", ["n/gzgzg4\351\20\1", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.9886:53:execve("/bin/gzgzg4é^P^A", ["n/gzgzg4\351\20\1", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory)
Das müsste eigentlich jeweils (/usr)/bin/gzip heißen. Damit erklärt sich auch die 100-Fehlermeldung. Da ich von C++ herzlich wenig Ahnung habe, überlasse ich das vorerst dem Maintainer. Falls es jemanden interessiert oder helfen möchte: Debian BTS #341326.
Wenn Du doch gdb einsetzen willst, dann brauchst Du wahrscheinlich eine Datei in der der breakpoint gesetzt wird, das Programm gestartet und anschließend ein Backtrace ausgegeben wird:
Ich habe zur Zeit kein Linux zur Hand, aber es sollte in etwa so aussehen:
break apt-pkg/contrib/fileutl.cc:390 run bt (evtl. auch btfull oder so ähnlich) disable 1 (Breakpoint 1 deaktivieren) continue
Dieses Script gibst Du dem gdb mit (ich glaube mit -x). Bevor Du das alles in die Crontab einträgst, solltest Du es erst mal im gdb selbst ausprobieren. apt-ftparchive sollte auf jeden Fall mit Debugsymbolen versehen sein (-ggdb beim Übersetzen).
Danke. Sollte sich der zuständige Maintainer nicht darum kümmern, werde ich das näher ins Auge fassen (dank strace könnte ich die Break-Points jetzt auch besser setzen). Ich muss mich dringend intensiver mit gdb befassen. Hilft immer, wenn man den Fehler schon lokalisiert hat, wenn man einen Bug-Report sendet :)
Danke noch einmal, MfG Daniel
El Jueves, 1. Diciembre 2005 03:37, Daniel Leidert escribió:
./cron.9886:53:execve("/bin/gzgzg4é^P^A", ["n/gzgzg4\351\20\1", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory)
Klassischer Fall von String-Korruption. Da hat er wohl die C++-String-Klassen umgangen und händisch was zusammengebaut.
Josef
El Jueves, 1. Diciembre 2005 03:37, Daniel Leidert escribió:
Das müsste eigentlich jeweils (/usr)/bin/gzip heißen. Damit erklärt sich auch die 100-Fehlermeldung. Da ich von C++ herzlich wenig Ahnung habe, überlasse ich das vorerst dem Maintainer. Falls es jemanden interessiert oder helfen möchte: Debian BTS #341326.
Kannst du bitte noch die Konfigurationsdatei dort ablegen? Hab mit apt-utils 0.6.42.3 und ähnlichen sonstigen Versionen und der Vorlage aus dem examples-Verzeichnis (und angepassten Pfaden) den Fehler nicht verifizieren können. *Mein* apt-ftparchive funktioniert auch im cron :) Die Vermutung, dass die Speicherkorruption durch händische String-Puzzelei entstanden ist, scheint auch nicht zu stimmen, denn er verwendet ja Konstanten für die Ausführung von execvp().
Schau bitte auch mal (via std::cout, gdb, valgrind falls x86-Nutzer) nach, wie die Werte kurz vor dem execvp() übergeben werden.
Josef
Am Montag, den 05.12.2005, 09:40 +0100 schrieb Josef Spillner:
El Jueves, 1. Diciembre 2005 03:37, Daniel Leidert escribió:
Das müsste eigentlich jeweils (/usr)/bin/gzip heißen. Damit erklärt sich auch die 100-Fehlermeldung. Da ich von C++ herzlich wenig Ahnung habe, überlasse ich das vorerst dem Maintainer. Falls es jemanden interessiert oder helfen möchte: Debian BTS #341326.
Kannst du bitte noch die Konfigurationsdatei dort ablegen?
Ich habe sie hier abgelegt:
http://debian.wgdd.de/temp/archiv.tar.gz
Das Archiv enthält (/var/lib/)debarchiver_ubuntu. Die Konfigurations-Datei debarchiver_ubuntu/dists/.apt-ftparchive.conf, die an apt-ftparchive übergeben wird, legt fest, dass als CachDir /var/cache/debarchiver_ubuntu fungiert.
Die Dateien gehören auf meinem System dem Nutzer debarchiver, der kein Passwort besitzt:
debarchiver:x:113:113:Deb archiving tool,,,:/home/debarchiver:/bin/sh
/etc/cron.d/debarchiver_ubuntu sieht so aus (mit strace):
*/1 * * * * debarchiver strace -ff -o /tmp/cron.log /usr/bin/apt-ftparchive generate /var/lib/debarchiver_ubuntu/dists/.apt-ftparchive.conf
Hab mit apt-utils 0.6.42.3 und ähnlichen sonstigen Versionen und der Vorlage aus dem examples-Verzeichnis (und angepassten Pfaden) den Fehler nicht verifizieren können.
Ich kann ihn unter meinem Sid leider stetig verifizieren, trotz aktuellem apt (0.6.43).
*Mein* apt-ftparchive funktioniert auch im cron :)
Du hast es gut :(
Die Vermutung, dass die Speicherkorruption durch händische String-Puzzelei entstanden ist, scheint auch nicht zu stimmen, denn er verwendet ja Konstanten für die Ausführung von execvp().
Schau bitte auch mal (via std::cout, gdb, valgrind falls x86-Nutzer) nach, wie die Werte kurz vor dem execvp() übergeben werden.
Könntest du das bitte spezifizieren?
MfG Daniel
El Lunes, 5. Diciembre 2005 16:42, Daniel Leidert escribió:
Ich habe sie hier abgelegt:
'k, danke. Hatte sie gleich gesichert, bin aber noch nicht zum Experimentieren gekommen. Vielleicht jetzt am Wochenende. (Wenn man das 'debian' weglässt, kommen komische PHP-Fehler.)
Schau bitte auch mal (via std::cout, gdb, valgrind falls x86-Nutzer) nach, wie die Werte kurz vor dem execvp() übergeben werden.
Könntest du das bitte spezifizieren?
Das execvp() führt für jede Komponente in $PATH ein execve() mit dieser Pfadkomponente und dem übergebenen Programm aus. Die Frage wäre also, bekommt execvp() schon fehlerhafte Strings übergeben? Also z.B. vor dem execvp() mal folgendes eingeben: cout << "(debug:compressor) " << Args[0] << endl; (ist nicht so schick wie mit gdb, aber einfacher zu erklären ;)
Da ich einen powerpc habe, möchte ich einen Fehler in der libc/libstdc++ nicht ausschließen. (Werde das aber auch nochmal auf x86 testen.)
Josef
Am Donnerstag, den 08.12.2005, 15:04 +0100 schrieb Josef Spillner:
El Lunes, 5. Diciembre 2005 16:42, Daniel Leidert escribió:
Ich habe sie hier abgelegt:
'k, danke. Hatte sie gleich gesichert, bin aber noch nicht zum Experimentieren gekommen. Vielleicht jetzt am Wochenende. (Wenn man das 'debian' weglässt, kommen komische PHP-Fehler.)
Danke. Da hat ein Update offenbar stillschweigend eine Änderung an den Configs vorgenommen.
Schau bitte auch mal (via std::cout, gdb, valgrind falls x86-Nutzer) nach, wie die Werte kurz vor dem execvp() übergeben werden.
Könntest du das bitte spezifizieren?
Das execvp() führt für jede Komponente in $PATH ein execve() mit dieser Pfadkomponente und dem übergebenen Programm aus. Die Frage wäre also, bekommt execvp() schon fehlerhafte Strings übergeben? Also z.B. vor dem execvp() mal folgendes eingeben: cout << "(debug:compressor) " << Args[0] << endl; (ist nicht so schick wie mit gdb, aber einfacher zu erklären ;)
Ok. Habe ich mal gemacht (apt-inst/contrib/extracttar.cc). Folgendes kommt dabei heraus:
[..] ./cron.log.24722:54:write(1, "(debug:compressor) gzip\n", 24) = 24 ./cron.log.24722-55-execve("/usr/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.log.24722-56-execve("/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.log.24722-57-write(2, "Failed to exec gzip ", 20) = 20 -- ./cron.log.24725:52:write(1, "(debug:compressor) gzip\n", 24) = 24 ./cron.log.24725-53-execve("/usr/bin/gzgzgs9", ["n/gzgzgs9", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.log.24725-54-execve("/bin/gzgzgs9", ["n/gzgzgs9", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.log.24725-55-write(2, "Failed to exec gzip ", 20) = 20 -- ./cron.log.24726:52:write(1, "(debug:compressor) gzip\n", 24) = 24 ./cron.log.24726-53-execve("/usr/bin/gzgzgn)", ["n/gzgzgn)", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.log.24726-54-execve("/bin/gzgzgn)", ["n/gzgzgn)", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.log.24726-55-write(2, "Failed to exec gzip ", 20) = 20 -- ./cron.log.24729:52:write(1, "(debug:compressor) gzip\n", 24) = 24 ./cron.log.24729-53-execve("/usr/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.log.24729-54-execve("/bin/gzgzg", ["n/gzgzg", "-d"], [/* 8 vars */]) = -1 ENOENT (No such file or directory) ./cron.log.24729-55-write(2, "Failed to exec gzip ", 20) = 20 -- ./cron.log:165:read(8, "(debug:compressor) gzip\n", 512) = 24 ./cron.log-166-read(8, "", 488) = 0 ./cron.log-167---- SIGCHLD (Child exited) @ 0 (0) --- ./cron.log-168-close(8) = 0 -- ./cron.log:210:read(8, "(debug:compressor) gzip\n", 512) = 24 ./cron.log-211-read(8, "", 488) = 0 ./cron.log-212---- SIGCHLD (Child exited) @ 0 (0) --- ./cron.log-213-close(8) = 0 -- ./cron.log:252:read(8, "(debug:compressor) gzip\n", 512) = 24 ./cron.log-253-read(8, "", 488) = 0 ./cron.log-254---- SIGCHLD (Child exited) @ 0 (0) --- ./cron.log-255-close(8) = 0 -- ./cron.log:381:read(8, "(debug:compressor) gzip\n", 512) = 24 ./cron.log-382-read(8, "", 488) = 0 ./cron.log-383---- SIGCHLD (Child exited) @ 0 (0) --- ./cron.log-384-close(8) = 0 [..]
Scheint also bis zur Übergabe noch korrekt zu sein. Im übrigen habe ich mal mit Memtest86 meinen RAM getestet. Es konnten keine Fehler gefunden werden. Also gehe ich mal davon aus, dass das Problem nicht durch defekten RAM verursacht wird.
Da ich einen powerpc habe, möchte ich einen Fehler in der libc/libstdc++ nicht ausschließen.
Ich würde ja fast darauf tippen, da nach dem letzten bekannten Termin als es noch funktionierte, weder gzip noch apt(-utils) geändert wurden. In die Zeit fiel aber die allocator-Änderung.
(Werde das aber auch nochmal auf x86 testen.)
MfG Daniel
Am Freitag, den 09.12.2005, 10:33 +0100 schrieb Daniel Leidert:
Am Donnerstag, den 08.12.2005, 15:04 +0100 schrieb Josef Spillner:
[..]
Also z.B. vor dem execvp() mal folgendes eingeben: cout << "(debug:compressor) " << Args[0] << endl; (ist nicht so schick wie mit gdb, aber einfacher zu erklären ;)
Ok. Habe ich mal gemacht (apt-inst/contrib/extracttar.cc). Folgendes kommt dabei heraus:
[snip]
Kleine Anekdote nebenbei. Danach warf mit apt bei jeder Paket-Installation die Meldung:
"Tar Checksum failed, archive corrupted" (aus extracttar.cc)
Nachdem ich wieder die offiziellen Debian-Pakete installiert hatte, verschwand diese Meldung. Irgendwas läuft hier falsch. Ich sollte diese Infos mal fürs BTS aufbereiten.
MfG Daniel
lug-dd@mailman.schlittermann.de
-
Daniel Leidert -
Gregor Jasny -
Josef Spillner