Segmentation Fault finden, embedded System

[funky (Gast)]

Hallo,

hätte mal eine Frage zur Vorgehensweise:

Ich entwickle auf einem Embedded Linux System(wobei man es eigentlich 
schon als vollwertigen PC bezeichnen kann) in C++.

Habe nun ein riesen Programm, das ab und an(bisher nich reproduzierbar) 
einen Seg Fault produziert.

Wie geht man am besten vor, um sowas einzugrenzen und den Fehler zu 
finden?
Ich kompiliere auf einem anderen Rechner und kopiere das Binary dann auf 
das System. Wüßte momentan auch nicht, wie ich das debuggen kann.

Hat jemand nen Tip wie man da am besten vorgeht?

[madler (Gast)]

Wenn das ein Linux-System ist, gibt es dafür auch den gdb oder Du kannst 
ihn Dir dafür kompilieren oder Du kannst gdb remote verwenden (Google).

[bob (Gast)]

Gibt es bei dem SegV einen coredump? wenn nicht hilft es ggf. mit dem 
Kommando

ulimit -c unlimited

in der Shell die Erzeugung von core-files zuzulassen.
Das Setzen des ulimit's muss auf jeden Fall vor dem Start erfolgen da es 
dann an den Prozess vererbt wird.
Sollte das ganze beim Booten schon gestartet werden muss dass 
ulimit-Kommando an geeigneter Stelle eingebaut werden.

Um das Corefile auszuwerten benötigt man gdb. Wie der Vorposter schon 
geschrieben hat sollte man sich den für seine Zielplatform 
"organisieren".

Am besten wäre ein Cross-gdb, um mit komfortablen Tools auch Sprünge 
innerhalb des Sourecodes z.b. in Emacs zu machen.

SegV hat in vielen Fällen einen NULL-Pointer-Zugriff zur Ursache.

[Georg A. (Gast)]

Kann das Programm nur auf dem Embedded System laufen oder kann man es 
(evtl. mit Abstrichen) auch auf dem PC laufen lassen? Dann wäre evtl. 
valgrind ganz hilfreich, das kann ziemlich viele Speichersauereien 
finden.

Desweiteren kann man den Segfault per Signalhandler natürlich abfangen 
und dann mit den Backtrace-Tools der glibc den Aufrufbaum ausgeben:

http://www.delorie.com/gnu/docs/glibc/libc_665.html

Notfalls (falls das Binary keine Symbole hat) muss man die rohen 
Addressen halt mit den ungestrippten Binary vergleichen.

[funky (Gast)]

danke schonmal für die Stichworte.
Es handelt sich um ein Debianbasiertes(sehr abgespecktes) System. Die 
Chancen das ich da eines der Tools zum laufen bekomme sind also recht 
hoch s

Auf einem normalen PC kann ich das Programm nicht laufen 
lassen(zumindest nicht in sinnvoller Form)

Muss mich erstmal noch bischen durchwühlen. Habe noch nie mit einem 
Debugger auf einem Remote System gearbeitet und mit GDB auch noch nicht