Portierung eines C-Programms von SuSE 9.0 32bit auf openSuse 12.1 64bit -> SIGSEV
-
Pretty schrieb:
gcc multilibfähig zu kompilieren wäre kein großes Hindernis - ist nur nicht gestattet.
Von wem? Deinem Arbeitgeber? Müsst ihr auch mit verbundenen Augen und der rechten Hand auf dem Rücken arbeiten?Hast du mal valgrind oder ähnliches auf das Problem angesetzt? Wozu von Hand suchen und raten, wenn ein Computer fehlerfrei alles durchtesten kann?
-
Ich komme von C# und wurde hier in eine steinzeitliche Grube geworfen, in der Windows verteufelt und alle Hilfsmittel dieses Jahrtausends verschmäht werden.
Deshalb darf ich auf einem 10 Jahre alten Betriebssystem (das nicht angepasst werden darf und kann) entwickeln und das Ergebnis dann auf ein aktuelles System schmeißen.
Meine spärlich vorhandenen C-Kenntnisse mische ich täglich mit einer Portion Phantasie und Mut und erzeuge daraus teils kompilierbaren Code. Aber das nur zum Thema Arbeitgeber. Ich bin froh, diesen Job zu haben und möchte das Beste draus machen. Mit den Mitteln, die ich eben zur Verfügung habe...
-
valgrind läuft ja leider nicht. Steht denke ich in meinem ersten Post. Valgrind ist installiert, bricht aber ab, weil die debuginfos bzw. das jeweilige Paket fehlt. gdb meckert auch reichlich, aber ist gnädiger und läuft wenigstens.
-
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.
