Hallo, sorry falls irgendwas schief geht, ich kopier das hier aus dem Archiv zusammen... Helga Fischer wrote:

Kann mir einer erklären, wie ich mir das mit der Rückverfolgung eines Crashs vorzustellen habe? Wie funktioniert das denn?

Naja, sagt dir der Begriff 'stack' etwas? Achtung: alles nur IIRC, ich bitte um Korrekturen! Also, wenn ein Programm ablaueft, dann werden i.a. ja mehr oder weniger viele Funktionen aufgerufen, und deren Adressen sowie (die Adressen) deren lokale Variablen landen eben dort, auf dem "Stack". Ein "Stack" ist ein "Stapel", du kannst oben was drauflegen, und von oben wieder runternehmen... Der sog. "Stack-Backtrace" baut also quasi den Stapel komplett ab, und ist somit i.A. von hinten/unten zu lesen, um herauszufinden was/von wo aufgerufen wurde... Nun kommt das folgende ins Spiel:

Wenn er sagt, no debugging symbols found, dann heißt das, das der verwendete Code keine Debugging-Informationen enthält (die kann man mitkompilieren). Warum aber gibt es dann trotzdem noch Informationen?

Naja, es gibt eben die Info's, die zur Laufzeit verfuegbar sind, also z.B. eben die Adressen von Funktionen und Variablen. Das hilft einem aber nur relativ wenig. Zum Kernel gibt's dafuer die System.map, die diese Adressen einem Namen zuordnet, bei Programmen muessen die Symbolnamen in das binary einkompiliert werden (d.h. kein "strip"!). Dann kann der Backtrace die Symbolnamen mit ausgeben. Zum debuggen selbst sind allerdings noch mehr Infos noetig (die mit dem flag '-g' mit einkompiliert werden koennen), damit sich der debugger zurechtfindet...

Und wie aussagekräftig sind sie?

Sehr, wenn man auch die Quellen vorliegen hat ;) Bei KDE wuerde ich mir aber als nicht-KDE-Anwender keinen Kopp drum machen, dazu sind u.a. zu viele libs beteiligt, soll heissen, die Komplexitaet ist enorm und der Aufwand den Fehler zu lokalisieren ebenso. Und leider sind (kleinere) Unsauberkeiten bei den GUIs leider normal, kompiliere mal ne KDE/GTK-App mit '-Wall -W', vieles was dann der gcc als Warnings ausspuckt funktioniert oder ist sogar richtig, aber eben _nicht_ alles ;( Was mir z.B. (ich versuch grad gtk2 zu kompilieren mal wieder) am meisten auffaellt, ist dass mit der "signedness" von Variablen ziemlich rumgeschlampt wird, was sich vereinzelt bis in die libc und den Kernel zieht... Tja, und wenn man signed und unsigned vergleicht (z.B.) sind die Resultate nur bedingt deterministisch. Kompiliere mal z.B: ,----[ /tmp/test/signedness.c ] | #include | int main(void) { | unsigned int a = -1; | signed int b = -1; | if( a <= b ) { | printf("a=%u <= b=%i is true\n", a, b); | } else { | printf("a=%u > b=%i\n", a, b); | } | return 0; | } `---- /tmp/test $ make signedness gcc -Wall -W signedness.c -o signedness signedness.c: In function `main': signedness.c:5: warning: comparison between signed and unsigned /tmp/test $ ./signedness [snip! will die "Spannung" nicht versauen ;)] Tja! Eben! *grummel* -dnh -- In short, I want to show people what real power is. Power is not having to bomb cities flat to bring mass murderers to justice. Power is being able to determine guilt or innocence and it comes from being willing to actually act as if the principles you espouse matter to you even when they're inconvenient. -- Jonathan Guthrie in asr

Helga Fischer wrote:

Wenn er sagt, no debugging symbols found, dann heißt das, das der verwendete Code keine Debugging-Informationen enthält (die kann man mitkompilieren). Warum aber gibt es dann trotzdem noch Informationen? Und wie aussagekräftig sind sie?

100% aussagekraefitg. Das was er an Informationen besorgen kann, sind die Einsprungsadressen der Funktionen. Im backtrace stehen die hexadezimal Adressen der Bibliotheksfunktionen, die der Crash-Manager liest. Dann schaut er in den Bibliotheken nach den export-Symbolen und listet die auf. Die Meldung am Anfang bezieht sich auf die Extra-Informationen, die der gcc dem gdb zur Verfuegung stellen koennte. Dann steht dort ein Verweis auf das Source-File und die Zeilennummer in der die fehlerhafte Zeile auftaucht. Programme gezielt wegschiessen kann man mit "kill -6 <pid>" und dann taucht der Crash-Manager auf. hier die Ausgabe bei mir: (no debugging symbols found)...(no debugging symbols found)... 0x41040079 in wait4 () from /lib/libc.so.6 #0 0x41040079 in wait4 () from /lib/libc.so.6 #1 0x410bab98 in __DTOR_END__ () from /lib/libc.so.6 #2 0x40ed5072 in waitpid () from /lib/libpthread.so.0 #3 0x406cb08e in KCrash::defaultCrashHandler () from /opt/kde3/lib/libkdecore.so.4 #4 0x40ed2a74 in pthread_sighandler () from /lib/libpthread.so.0 *** hier beginnt der interessante Teil *** #5 <signal handler called> #6 0x41069d6e in select () from /lib/libc.so.6 #7 0x40da6984 in __DTOR_END__ () from /usr/lib/libqt-mt.so.3 #8 0x40956a14 in QApplication::enter_loop () from /usr/lib/libqt-mt.so.3 #9 0x40903df6 in QApplication::exec () from /usr/lib/libqt-mt.so.3 #10 0x0806568a in QScrollView::mouseReleaseEvent () #11 0x40fb59ed in __libc_start_main () from /lib/libc.so.6 Mein KNotes hat also geduldig in der select()-funktion gewartet, bis es starb. und aus dem gdb-info file: #0 m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8) at builtin.c:993 #1 0x6e38 in expand_macro (sym=0x2b600) at macro.c:242 #2 0x6840 in expand_token (obs=0x0, t=177664, td=0xf7fffb08) at macro.c:71 (More stack frames follow...) Es fehlen also auch noch die Argumentlisten inkl. der Werte. Peter