Nach dem setzen eines Breakpoints in Qt, gdb, sagt: "Fehler beim Zugriff auf Speicher-Adresse"

Schrieb ich ein sehr einfaches Qt-Programm hier:

int main(int argc, char* argv[])
{
    QApplication app(argc, argv);

    QTableView table(&frame);
    table.resize(100, 100);
    table.show();

    return app.exec();
}

Und wenn ich versuche, einen breakpoint zu setzen, wo die Tabelle geklickt wird, bekomme ich diese Fehler vom gdb:

(gdb) symbol-file /usr/lib/libQtGui.so.4.4.3.debug 
Load new symbol table from "/usr/lib/libQtGui.so.4.4.3.debug"? (y or n) y
Reading symbols from /usr/lib/libQtGui.so.4.4.3.debug...done.
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)'
Breakpoint 1 at 0x5fc660: file .moc/release-shared/moc_qabstractitemview.cpp, line 313.
(gdb) run
Starting program: ./qt-test
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x5fc660: Input/output error.

Weiß jemand, warum der Haltepunkt kann nicht eingefügt werden?

Ich bin mit Ubuntu Intrepid, und habe ich installiert libqt4-dbg, wenn das hilft überhaupt.

InformationsquelleAutor Neil | 2009-05-26

  1. 2

    Wenn Sie möchten, um automatisch Pause im main ohne setzen eines Breakpoints können Sie auch den start Befehl.

    Wenn Sie brauchen, um alle Argumente an das Programm, das Sie verwenden können:

    start argument1 argument2

    InformationsquelleAutor Andy

  2. 11

    Nicht verwenden die gdb-Befehl symbol-file laden von externen Symbole. Der Haltepunkt-Adressen falsch sein, da Sie nicht verlegt.

    Stattdessen setzen Sie einen Haltepunkt in main führen Sie das Programm, und legen Sie dann Ihren Haltepunkt:

    gdb ./program
GNU gdb 6.8-debian blah blah blah
(gdb) br main
Breakpoint 1 at 0x80489c1
(gdb) run
Starting program: ./program
Breakpoint 1, 0x080489c1 in main ()
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)'
Breakpoint 2 at 0xb7d24664
(gdb) continue
Continuing.

    Dann machen Sie Ihren Haltepunkt passieren.

    Stellen Sie sicher, dass Sie den parameter-Liste in der Funktion, in der Sie einen breakpoint setzen möchten, ohne die Namen dieser Parameter, nur Ihre Arten.

    Dank pholklore in #gdb irc.freenode.net für diese Antwort.
    Sie können auch nur einen Haltepunkt auf was auch immer Sie mögen, ohne zu brechen auf main() wird zuerst, und gdb werden Sie Fragen, ob Sie möchten, um einen anstehenden Haltepunkt. Jedoch, auf diese Weise können Sie nie sicher sein, ob diese Funktion tatsächlich vorhanden ist, oder wenn Sie einen Tippfehler gemacht. So ist die Methode, dargestellt in der Antwort sicherer.
    Diese Feste einige seltsame Probleme, die ich hatte; vielen Dank.

    InformationsquelleAutor Neil

  3. 4

    Den tatsächlichen Fehler:

    Fehler beim Zugriff auf Speicher-Adresse 0x5fc660: Input/output error.

    Kann verursacht werden, von der 32/64-bit-mixups. Prüfen Sie beispielsweise, dass Sie nicht Anhängen zu einem 32-bit-Binärdatei, die mit einer 64-bit-Prozess die ID' s, oder Umgekehrt.

    Ich habe dieses problem, aber ich kann nicht herausfinden, wie zu machen, verwenden Sie gdb, richtig 🙁
    Und Bitanzahl-mismatch ist nicht das problem?
    Scheint, dass ich hatte, um die -g option, um das makefile, und das problem behoben. Fand es irgendwo auf stackoverflow, aber ich weiß nicht, was es tut.

    InformationsquelleAutor Nathan Kidd

  4. 1

    OK für mich, habe ich diese beim erstellen mit mingw-w64 (native oder cross-compiler).
    Ich bin mir nicht sicher, was das genaue problem war, aber wenn Baue ich es mit gcc-mingw-w64 i686-5.1.0-posix-sjlj-rt_v4-rev0 dann schafft es (endlich) eine debug-Version einer baut. Ansonsten 

    (gdb) break main
...
(gdb) r
...
Cannot insert breakpoint 1.
Cannot access memory at address 0x42445c
<process basically hangs>

    Meldung 19 mal von 20, aber manchmal war es tatsächlich funktioniert (sehr selten).

    gdb 7.8.1 und 7.9.1 schien in der Lage sein, um das Debuggen der erstellten exe-Datei. So ist es wohl nicht die version von gdb, der einen Unterschied macht.

    Meine aktuelle Theorie/Vermutung entweder war es die gcc-version, oder vielleicht die, die sljl vs. dwarf2 "Aspekt" an den compiler, [?] (i686-492-posix-Zwerg-rt_v3-rev1 hat nicht funktioniert, und cross-Compilierung mit gcc 4.9.2 nicht entweder). Habe nicht versucht, andere Versionen von gcc.

    update: neuere gcc (5.1.0), aber cross-kompilieren ich habe immer noch den Fehler an. Die Ursache in diese Fall stellte sich heraus, dass eine Abhängigkeit, die Bibliothek, die mein build (FFmpeg) wurde mit Hilfe von Verknüpfung vor (libgme in diesem Fall) ist der Export von ein paar fehlgeleiteten "shared" - Symbole (wenn ich Baue eine statische ausführbare Datei). Weil dieses "gemeinsame" baut Bremse (https://trac.ffmpeg.org/ticket/282) und irgendwie Schrauben Sie den gdb als gut. Zum Beispiel möglicherweise die Verknüpfung gegen SDL können dies tun, um Sie als gut. Mein Gedanke ist möglicherweise eine ld Fehler [?]

    InformationsquelleAutor rogerdpack

Schreibe einen Kommentar