2.8.0 startet nicht

[sagu]

Hallo zusammen,

ich habe längere Zeit problemlos mit theli-gui 2.6.1 (oder war's .2 - vergessen :/) gearbeitet, bis ich vor einer Woche oder so gesehen hatte, dass sowohl gui als auch pipeline aktualisiert wurden. Ich konnte Beide ohne Fehler kompilieren und installieren, bekomme aber beim Starten nun plötzlich (nachdem der Splashscreen erscheint) die folgende Fehlermeldung:

Code: Alles auswählen

sascha@mizar:~/apps/theli/gui-2.8.0$ ./theli
*** Error in `./theli': free(): invalid pointer: 0x0000000000abcfa0 ***
*** Error in `./theli': malloc(): memory corruption (fast): 0x00000000009fdc00 ***


dann passiert nichts mehr...Splashscreen bleibt hängen - kann aber noch mit Strg+C beendet werden.
Irgendeine Idee was das sein könnte?

Was ich schon versucht habe:

• alle Einstellungen (~/.theli + ~/.qt/theli*) gelöscht -> kein Erfolg
• Im .pro-File debug-build aktivieren, um dem Problem auf die Spur zu kommen -> das schlägt leider mit zig-Linker-Fehlern fehl

mein Linux ist ein debian/unstable (64bit) - hier ein paar Versionsnummern:

Code: Alles auswählen

sascha@mizar:~$ gcc --version
gcc (Debian 4.8.1-9) 4.8.1


Code: Alles auswählen

sascha@mizar:~$ ldd /home/sascha/apps/theli/gui-2.8.0/theli
        linux-vdso.so.1 (0x00007fffe71ff000)
        libqt.so.3 => /usr/src/qt-x11-free-3.3.8b//lib/libqt.so.3 (0x00007fc6963f6000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fc6961b7000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fc695e7b000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc695b78000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc69587a000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc695663000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc6952b7000)
        libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007fc6950b0000)
        libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007fc694e94000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc694c90000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fc694a71000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc696e65000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fc694a6a000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fc694866000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fc694660000)


Gruß S. (der sein altes theli natürlich schon nach /dev/null verschoben hat

[mischa]

mein Linux ist ein debian/unstable (64bit)

Hi Sascha,

da es bisher bei allen anderen die die 2.8.0 haben problemlos laeuft, sage ich mal, dass eine 'unstable' Linux Version keine gute idee ist (gilt auch allgemein). Ich kann dir also nicht weiterhelfen...

Mischa

[sagu]

Hallo Mischa,

ich glaub ich hab's gefunden

Habe die Executable mal mit valgrind laufen lassen - da kann man auch ohne Debug-Symbole wenigstens sehen, in welcher Funktion der segfault sitzt => in theliform.ui.h muss m.E. in Zeile 217 'ne 6 stehen - keine 8 - das Array hat nur 6 Elemente.

Wenn ich das ändere läuft's dann auch. Warum sich das nur bei mir so zeigen soll ist mir schleierhaft, ich denke das liegt vielleicht wirklich an meiner gcc-version. Ansonsten hört sich unstable gefährlicher an, als es ist - ich benutze es seit vielen Jahren und habe nur sehr selten Probleme.

Gruß S.

[mischa]

Habe die Executable mal mit valgrind laufen lassen - da kann man auch ohne Debug-Symbole wenigstens sehen, in welcher Funktion der segfault sitzt => in theliform.ui.h muss m.E. in Zeile 217 'ne 6 stehen - keine 8 - das Array hat nur 6 Elemente.

Hi Sascha,

vielen Dank fuer den Fund! Das hat sich dort im Mai 2013 eingeschlichen mit einer grossen Umstrukturierung. An etwa gefuehlt 100 anderen Stellen habe ich die Indizierung richtig gesetzt, aber hier nicht. Mit der Version hatte ich intern drei Monate ohne Probleme gearbeitet ehe ich sie Anfang August freigegeben habe. Normalerweise sollte das wie bei dir beim Programmstart sofort zu einem segfault fuehren. Warum es das nicht tat ist mir raetselhaft, muss wohl mit deinem neueren Compiler zu tun haben. Das entsprechende array ist statisch deklariert, ich wuerde meinen dass das der Compiler eigentlich gleich zu Beginn erkennen sollte, da ich explizit drueber hinauslaufe. Das muss ich mal an einem Beispiel testen.

Ich werde noch heute ein update hochladen.

mischa

[mischa]

Hallo,

das Update ist draussen. Danke nochmal an Sascha!

Mischa

[mischa]

Hi Sascha,

rein zur Info, falls es dich interessiert... ich hab eben mal folgendes Beispiel geschrieben:

Code: Alles auswählen

int main()
{
  int ext[6], i;

  for (i=0; i<8; i++) {
    ext[i] = i;
    cout << ext[i] << endl;
  }
  return 0;
}


Entgegen meiner Erwartung und Erfahrung laeuft das (mit g++ v4.6.3 compiliert) problemlos. Selbst wenn ich den compiler auf 'pedantic' stelle, wird das bei der Compilierung nicht erkannt. Was noch schlimmer ist, der memory checker in valgrind (v3.8 ) erkennt es auch nicht! Ich hab dann auf wikipedia zu valgrind folgenden Eintrag gefunden:

[...] an important limitation of Memcheck is its inability to detect all cases of bounds errors in the use of static or stack allocated data.

Danach wird ein Beispiel aufgelistet, welches dem obigen sehr aehnlich ist, sowie eine -- in den man-pages undokumentierte -- experimentelle Option namens

Code: Alles auswählen

--tool=exp-sgcheck

, die diesen Fehler entdeckt (was ich bestaetigen kann). Das hat mich sehr ueberrascht. Ich lasse valgrind praktisch ueber jeden neuen release von Theli drueberlaufen, und auch ueber alle andere software welche ich schreibe, da es sehr pedantisch ist und, so dachte ich bisher, praktisch alles findet. Nur wohl offenbar keine out-of-bounds Fehler in statisch deklarierten arrays. Ich dachte das waere der einfachste Fall im Vergleich zu dynamischen arrays, die ich meistens verwende. Wieder was gelernt...

mischa

[sagu]

Hallo Mischa,

ich freue mich sehr, dass theli bei mir wieder läuft - bei der aktuellen Schönwetterkatastrophe wüsste ich sonst gar nicht wohin mit den vielen Daten

Zu Deinem Beispiel:
Ein C-Compiler *kann* sowas prinzipbedingt nicht erkennen. Ob das Programm am Ende wirklich "segfaultet" hängt ziemlich empfindlich von allen möglichen Randbedingungen ab - solange man nur Speicher überschreibt, der dem Programm gehört, passiert auch nichts. Am Ende hilft es nur, Container-Klassen(-templates) zu verwenden, die sowas sauber abfangen.

Falls Du bei der Portierung von theli irgendwelche Hilfe oder Rat gebrauchen kannst, würde ich Dir gerne meine Unterstützung anbieten - habe relativ viel Erfahrung mit Qt


Gruß S.

[mischa]

Falls Du bei der Portierung von theli irgendwelche Hilfe oder Rat gebrauchen kannst, würde ich Dir gerne meine Unterstützung anbieten - habe relativ viel Erfahrung mit Qt

Hi Sascha,

danke fuer das Angebot, da werde ich mit Sicherheit auf dich zurueckkommen. Mit Qt3 musste ich an mehreren Stellen laestige Umwege machen, die ich in Qt5 gerne loswerden wuerde. Da kommt ein externer Standpunkt, den ich anzapfen kann, gerade recht. Bis ich anfangen kann, das GUI selbst zu portieren, werden noch ein paar Monate vergehen. Bis dahin raeume ich den alten Spaghetti Code auf, z.B. in den fitstools. An die gaengigen Standards habe ich mich damals als Schmalspurprogrammierer nicht gehalten (getreu dem Motto Hauptsache es laeuft). Jetzt wird alles sauber in C++ neu geschrieben, dann klappts auch hoffentlich mit MacOS.

mischa

[frasax]

Hi Mischa,

dann klappts auch hoffentlich mit MacOS.

an dem Tag werde ich vermutlich eine kleine Fiesta feiern:-) Da bin ich ja gespannt!

CS Frank

[selste]

Hi,

[...]
Bis ich anfangen kann, das GUI selbst zu portieren, werden noch ein paar Monate vergehen. Bis dahin raeume ich den alten Spaghetti Code auf, z.B. in den fitstools. An die gaengigen Standards habe ich mich damals als Schmalspurprogrammierer nicht gehalten (getreu dem Motto Hauptsache es laeuft). Jetzt wird alles sauber in C++ neu geschrieben, dann klappts auch hoffentlich mit MacOS.
mischa

wenn Du 'Opfer' für Tests brauchst, bin ich gerne mit dabei, sagst einfach Bescheid - hast Dir schon Gedanken über die Nutzung eines Frameworks mit C++ gemacht (boost o.ä.)?
Gruß,

Steffen

[mischa]

wenn Du 'Opfer' für Tests brauchst, bin ich gerne mit dabei, sagst einfach Bescheid - hast Dir schon Gedanken über die Nutzung eines Frameworks mit C++ gemacht (boost o.ä.)?

Ihr seid ohnehin alle meine Opfer, hehe
Ich bleibe bei Qt5, auf etwas anderes umzustellen waere viel zu viel Aufwand, da die ganze Infrastruktur bereits vorliegt und ich mich in der Bibliothek auskenne. Qt Creator 2.8.0 scheint ein sehr gutes IDE zu sein, das gab es damals fuer Qt3 noch nicht.

mischa

[selste]

Ah,

[...]
Ich bleibe bei Qt5, auf etwas anderes umzustellen waere viel zu viel Aufwand, da die ganze Infrastruktur bereits vorliegt und ich mich in der Bibliothek auskenne. Qt Creator 2.8.0 scheint ein sehr gutes IDE zu sein, das gab es damals fuer Qt3 noch nicht.
mischa

ich meinte auch nicht die GUI, dass Du da bei Qt bleibst (auch wenn der Wechsel von 3 auf 5 sicher net einfach ist) ist klar
Bezog mich mit der Frage eher auf den 'Klebstoff', um so Sachen wie die fitstools sauber einzubinden - Datenstrukturen, Reference Counter und so Zeuch.

BTW - einen SEGFAULT bekomme ich bei Theli auch jedes Mal, wenn ich die Anwendung beende ... da stört es allerdings net; hab mich aber auch noch nicht aufraffen können, das mal genauer anzuschauen.
Gruß,

Steffen

[mischa]

Hi Steffen,
Bezog mich mit der Frage eher auf den 'Klebstoff', um so Sachen wie die fitstools sauber einzubinden - Datenstrukturen, Reference Counter und so Zeuch.

BTW - einen SEGFAULT bekomme ich bei Theli auch jedes Mal, wenn ich die Anwendung beende ... da stört es allerdings net; hab mich aber auch noch nicht aufraffen können, das mal genauer anzuschauen.

Die fitstools sind unabhaengig von Theli entwickelt worden, die verwende ich fuer viele andere Sachen auch. Das sollte als externes Modul betrachtet werden, genauso wie Scamp oder Swarp oder Sextractor.
Das GUI sieht diese tools nicht, die werden lediglich innerhalb der scripten aufgerufen, welche die eigentliche Datenreduktion machen. Das GUI ist lediglich auf die Skripten aufgepfropft, um deren Anwendung bequemer zu gestalten.

Der segfault am Ende ruehrt daher, dass eines der grafischen Elemente des GUI zweimal freigegeben wird. Welches das ist konnte ich nie rausfinden. Da Qt das ohne mein Zutun macht, betrachte ich es als bug, der in Qt5 sicherlich verschwunden sein wird.

mischa