gdb hält nicht an Memory Watchpoint [SOLVED]

benediktibk · Feb 27, 2012

Falls es noch nicht aufgefallen sein sollte, momentan habe ich es mit dem armen gdb. Oder ich bin der Arme, aber das wollen wir jetzt nicht diskutieren.

Das Problem ist folgendes: Ich habe eine Anwendung, in der ein Wert einen ziemlich eigenartigen Wert annimmt, den ich mir nicht erklären kann (und der zu einem Segfault führt). Deswegen habe ich den gdb angeschmissen und einen Watchpoint auf gesagten Speicher gesetzt, ABER der gdb hält nicht an:

Code:

benediktibk@speedy-iii-gentoo ~ $ gdb /opt/been/been-test
GNU gdb (Gentoo 7.3.1 p2) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /opt/been/been-test...done.
(gdb) break ProjectConfiguration::ProjectConfiguration
Function "ProjectConfiguration::ProjectConfiguration" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (ProjectConfiguration::ProjectConfiguration) pending.
(gdb) r /opt/been/libtestconfiguration.so 
Starting program: /opt/been/been-test /opt/been/libtestconfiguration.so

Breakpoint 1, ProjectConfiguration::ProjectConfiguration (this=0x6183c0, subProjectNames=..., options=..., projectDefinition=..., directory=...)
    at source/projectconfiguration.cpp:7
7           m_projectName(directory.getNameOfParentDirectory())
(gdb) n
9               subProjectNames = parseDefinition(projectDefinition);
(gdb) print &(this->m_directory.m_extension.m_size)
$1 = (unsigned int *) 0x7fffffffd5e4
[B](gdb) print *(unsigned int *) 0x7fffffffd5e4
$2 = 0
(gdb) watch (unsigned int *) 0x7fffffffd5e4
Watchpoint 2: (unsigned int *) 0x7fffffffd5e4
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000021 in ?? ()
(gdb) print *(unsigned int *) 0x7fffffffd5e4
$3 = 32767[/B]
(gdb)

Weiß zufällig jemand woran das liegt? Irgendwelche Bedienungsfehler?

mfg benediktibk

Hackse · Feb 27, 2012

Du versuchst über den Debugger auf ein Shared-Object Module zuzugreifen. Kannst Du verifizieren, dass auch das Shared-Object Module mit "-gstabs" kompiliert wurde und Debugging-Infos für den GDB enthält? Andernfalls funktioniert Dein Vorhaben nicht.

Du könntest mit der "list"-Funktion Source mit Zeilennummern anzeigen lassen, dann via "break <Zeilennummer>" eine Zeile vor den Funktionsaufruf springen und schließlich mit "step" in die Funktion hineinspringen.

benediktibk · Feb 28, 2012

Wenn ich nur mit -gstabs kompiliere wird das Debuggen problematisch, dann habe ich scheinbar keinen Zugriff mehr auf den gesuchten Member. Es befindet sich in einer Basisklasse und ist dort protected. Mit -gstabs+ hingegen konnte ich auf den Member im Debugger dagegen zugreifen, nur ist das Problem immer noch das gleiche.

Falls ich das richtig verstanden habe hilft mir der zweite Vorschlag nicht weiter, da ich eben nicht weiß, wo der Wert geändert wird. Die Variable hat plötzlich den Wert 2^15-1 anstelle von 0 und ich versuche eben herauszufinden, wo der Speicherbereich da beschrieben wird.

mfg benediktibk

benediktibk · Feb 29, 2012

Der Bug sitzt einmal wieder 50 cm vor dem Bildschirm.
Zum setzen eines Memory Watchpoints braucht es folgende Anweisung:

Code:

watch [COLOR="Red"]*[/COLOR](unsigned int*)0x7fffffffd5e4

Das war für mich irgendwie unlogisch, da der Prozessor zur Überwachung ja wieder die Speicheradresse braucht, deswegen habe ich das Sternchen absichtlich weggelassen. Keine Ahnung auf was er dann gewartet hat, auf jeden Fall nicht auf das, was ich wollte. So funktioniert der Watchpoint aber tadellos, jetzt muss ich nur noch den bösen Bug finden. Der lustige Teil kommt also noch ... :wink:

Danke Hackse für die Antwort,
benediktibk