backtrace erstellen wie?
lima-city → Forum → Programmiersprachen → C/C++ und D
autor
bus
code
datei
file
http
information
modul
not
pfad
programm
show
signal
software
terminal ausgabe
text
treten
type
url
zustand
-
Hallo,
ich habe gcc 4.3.0 und 4.7.0 probiert auf meinem debian / sarge - sparc zu kompilieren. Dabei habe ich einen Bug entdeckt und diesen auch gemeldet.
Nun wollen die Autoren von mir einen backtrace. Allerdings weiß ich nicht genau wie ich den erstellen soll.
Kann mir wer sagen wie das geht? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Wo hat es denn genau geknallt? Hat der Compilierungsprozess nicht geklappt, oder ist der GCC beim compilieren von einem anderen GCC abgestürzt?
Wenn das erste der Fall ist, solltest du die letzten Zeilen deiner Terminal-Ausgabe nehmen, bevor er den Compilierungsvorgang abbricht (sofern da nichts paralellisiert wurde).
Im zweiten Fall verwende folgenden Befehl im Terminal:
ulimit -c unlimited
Um coredumps zu aktivieren. Jetzt starte den Compilierungprozess noch einmal. Sobald GCC abstürzt, sollte eine Datei mit dem Namen core im Dateisystem zu finden sein. Sobald du diese Datei gefunden hast, benutzt du den GNU Debugger um den Backtrace zu erzeugten:
gdb $(which gcc) ./core #GDB intro Text bt
Und das kannst du dann kopieren. -
Hallo,
habe gcc 4.3.0 probiert mit make --debug CFLAGS='-g -O0' zu kompilieren. Hier der link http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53467
Habe ulimit -c unlimited ausgeführt und werde jetzt nochmal kompilieren wie du gesagt hast. Das dauert jetzt ein bisschen :(
Beitrag zuletzt geändert: 27.5.2012 15:04:42 von get -
get schrieb:
Hallo,
habe gcc 4.3.0 probiert mit make --debug CFLAGS='-g -O0' zu kompilieren. Hier der link http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53467
In dem Fall scheint es der xgcc zu sein. Von daher wirst du wahrscheinlich folgendes ausführen müssen:
gdb $(which xgcc) ./core #GDB intro text bt
Habe ulimit -c unlimited ausgeführt und werde jetzt nochmal kompilieren wie du gesagt hast. Das dauert jetzt ein bisschen :(
Jup.
Aus dem Bugreport geht es nicht ganz klar hervor: Wann tritt das Problem auf? Bei
1) ./configure
oder beim anschließendem
2) make
Insgesammt tendiere ich zu 2), aber die logfile verwirrt mich teilweise.
Beitrag zuletzt geändert: 27.5.2012 15:51:30 von bladehunter -
Hallo,
ja du hast recht, genau genommen tritt der Fehler wie du bemerkt hast beim ./configure von libgcc auf.
Bei gcc ist es ja so, dass der aus mehreren Modulen besteht und nach dem ausführen von make für jedes modul seperat ein configure ausführt und anschließend auto. kompiliert.
Also wenn ich
/backup/gcc-4.3.0-compiled/gcc# ls co collect2 collect-ld combine-stack-adj.o config.cache config.log convert.o coverage.o collect2.o combine.o configargs.h config.h config.status core
mache sieht man das die File erstellt ist. So weit so gut. Hier der output:
gdb $(which gcc) ./core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-linux"...Using host libthread_db library "/lib/libthread_db.so.1". warning: core file may not match specified executable file. Core was generated by `/backup/gcc-4.3.0-compiled/./gcc/cc1 -E -quiet -iprefix /c/backup/gcc-4.3.0-com'. Program terminated with signal 10, Bus error. #0 0x2000ab58 in ?? () Breakpoint 1 at 0x13214: file ../../gcc-4.0.0/gcc/gcc.c, line 6733. Function "internal_error" not defined. Breakpoint 2 at 0x37348 Breakpoint 3 at 0x37210
Ok, habe die Rückmeldung "The core file was not generated by gcc, as gdb says it came from cc1" erhalten. Aber ich weiß jetzt nicht was ich damit anfangen soll.
So wie kann das mit cc1 loggen?
Beitrag zuletzt geändert: 27.5.2012 20:04:08 von get -
get schrieb:
So wie kann das mit cc1 loggen?
gdb $(which cc1) ./core
Und falls das nicht klappt, findet er wahrscheinlich das Binary cc1 nicht in deinem PATH. Dann musst du selber den Pfad zur Datei rausfinden und angeben.
Mit
gdb programm coredatei
startest du das jeweilige Programm im Debugger. Da du zusätzlich eine core-Datei übergeben hast, fängt die "Ausführung" direkt an der Stelle an, wo das Programm abgestürzt ist. (Und weil es abgestürzt ist, kann man es in diesem Fall auch nicht weiterlaufen lassen).
In der core-Datei ist der Zustand des Programs gespeichert, bei dem es abgestürzt ist. Und diesen Zustand kannst du mit dem Debugger abfragen. Den Backtrace kriegst du mit dem GDB Befehl bt.
Beitrag zuletzt geändert: 27.5.2012 21:16:26 von bladehunter -
Hallo,
danke für die schnelle Rückmeldung. Also ich habs jetzt so versucht:
./corebackup/gcc-4.3.0-compiled/gcc# gdb /usr/lib/gcc-lib/sparc-linux/3.3.5/cc1 ./core
und erhalte die Meldung:
Core was generated by `/backup/gcc-4.3.0-compiled/./gcc/cc1 -E -quiet -iprefix /c/backup/gcc-4.3.0-com'. Program terminated with signal 10, Bus error. #0 0x2000ab58 in ?? () Function "fancy_abort" not defined. Function "internal_error" not defined. Breakpoint 1 at 0x2cb9f8 Breakpoint 2 at 0x2cb848 (gdb) backtrace #0 0x2000ab58 in ?? () #1 0x2000aaf8 in ?? () Previous frame identical to this frame (corrupt stack?)
backtrace full liefert auch nicht mehr Informationen.
Ich habe den Backtrace auf bugzilla hochgeladen. Die können jetzt rein theoretisch alle Informationen raus lesen die Sie brauchen?
-
Okay. Da scheint wirklich was sehr faul zu sein. Diese Angaben sind jedenfalls nicht sonderlich hilfreich. Ansonsten solltest du noch mal ins IRC gehen und im Channel #gcc im freenode.org Netzwerk nachfragen, wie du die benötigten Infos kriegst.
Oder kann es sein, dass du das falsche executable angegeben hast? Im Bugtracker hat auch schon jemand angemerkt, dass das Executable cc1 ist und nicht gcc.
Beitrag zuletzt geändert: 27.5.2012 22:51:10 von bladehunter -
Hallo,
ich habe es jetzt geschafft gcc 4.3.0 erfolgreich zu kompilieren. Ich habe mit den configure Parameter einiges ausprobiert und hatte erfolg :) Ich werde dies dann auch im Bugreport posten, wenn er gcc 4.7.0 fertig kompiliert hat (der NAS kompiliert mit heute schon seit 3 Tagen!)
Also auf dem NAS war bereits gcc 3.3.5 installiert (via Paketmanager). Aufgrund der kaputten Abhänigkeiten konnte ich gcc nur über den source upgraden.
Und zwar habe ich zuerst gcc 4.0.0 kompiliert, dann gcc 4.3.0 und jetzt eben gcc 4.7.0.
Da die Systempartition des NAS auf 1GB beschränkt ist würde ich gern die "überflüssigen gcc Versionen deinstallieren. Also den gcc 4.0.0 mit make uninstall runter machen. (Später dann den gcc 4.3.0 wenn gcc 4.7.0 fertig ist)
Kann ich den gcc 4.0.0 so ohne weiteres deinstallieren, oder könnte es sein, dass gcc 4.3.0 irgendwie auf den gcc 4.0.0 aufbaut und abhänigkeiten vorhanden sind? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
