[solved] Segmentation fault bei QFont

[katoon]

Also ich benutze folgenden Code:

Code: Alles auswählen

void sproDialogImpl::abort_scan()
{
        if ((fd = open( scan_device_filename, O_WRONLY )) < 0)
        {
          textBrowser_status->append("Scanning not implemented on this   ");
        }
        else
        {
                textBrowser_status->append("open xypos");
        }

        if (ioctl( fd, DAQ_SCAN_ABORT ) < 0)
        {
          textBrowser_status->append("Scanning not implemented on this system");
        }
        else
        {
                textBrowser_status->append("abort scan");
        }

        close( fd );

}

und kompilliert wird mit gcc v2.96 ohne Probleme.
Starte ich es und benutze diese Funktion stürzt das ganze ab mit Speicherzugriffsfehler (core dumped).

gdb liefert folgendes:

Program received signal_SIGSEV, Segmentation fault,
0x402cabb2 in QFont::~QFont() from /usr/local/qt-x11-free-3.2.1/lib/libqt.so.3

An was genau könnte das liegen. Andere Programme laufen tadellos und benutzen auch QFont. wenn es überhaupt an QFont liegt ??

Die Zeile if (ioctl( fd, DAQ_SCAN_ABORT ) < 0) muss auch noch ausgeführt werden weil ich das Ergebniss davon noch auf einem Oszilloskop zu sehen bekomme
Mir ist das schleierhaft, hilft vielleicht eine neuinstallation ????

[PeterLustig]

Meistens liegt ein seg fault an einem nicht richtig initialisiertem Objekt.

[macman]

Also ich benutze folgenden Code:

Nächstes Mal in Code-Tags, dann kann man es auch vernünftig lesen.

An was genau könnte das liegen. Andere Programme laufen tadellos und benutzen auch QFont. wenn es überhaupt an QFont liegt ??

In deinem Codeschnipsel sehe ich überhaupt nichts von QFont, wieso sollte es also da drin passieren?

Mir ist das schleierhaft, hilft vielleicht eine neuinstallation ????

Klar, neu installieren hilft immer, am besten gleich das ganze System

Ich kenne gdb nicht, aber gibt es da nicht so was wie eine Aufrufliste? Dann könntest Du sehen welcher deiner Funktionen zuletzt aufgerufen wurde und da würde ich dann anfangen.

Übrigens, Du plenkst und dein Fragezeichen prellt.

[katoon]

In meinem ganzen Programm taucht nix mit QFont auf trotzdem spuckt der Debugger diese Fehlermeldung aus.
Auf die Neuinstallation bin ich auch nur gekommen weil ich mir keinen Reim darauf machen kann und der Fehler wohl an Qt selber liegt denn dieser Codeschnipsel ist mein Programm. Was anderes kommt einfach nicht drin vor.

[Christian81]

Mit dem Debugger starten und einen Backtrace posten.

[katoon]

Code: Alles auswählen

Program received signal SIGSEGV, Segmentation fault.
0x402cabb2 in QFont::~QFont () from
/usr/local/qt-x11-free-3.2.1/lib/libqt.so.3
(gdb) bt
#0  0x402cabb2 in QFont::~QFont ()
   from /usr/local/qt-x11-free-3.2.1/lib/libqt.so.3
#1  0x4033d9a5 in QWidget::~QWidget ()
   from /usr/local/qt-x11-free-3.2.1/lib/libqt.so.3
#2  0x40480715 in QDialog::~QDialog ()
   from /usr/local/qt-x11-free-3.2.1/lib/libqt.so.3
#3  0x0804d354 in sproDialog::~sproDialog ()
#4  0x0804b99b in main ()
#5  0x40a5d777 in __libc_start_main (main=0x804b930 <main>, argc=1, 
    ubp_av=0xbffff644, init=0x804adf0 <_init>, fini=0x804df50 <_fini>, 
    rtld_fini=0x4000dd34 <_dl_fini>, stack_end=0xbffff63c)
    at ../sysdeps/generic/libc-start.c:129

ok hier der backtrace des gdb. Aber nun seh ich gar nicht mehr durch. Lass ich die obige Funktion weg oder zumindest die ioctl Aufrufe funktioniert alles prima. Keine Ahnung warum die sich nicht verstehen.
Allerdings muss ich sagen, das der Code komplett ausgeführt wird, soviel ist sicher, aber irgendwie funktioniert die "Rückgabe" an das Dialogfeld nicht richtig.

[Christian81]

Dann bitte deine Definition des Header der sproDialog-Klasse und den destruktor.

[katoon]

In der zip Datei sind die relevanten Daten. Vielen Dank das du dir das mal anschaust. Ich hoffe du findest einen Fehler.

Ich habe den Code auch nochmal in ein anderes Programm eingefügt wodurch das dann auch abgestürzt ist sobald ich die Funktion ioctl benutze. Warum auch immer aber irgend wie verträgt sich mein QT nicht mit diesem Aufruf

[Christian81]

Jetzt sehe ich zumindest einen Fehler - wenn open() nicht funktioniert arbeitest Du trotzdem mit dem zurückgegeben Wert weiter.

[solarix]

du rufst das falsche close auf.. nicht

Code: Alles auswählen

int close(int fildes);

sondern

Code: Alles auswählen

bool QWidget::close ( bool alsoDelete ) [virtual]

Ist natuerlich hubsch, wenn der (erste) open() gleich fd=1 ergibt....

[katoon]

Vielen Danke für eure Hilfe.

@Christian81
Ja den Fehler habe ich nicht bemerkt. Das wurde korriegiert aber das war nicht das Problem.

Was den Absturz verursacht, ist die close-Funktion. Sie soll eigentlich die Datei nach dem Bearbeiten wieder schliessen. Vielleicht wird diese im Zusammmenhang mit QT fehlinterpretiert, who knows.
Während ich mit open und close meine Datei öffnen und schliessen will versucht QT wahrscheinlich damit Widget zu schliessen, was dann schief geht.
Etwas ähnliches hatte ich schon mit connect im Zusammenhang mit Socket Programmierung und der SIGNAL-SLOT-Methode, allerdings war es da offensichtlich.
Da ich für ioctl einen Dateizeiger brauche und QFile mir keinen dafür liefert, wobei ich mir allerdings nicht sicher bin, werde ich mal folgendes versuchen

Code: Alles auswählen

#ifndef WIN32
     int closefile(int filedes)
#endif
{
     return close(filedes);
}

[Christian81]

::close()

[franzf]

Da ich für ioctl einen Dateizeiger brauche und QFile mir keinen dafür liefert, wobei ich mir allerdings nicht sicher bin, werde ich mal folgendes versuchen

Ich bin mir nicht sicher aber vllt ist ja int QFile::handle () const das was du suchst?

[Christian81]

Ich bin mir nicht sicher aber vllt ist ja int QFile::handle () const das was du suchst?

Nein, bitte nicht. Unter Windows kommt da entweder ein posix oder Windows-Handle oder 0 zurück... seeehr gefährlich...

[solarix]

Vielleicht wird diese im Zusammmenhang mit QT fehlinterpretiert, who knows. [...]
Während ich mit open und close meine Datei öffnen und schliessen will versucht QT wahrscheinlich damit Widget zu schliessen, was dann schief geht.

"who knows"?!? Da wird gar nichts "fehlinterpretiert" oder "versucht". Das ist ganz normales C++! Dem Compiler stehen an dieser Stelle zwei Methoden zur Auswahl, wobei er die "naheliegendere" (die im aktuellen Namespace) nimmt (siehe chr81 wie's richtig gemacht wird).