Portierung eines C-Programms von SuSE 9.0 32bit auf openSuse 12.1 64bit -> SIGSEV
-
Kannst du dir da nicht einen gcc im $HOME Verzeichnis kompilieren?
-
auf meinem 32bit-System und mit einem Valgrind aus der Vorkriegszeit bekomme ich im Übrigen keine signifikanten Probleme gemeldet. Ein Speicherproblem mit uninitialisierten Variablen in einer shared lib vom Kollegen hat er angeblich ausgebessert - kann ich nicht nachvollziehn, weil er nur eine 64-bit-Version der lib für besagte Maschine gebaut hat und dort ja kein valgrind läuft...
-
Pretty schrieb:
auf meinem 32bit-System und mit einem Valgrind aus der Vorkriegszeit bekomme ich im Übrigen keine signifikanten Probleme gemeldet. Ein Speicherproblem mit uninitialisierten Variablen in einer shared lib vom Kollegen hat er angeblich ausgebessert - kann ich nicht nachvollziehn, weil er nur eine 64-bit-Version der lib für besagte Maschine gebaut hat und dort ja kein valgrind läuft...
Keine signifikanten Probleme? Angeblich ausgebessert? Jedes Problem das valgrind meldet ist fast ausnahmslos äußerst signifikant. Ich habe den Eindruck, dass das Problem hier das laxe Verhalten bei Fehlern und Warnungen ist. Hauptsache es läuft, oder? Da siehst du, wohin diese Einstellung führt.
Das schöne an deinem vorsinntflutlichen Betriebssystem ist doch, dass du dir den neuesten gcc und das neueste valgrind und die Multilib und alle Abhängigkeiten einfach in dein Homeverzeichnis installieren kannst. Dann bei jedem configure das Homeverzeichnis als Include-/Lib-/Runpfad angeben. Oder einfach für dich diese Pfade fest in die entsprechenden Umgebungsvariablen schreiben. Und schon hast du alles was du brauchst, mit dem gleichen Komfort als sei es systemweit installiert. Versuch das mal in Windows oder mit einer Klickibunti-IDE
.(Es dürfte jedoch ein paar Stunden dauern, den GCC, valgrind und die multilib aus dem nichts zu compilieren. Da muss man dann eben durch)
P.S.: Und wie kann valgrind kein Problem melden, wenn das Programm abstürzt? Es sollte dir im Gegenteil sogar die Ursache melden, im Idealfall sogar zurückverfolgt bis an die Stelle der eigentlichen(!) Ursache, die zu dem unmittelbaren Absturz geführt hat. Irgendwas stimmt hier doch nicht.
-
SeppJ schrieb:
(Es dürfte jedoch ein paar Stunden dauern, den GCC, valgrind und die multilib aus dem nichts zu compilieren. Da muss man dann eben durch)
Das dauert bei mir wahrscheinlich noch länger, wenn ich keine idiotensichere Anleitung finde
SeppJ schrieb:
P.S.: Und wie kann valgrind kein Problem melden, wenn das Programm abstürzt? Es sollte dir im Gegenteil sogar die Ursache melden, im Idealfall sogar zurückverfolgt bis an die Stelle der eigentlichen(!) Ursache, die zu dem unmittelbaren Absturz geführt hat. Irgendwas stimmt hier doch nicht.
Valgrind läuft ja auf dem 64bit-System noch nicht, also meldet es dort nichts. Auf dem 32-Bit-System gibt es keinen Absturz. Die ausgespuckten Meldungen beziehen sich alle auf die nicht debugfähige shared lib vom Kollegen, der die Probleme ja behoben habe.
Jetzt such ich mal nach einer Möglichkeit, meinen GCC auf der 32bit-Maschine lokal aktuell zu halten.
-
Pretty schrieb:
Die ausgespuckten Meldungen beziehen sich alle auf die nicht debugfähige shared lib vom Kollegen, der die Probleme ja behoben habe.
Aha! Wenn er versucht, da was z melden und wegen der fehlenden Debuginformationen keinen genauen Ort angeben kann, so hat er doch was gefunden!
-
In den nicht-aktualisierten und noch fehlerhaften Funktionen der shared lib, ja.
Ich mach mal lieber morgen früh weiter - danke an alle
-
würg...
Die stacksize über ulimit angesehen - 8192. Da ich großzügig mit dem RAM umgehe, hat das einfach nicht gereicht.
Jetzt gibts keine Abstürze mehr beim allokieren und obendrein hab ich noch nen möglichen Überlauf entdeckt und ausschalten können.Danke Euch für die Hilfe.
