[Gelöst] Qt ohne argc und argv.

Hallo,

ich möchte ein paar Qt Funktionen aus Common Lisp (CL) verwenden. Dort habe ich aber keinen Zugriff auf argc und argv . Wenn ich den Code

extern "C"
void init_gui()
{
    int* argc = new int;
    *argc = 1;
    char** argv = new char*[2];
    argv[0] = strdup("dummy");
    argv[1] = NULL;

    QApplication* app = new QApplication(*argc, argv);
}

aus CL aufrufe, dann stürzt mein Programm später mit einem Speicherfehler ab. Wenn ich die Zeile in der QApplication erzeugt wird auskommentiere, dann habe ich keine Probleme. Irgendwie scheint beim erzeugen von QApplication an Speicherstellen geschrieben werden, wo nicht geschrieben werden dürfte.

Sieht hier jemand in dem Code einen Fehler (abgesehen von den Memory-Leaks)?

Edit: Funktion umbenannt.

Mechanics

Zumindest den int brauchst nicht auf dem Heap anlegen Probiers irgendwie so:

int argc = 1;
char * argv[] = {"dummy", NULL};

Okay... Die Funktion heißt hier main_loop . Eigentlich wollte ich eine Funktion init_gui haben, d.h. das QApplication-Objekt existiert auch nach Beendigung der Funktion noch. Laut Dokumentation, muss aber argc und argv so lange referenzierbar sein, bis die Anwendung beendet wurde. Darum auf dem Heap.

Die statische Initialisierung funktioniert nicht, da Qt erwartet, dass es argv ändern darf. D.h. ich darf nicht, mit einem const char* Initialisieren.

Mechanics

Hmm, siehst du im Callstack, was genau das Problem ist? Worauf will er da genau zugreifen?

Das Problem ist, dass das Programm erst abstürzt, wenn ich nachdem ich init_gui aufgerufen habe, ein externes Programm starten will.

Und das sind die einzigen beiden Dinge, die das CL Programm macht.

CORRUPTION WARNING in SBCL pid 4220(tid 140737353926400):
Memory fault at e1 (pc=0x41fb20, sp=0x7ffff6e264f8)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.

debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread
#<THREAD "main thread" RUNNING {1002978DE3}>:
  Unhandled memory fault at #xE1.

Mehr Informationen bekomme ich nicht, da sich SBCL nicht mit dem gdb debuggen lässt.

Mechanics

Bekommst du keinen core dump?

Ich wüsste nicht wie. Wenn ich mit dem gdb mich an den SBCL anhänge, fange ich eine Menge Seg-Faults ab, die aber vollkommen okay sind und nur dazu führen, dass irgendeine Datei noch nachgeladen wird. D.h. SBCL fängt alle Seg-Faults. Und ein Stack-Trace liefert nur eine Liste von Pointern ohne Funktionsnamen.

Ich habe das Problem gelöst. Ich habe folgenden Kommentar im Quelltext von commonqt gefunden:

;; Workaround for Qt+SBCL SIGCHLD handler conflict.
;; In its SIGCHLD handler Qt invokes the old handler with
;; signal argument only, so in case when SA_SIGINFO is used
;; it receives bad values as its siginfo and context
;; arguments. In case of SBCL this causes memory fault
;; e.g. when using SB-EXT:RUN-PROGRAM. Here we disable
;; the handler that causes that fault (SB-EXT:RUN-PROGRAM
;; still works after that). Thanks to nyef on #lisp.
;; See also: src/corelib/io/qprocess_unix.cpp in Qt
#+(and sbcl (not windows))
(sb-sys:enable-interrupt sb-unix:sigchld :default)