> -----Original Message-----
> From: Tobias König [SMTP:tokoe82@yahoo.de]
> Sent: Dienstag, 7. Dezember 1999 14:04
> To: lug-dd(a)schlittermann.de
> Subject: [Lug-dd] Datenbank (zum letzten mal)
>
> Ja, da bin ich wieder...
>
> Torsten, dein Programm hat wunderbar geklappt,
> auch ohne memcpy() (dazu später mehr), aber
> sobald ich den Code in das KDE-Programm einsetze
> liefert gdbm wieder den selben Fehler zurück.
>
> Wahrscheinlich kommt gdbm mit g++ nicht zurecht...
>
Welchen Fehler ? Ich glaube nicht, das es am g++ liegt !
> Übrigens, meine memcpy()- bzw. strncpy()-Funktion
> funktioniert nicht.
> Nach dem Ausführen des compilierten Programmes, gibt
> es einen die Fehlermeldung:
>
> Segmentation fault (core dumped)
>
Liegt i.A. am Programmierer !
> und wenn ich die core-Datei durch den Debugger laufen
> lasse, spuckt er folgende Meldung aus:
>
> at ../sysdeps/generic/memcpy.c:57
> ../sysdeps/generic/memcpy.c:57: Datei oder Verzeichnis
> nicht gefunden
>
Das ist normal, oder haeltst Du die libc-Quellen vor ?
> Anscheinend stimmt was mit meiner glibc-2.0.7 nicht.
> Weis jemand ob es da schon Fehlermeldungen gab, oder
> wie ich das Problem lösen kann???
>
Da stimmt alles ...
> Ciao,
> Tokoe
>
Du solltest im gdb mal "where" eingeben. Dann tut er Dir einen
wunderschoenen Ausdruck des Stack machen. Da kannst Du
nun gucken, was wann wie womit gerufen wurde.
Der Segfault sieht nach strcpy oder memcpy mit NULL oder
Wald-Pointern aus ... Wald-Pointer sind nicht initialisierte
(also zufaellig belegte) oder bereits wieder "gefreete", also
nicht mehr belegte. Das ganze muss nicht zwingend schiefgehen!
Aber wenn's mal geht und mal nicht ... liegt's meistens an sowas ...
Also: mit where den Stack ansehen und an der Stelle, wo der
eigene Code verlassen wird nach Fehlern suchen!
Willi