ich arbeite seit einiger Zeit an einer multithreaded Server Applikation. Diese verwendet Bibliotheken für ihre Funktionalitäten.
Dies geht auch schon soweit ganz gut, doch hin und wieder crasht die Anwendung und schließt sich ohne weitere Informationen.
Da ich aus der verwöhnten Borland Welt komme mit bpls, gestallte sich das debuggen schwer.
Ich kompiliere die exe/dlls mit Debuger-Informationen und starte sie im gdb.
Bei jedem Aufruf ein Funktionalität sag mir gdb Folgens. Doch starte ich die Applikation ohne gdb kommt es zu keinem Fehler.
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to thread 9516.0x2620]
0x7c911231 in ntdll!DbgUiConnectToDbg () from ntdll.dll
(gdb) bt
#0 0x7c911231 in ntdll!DbgUiConnectToDbg () from ntdll.dll
#1 0x7c97c943 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll
#2 0x018cf7f0 in ?? ()
#3 0x7c97cd80 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll
#4 0x00177470 in ?? ()
#5 0x00080000 in ?? ()
#6 0x00000001 in ?? ()
#7 0x018cf844 in ?? ()
#8 0x7c97e69b in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll
#9 0x00080000 in ?? ()
#10 0x00177470 in ?? ()
#11 0x7c97e74c in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll
#12 0x00080000 in ?? ()
#13 0x00176bc8 in ?? ()
#14 0x00177478 in ?? ()
#15 0x004f2c47 in WIN32ANSICOMPARETEXT (S1=, S2=)
Previous frame inner to this frame (corrupt stack?)
Das hat nichts mit deinem bug zu tun !
Diese fehler sind gdb intern und treten willkürlich auf jedenfalls alles was mit ntdll!DbgUiConnectToDbg () zu tun hat. Möglichweise hat ntdll!RtlpNtMakeTemporaryKey () was mit deinem bug zu tun würd ich aber nicht von ausgehen.
wiso startest du das executable seperat im gdb ? kannst doch in den ide machen.
Es gibt ein tool weiss nicht mehr genau wies heisst ist ne unit die dir funktionen zum ausgeben von variablen und so weiter zur verfügung stellt.
und n programm wenn du das startest werden die die variablen und alles was du mit den funktionen druchreichst angezeigt. Quasi n debugserver ohne das das programm läuft wird lediglich eine variable abgefragt macht also kaum laufzeitunterschiede bzw kannst den kram auch nacher in den executabled drin lassen. Bei grossen projekten empfielt sich sowas habs aber selbst noch nicht ausprobiert. Der vorteil ist das das programm nicht durch den debugger beeinflusst wird hatte schon ein paar mal das im debugger alles lief und real nicht weil etwas zu schnell ablief z.b. microcontrollerkommunikation.
Verein
Links
