Re: [Debian]: segmentation fault
On Wed, Jun 16, 1999 at 10:18:52PM +0200, Wolfgang Arnsberg wrote:
> Tach zusammen,
>
> was macht man gegen segmentation faults und wie kommen sie zustande?
segmentation fault bedeutet meistens (wenn kein Hardware Fehler vorliegt),
daß ein Programm versucht hat, eine Speicherzelle zu beschreiben, wo es
nicht darf. Also wenn Du Deine Socken bei Deinem Nachbarn in die Wäsche
tust....
Hier ein Beispiel (mit LC_ALL=de_DE):
ulysses:~# run-parts --test /foobar
Speicherzugriffsfehler (core dumped)
Unter Windows heißt das übrigens "Allgemeine Schutzverletzung" (weiß nicht,
ob das eins-zu-eins ist, aber in etwa)
Dagegen kannst Du nur einen Programmfehler beheben, oder wenigstens einen
Bug Report schicken. Wenn Du Dich kaum auskennst, reicht es erstmal, das
Programm unter strace laufen zuu lassen. strace Paket installieren und:
strace programmname optionen
(also einfach strace vorschalten).
strace verfolgt die syscalls. Mit dem Beispiel oben:
ulysses:~# strace run-parts --test /foobar
[ne menge zeugs]
open("/foobar", O_RDONLY|O_NONBLOCK|0x10000) = -1 ENOENT (No such file or directory)
[aha, /foobar gibt es nicht]
[mehr zeugs]
write(2, "run-parts: ", 11run-parts: ) = 11
write(2, "failed to open directory /foobar"..., 71failed to open directory /foobar: Datei oder Verzeichnis nicht gefunden) = 71
write(2, "\n", 1
) = 1
--- SIGSEGV (Speicherzugriffsfehler) ---
+++ killed by SIGSEGV +++
Okay, so kommen wir nicht weiter. Zweiter Versuch, diesmal das Programmpaket
ltrace, mit Kommentare:
ulysses:~# ltrace run-parts --test /foobar
atexit(0x4000ada0) = 0
__libc_init_first(3, 0xbffffcb2, 0xbffffcbc, 0xbffffcc3, 0) = 0x4000ada0
atexit(0x08049440) = 0
(umask setzen) umask(022) = 022
(optionen ein-) getopt_long(3, 0xbffffba4, "", 0x0804a970, 0xbffffb84) = 0
(-lesen) getopt_long(3, 0xbffffba4, "", 0x0804a970, 0xbffffb84) = -1
(verzeichnis
foobar) scandir(0xbffffcc3, 0xbffff714, 0, 0x0804895c, 0xbffffba4) = -1
(OOPS!) __errno_location() = 0x401092e0
(fehler!) strerror(2) = "Datei oder Verzeichnis nicht gef"...
fprintf(0x0804ab50, "run-parts: "run-parts: ) = 11
vfprintf(0x0804ab50, "failed to open directory %s: %s", 0xbffff6fcfailed to open directory /foobar: Datei oder Verzeichnis nicht gefunden) = 71
fprintf(0x0804ab50, "\n") = 1
(Speicher wieder freigeben)
free(0x40014c38) = <void>
--- SIGSEGV (Speicherzugriffsfehler) ---
+++ killed by SIGSEGV +++
AHA!!! Also, run-parts gibt Speicher wieder frei, und erleidet dann einen
segfault. Das deutet auf Zugriff schono freigegeben Speicherplätze
hin. Einem Programmierer fällt es leicht, sich die Sourcen an dieser Stelle
anzusehen. Besser ist es aber, gdb (GNU debugger) laufen zu lassen. Dazu muß
man aber unge'strip'te Binaries nehmen, also neu kompilieren.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <deine emailadresse>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder: 760
Reply to: