Debugger stürzt ab beim Anzeigen zu großer Variablen

Für Fragen rund um die Ide und zum Debugger
br_klaus
Beiträge: 244
Registriert: Do 21. Jan 2010, 22:33
OS, Lazarus, FPC: Windows Vista (L 0.9.31 FPC 2.5.1)
CPU-Target: 32Bit
Wohnort: z.z. Brasilien, sonst 82335 Berg-Leoni (südlich von München)

Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von br_klaus »

Hallo,
ich habe ein kleines Problem mit dem Debugger.
Wenn ich folgendes definiere

Code: Alles auswählen

Type TDWArray = array[0..maxint div 4 -1] of Dword; PDWArray = ^TDwarray;
var p:PDWArray;
 
und dann im Programmtext irgendwo p^ vorkommt, dann stürzt der Debugger regelmäßig ab, sobald ich mit dem Cursor darüber fahre. Und wenn ich versuche, das beim Beobachtungsfenster einzufügen (als p^ alleine ), dann stürzt der Debugger schon beim Starten des Kompilierens ab.
Anscheinend will er die ganzen maxint div 4 Elemente auf einmal einlesen, und das geht natürlich nicht...
Wäre es nicht sinnvoll, in einem solchen Fall die Anzahl der zu zeigenden Elemente auf die Breite des Ausgabebildschirmes zu reduzieren. Daß man dann zB bei Angabe von p^[100] die nächsten Elemente ab p^[100] gezeigt bekommt, aber nur, solange sie auf den Bildschirm pasen (und dann bei Records möglichst ohne Angabe der Namen, nur die puren Daten, dann passt mehr auf den Schirm).
Herzlichen Dank!

martin_frb
Beiträge: 588
Registriert: Mi 25. Mär 2009, 21:12
OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
CPU-Target: mostly 32 bit

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von martin_frb »

Zum Array:

Sollte es nötig sein, nur einen teil des Array zu lesen (habe den Absturz noch nicht getestet), dann werden wahrscheinlich wie beim dynamischen array 5 oder 7 werte angezeigt.

In den watch-properties lässt sich dann ein größerer Wert einstellen.

Der Grund fuer den niedrigen default Wert: Array werte einzeln lesen ist sehr langsam. 100 Werte lesen kann dauern.

---
Mehr spaeter, wenn ich Zeit hab.

br_klaus
Beiträge: 244
Registriert: Do 21. Jan 2010, 22:33
OS, Lazarus, FPC: Windows Vista (L 0.9.31 FPC 2.5.1)
CPU-Target: 32Bit
Wohnort: z.z. Brasilien, sonst 82335 Berg-Leoni (südlich von München)

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von br_klaus »

Und warum nicht mehr anzeigen? Gerade wenn es nur einzelne Integerwerte sind, dann wäre es oft angenehm, noch mehr sehen zu können und nicht schon nach 5 Angaben bloß ....
Auch wäre es praktisch, auch bei einem einzelnen Wert eines dynamischen Arrays (besonders bei Darstellung mit Pointern, zB p^[10]), auch die nächsten 10,20 Werte zu zeigen.
Mich wundert eh, warum der Bildaufbau beim Zeigen der zu beobachtenden Werte sooo langsam ist. Ginge das nicht etwas schneller (man kann geradezu verfolgen, wie eine Zeile nach der anderen - von unten her, warum eigentlich das? - am Bildschirm erscheint).

martin_frb
Beiträge: 588
Registriert: Mi 25. Mär 2009, 21:12
OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
CPU-Target: mostly 32 bit

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von martin_frb »

br_klaus hat geschrieben:Und warum nicht mehr anzeigen? Gerade wenn es nur einzelne Integerwerte sind, dann wäre es oft angenehm, noch mehr sehen zu können und nicht schon nach 5 Angaben bloß ....
Auch wäre es praktisch, auch bei einem einzelnen Wert eines dynamischen Arrays (besonders bei Darstellung mit Pointern, zB p^[10]), auch die nächsten 10,20 Werte zu zeigen.
Gibt es in 1.1 als option. Aber nicht default

20 werte anzeigen, braucht so viel zeit wie 20 watches.
Mich wundert eh, warum der Bildaufbau beim Zeigen der zu beobachtenden Werte sooo langsam ist. Ginge das nicht etwas schneller (man kann geradezu verfolgen, wie eine Zeile nach der anderen - von unten her, warum eigentlich das? - am Bildschirm erscheint).
Bei mir erscheinen die Zeilen von oben. (6 oder 7 werte (integer) in der Sekunde.
Objecte, records, etc sind langsamer. (Schaetze 3-5 per Sek)
Dyn Array koenne sogar nur 1 per sek oder noch langsamer sein.

Achtung: In "Nested Procedures" kann die Geschwindigkeit sehr stark abnehmen (2 oder3 pro sek)


Die Zeit hängt damit zusammen, das die IDE mit gdb kommunizieren muss. Das ist kompliziert. Und oft liefert GDB nicht auf Anhieb den richtigen Wert, und dann muss aufwendig in mehreren Schritten gesucht werden.

Kann im Fenster "Debug Output" beobachtet werden.

Natürlich lässt sich vieles schneller machen, aber das erfordert viele Änderungen in der IDE, und das braucht halt zeit die zu programmieren.
Im Moment ist die Priorität "korrekte Daten" über "schnelle Daten" (schnelle inkorrekte, oder unvollständige Daten nützen wenig)

martin_frb
Beiträge: 588
Registriert: Mi 25. Mär 2009, 21:12
OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
CPU-Target: mostly 32 bit

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von martin_frb »

Bad news

So wie es aussieht, kann das in der nahen Zukunft nicht gelöst werden.

Das Problem GDB versucht 2 GB Speicher zu reservieren... Das betrifft *alle* GDB Versionen (getestet von 6.3 bis 7.5).

- Um das Problem zu vermeiden darf die IDE kein Kommando an GDB schicken, das den Fehler auslöst.
- Um aber kein solches Kommando zu schicken, muss die IDE wissen das eine variable auf ein solches Array zeigt.
- Dazu wuerde sie normalerweise GDB fragen "Welchen type hat var" => nur GDB stuerzt da schon ab. Aus einem nicht nachvollziehbaren Grund versucht GDB den Speicher zu reservieren, nur um den type zu ermitteln (obwohl keine Daten gefragt sind).

Ich habe alle mir bekannten Wege zur type Ermittelung, mit allen GDB Versionen versucht. Ohne Erfolg.

Wenn der type nicht feststellbar ist, kann die IDE den type nicht filtern.

---

theoretisch koennte die IDE den type selbst aus dem Quellcode ermitteln. Das ist aber:
1) nicht 100% zuverlässig (z.b wenn Quellcode verändert wurde)
2) lässt sich nicht kurzfristig umsetzen, da mehr arbeitsaufwendig

Zuverlässigkeit waere nicht das Problem, es waere ja schon gut wenn es 95% fixt. Aber der Arbeitsaufwand ist ein Problem.

martin_frb
Beiträge: 588
Registriert: Mi 25. Mär 2009, 21:12
OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
CPU-Target: mostly 32 bit

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von martin_frb »

Um den wert anzuzeigen kann man

^LONGWORD(p)[0]

als watch angeben.
Laz 1.1 kann dan auch 10 oder 20 werte ab dem index zeigen.

Nur die IDE kann das nicht automatisch machen, weil sie (zu mindest der Debugger-teil der IDE) nicht weiß das p ein solches array ist.

br_klaus
Beiträge: 244
Registriert: Do 21. Jan 2010, 22:33
OS, Lazarus, FPC: Windows Vista (L 0.9.31 FPC 2.5.1)
CPU-Target: 32Bit
Wohnort: z.z. Brasilien, sonst 82335 Berg-Leoni (südlich von München)

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von br_klaus »

Das ist ja hoch kompliziert! Wäre es da nicht höchste Zeit, den Code viel schlanker zu machen und alle unnötigen gegenseitigen Abfragen auszuschalten? (Wie sagt doch ein treffendes Sprichwort: viele Köche verderben den Brei)

Wie geschieht das denn bei delphi? Gibt es da auch diese so komplizierten gegenseitigen Abfragen, um (lokale) Variablen zegen zu können?
Würde es denn nicht reichen, wenn der Compiler beim Lesen des Quellcodes selber feststellen kann, um was für einen Typ es sich handelt (evtl. mit vartype von variants bei "einfachen" Daten), und dem enstprechend werden die Daten dann am Bildschirm ausgegeben. Wozu das Zwischenschalten von GDB, der/die/das das anscheinend so kompliziert macht?
Werde versuchen, etwas ähnliches zu programmieren und dann als Vorschlag zu posten...

Warum soll denn das Lesen des Quellcodes (wenn er verändert wurde) nicht zuverlässig sein? Es wird doch immer beim Kompilieren der gerade aktuelle (d.h. veränderte) Quellcode genommen (zumindest mache ich das bei mir immer so. Wie sollte ich sonst Fehler finden und meinen Code verbessern können?)

martin_frb
Beiträge: 588
Registriert: Mi 25. Mär 2009, 21:12
OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
CPU-Target: mostly 32 bit

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von martin_frb »

Delphi benutzt keinen externen Debugger, sondern erledigt das direkt.

Es gibt/gab verschiedene Versuche das fuer Lazarus auch so zu machen. Die sind aber alle noch weit von nutzbar entfernt.

Alles andere. Nein das hat nix mit schlankem code zu tun.... GDB ist nun mal einfach nicht gut im Umgang mit Pascal. Aber derzeit gibt es keine Alternative zu GDB...

martin_frb
Beiträge: 588
Registriert: Mi 25. Mär 2009, 21:12
OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
CPU-Target: mostly 32 bit

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von martin_frb »

br_klaus hat geschrieben: Warum soll denn das Lesen des Quellcodes (wenn er verändert wurde) nicht zuverlässig sein? Es wird doch immer beim Kompilieren der gerade aktuelle (d.h. veränderte) Quellcode genommen (zumindest mache ich das bei mir immer so. Wie sollte ich sonst Fehler finden und meinen Code verbessern können?)
Manche Leute editieren den Code, waehrend der Debugger laeuft. Aber wie gesagt, das ist nebensaechlich.

Der Debugger bezieht seine Info von den stabs/dwarf. (Das gilt auch fuer Delphi, da heisst das nur anders).

---
Wie gesagt, es ist nicht, das das Problem nicht loesbar ist. Es ist nur in jedem Falle sehr Aufwendig und daher nicht in kurzer Zeit.

Dazu kommt, das derzeit solche grossen Änderungen nicht in meinen Termin Kalender passen. D.h das egal wie, ich die Sache erst spaeter ueberhaupt angehen werde.

br_klaus
Beiträge: 244
Registriert: Do 21. Jan 2010, 22:33
OS, Lazarus, FPC: Windows Vista (L 0.9.31 FPC 2.5.1)
CPU-Target: 32Bit
Wohnort: z.z. Brasilien, sonst 82335 Berg-Leoni (südlich von München)

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von br_klaus »

Hier mein Vorschlag, wie man das Problem angehen könnte. (Habe schon gestern abend daran getüftelt, konnte aber nicht ausprobieren, ob es funktioniert, weil ich nicht weiß, wie genau der Compiler die Informationen aus dem Quelltext liest. Das muß ich Dir überlassen, diese fehlenden Programmteile zu programmieren.

Mein Ansatz ist, bei RecordArrays die Recordstruktur nur ein einziges Mal einzulesen (in das array recs), dazu bräuchte es dann variants o.ä., und dann so oft wie gewünscht daraus einen String zu erstellen für jeden Record und diesen am Bildschirm ausgeben.
Dann könnte man auch schon bei der Angabe im Watch-Fenster nach dem Variablennamen,
durch Komma getrennt, die gewünschten Optionen angeben:
10 = die nächsten 10 Records bzw Datenfelder
3h4 = 3x als HexZahl zu 4 Bytes, mit $ zu Beginn, nicht 0x, das spart ein Byte (- oder gleich ganz ohne)
3L oder 3z = 3 Zeilen lang ausgeben, eingerückt ab hinter dem Namen der Variablen, wie in meinem Programm unten)
b = Byte, c=Char, d=dezimal, sh=shortint, sm=smallint, w=word, i=integer, dw=Dword, qw=qword, i64=int64
zB: 12sh = 12 x shortint; 4li = 4 Zeilen lang als Integer; etc.


Zu Beginn (am besten bereits, wo der Record definiert wird), lasse ich die Struktur des Records in folgender Weise speichern:

Code: Alles auswählen

   var p: pointer; // = Zeiger auf Beginn des Records
 
   Type TRec =
    record name;string; adresse:dword;
           vt:vartype; // $F000 + '(' oder ')' ==> Klammer einfügen
           ArrayPtr:pointer; //(wenn vt = vararray)
           offs:integer;
           modus:word; end; //falls noch mehr differenziert werden muß, zB shortstring oder ansistring
    end;
    Type TRecs = array of TRec;
    var recs:TRecs; Reclg:integer; // Anzahl der Recs zur Darstellung eines Records
 

ArrayPtr weist auf einen Record mit den Daten zum entsprechenden Array:

Code: Alles auswählen

      TArrayRec = record cnt:integer; vtype:word; PARec: PArrayRec; Voffs; word; end
      PArrayRec = ^TArrayRec;
 
 
PArec brauche ich, falls es mehrmals geschachtelte arrays gibt (array of array of ..)

ArrayPtr wird durch die Funktion VarArray_to_String in einen String umgewandelt
( mit () als Eingrenzung )

Code: Alles auswählen

    function VarArray_To_String(PR: PArrayRec):string;
      var s:string; i:integer;
      begin
       with PR^ do
        begin
        ....
        for i:=0 to cnt-1 do
           begin
             case vtype of
                varinteger: s:=intToStr(pinteger(p+offs[i])^);
                vararray: s:=VarArray_To_String(parec);
                ...
             end;
             if result='' then result:=result+s else result:=result + ',' + s;
           end;
       result:='('+result+')';
     end;
 
TRec wird dann beim Anzeigen in einen String umgewandelt:

Zu Beginn werden mittels der Prozedur
Read_offsets_and_Vartypes - die muß noch erstellt werden -
die einzelnen Offsets und Vartypes der RecordFelder in die WordArrays
vt und offs übertragen (Platz freilassen für evtl. Klammern bzw in einem zweiten Schritt einfügen).
bei klammer: vt = $F000 + ord(Klammer)

Dann wird damit der Record in einen String übertragen:

Code: Alles auswählen

function Record2String(p:pchar; recs:TRecs):string:
   var s:string;  i:integer;
  begin
   i:=0; result:='';
   repeat with recs[i] do
     case vt of
       vararray:
          begin with PArrayPtr(p+offs[i])^ do s:=var_array_To_String(ArrayPtr);
       varinteger; s:=intToStr((p+offs[i])^);
       $F000 + ord('('): s:='(';
       $F000 + ord (')'): s:=')';
       ....
     end;
     if result='' then result :=s else result :=result+','+s;
    inc(i);
    until i>=reclg;
  end;
 
Zur Ausgabe des strings am Bildschirm wird wohl der Canvas des Fensters benutzt, oder?
Wenn nicht, dann die Prozedur entsprechend ändern.

Code: Alles auswählen

  Procedure Record_Ausgeben(x,y:integer; varname:string; recs:TRecs;
            count:integer; Zeilen:integer);
      // Zeilen = wenn >0, dann max. Anzahl Zeilen zur Ausgabe der Records,
      // sonst max. eine Zeile
    var maxlg:integer; // Ausgabeschirm-Breite
        z,c,n,  x,x0, y:integer; s:string;
        p:pchar;
       procedure OutText(s:string);
         begin with canvas do
            begin textout(x,y,s); x:=penpos.x; y:=penpos.y; end;
         end;
    begin
      Read_offsets_and_Vartypes;
      .... maxlg=.. p=..
      with canvas do
        begin
          x:=PenPos.x; y:=PenPos.y;
          outtext(varname);
          x0:=PenPos.x;
          { outtext( VarAdresse } ); // wenn gewünscht
          n:=0; z:=0; // z=Anzahl ausgegebener Zeilen
         repeat
           p:= ... = adresse des n-ten Records
           s:=Record2String(p, recs);
           outtext(s);
           if PenPos.x>=maxlg then  // über den rechten Rand hinauasgeschrieben
             begin inc(z); if z>=zeilen then exit;
                   inc(y, Textheight('M'));
                   if x>maxlg then begin x:=x0; textout(x,y,s); end // Ausgabe wdh in neuer Zeile
                   else x:=x0;
             end;
           inc(i);
          until i>=count;
        end; // with canvas
     end;
 
Ich denke, in dieser Form dürfte es nicht so lange dauern, bis der Debugger die Records am BNildschirm ausgibt.
Vielleicht könnte masn auch die Ausgabe der anderen lokalen Varablen am Bildschirm beschleunigen, indem man man zuerst alles in einer TStringList speichrt und dann in einem Rutsch ausgibt?

br_klaus
Beiträge: 244
Registriert: Do 21. Jan 2010, 22:33
OS, Lazarus, FPC: Windows Vista (L 0.9.31 FPC 2.5.1)
CPU-Target: 32Bit
Wohnort: z.z. Brasilien, sonst 82335 Berg-Leoni (südlich von München)

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von br_klaus »

P.S.:
Wenn du mir sagst, wie der Compiler die Daten und Typen einliest (bzw wo und mit welchen Prozeduren), dann könnte ich das Problem evtl. selber angehen und eine Lösung programmieren. Meine Programmierkenntnise sind nur nicht allzu groß. Bin ständig am dazu Lernen...

martin_frb
Beiträge: 588
Registriert: Mi 25. Mär 2009, 21:12
OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
CPU-Target: mostly 32 bit

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von martin_frb »

Also ich bin noch nicht sicher wo ich Deine erste Antwort einsortiere... Insbesondere da: "Wenn du mir sagst, wie der Compiler die Daten und Typen einliest"

Compiler: Das musst Du auf der FPC mail liste fragen. Spielt aber eigentlich keine Rolle.

Der Compiler liest die Daten, und schreibt Debug Info. (stabs oder Dwarf)
GDB liest diese Debug Info, und das ist alles was es braucht.

Das heißt, selbst wenn GDB keinen Zugriff auf die Source hat, kann es dir den Wert einer Variable angeben. Die Debug Info enthält den Namen, die type Definition, und wo der/die Wert(e) im Speicher sind.

GDB ist ein eigenständiges Programm, mit dem auch außerhalb der IDE Debuggen kann. GDB hat ein Dos-artiges Interface. Das heißt man tippt z.b
ptype VarName
-data-evaluate VarName
...
Und obwohl GDB teilweise weiß was Pascal ist, verhält es sich oft so, als ob die Daten zu C Strukturen gehoeren.

Die IDE sendet all diese Kommandos, korrigiert soweit möglich Fehler die GDB macht, und gibt das Ergebnis aus.

-----------------------

Das heißt, derzeit liest die IDE (der Debugger Teil der IDE) den Quelltext nicht. Alle Info kommt via GDB aus der "Debug Info", die FPC geschrieben hat.

Nur fuer besagte Arrays ist das nicht möglich, da GDB ja schon abstürzt wenn die IDE fragt "was ist P?". GDB sollte antworten "p = array [0..512000] of integer" oder ähnlich. Also eben mal 30 Zeichen. Aber GDB versucht 2GB Speicher zu kriegen, um diese Antwort zu geben....

Da die IDE vor der frage "was ist p" nicht weiß das GDB damit ein Problem hat, kann die IDE auch nicht entscheiden, das es GDB nicht fragen darf. (p könnte ja auch was anderes sein.)

2 Lösungen:
a) Die IDE (Debugger-Teil) liest selbst die Debug Info.
b) Die IDE (Debugger-Teil) scannt selbst die Source.

a: würde viele andere Probleme mitlösen, und wäre der "korrekte" weg (und wird eines Tages kommen)

b: Die IDE kann Quellcode schon lesen: CodeTools. Es geht darum den IDE-Debug-Teil und Codetools korrekt zu verbinden.
Da muss ich selbst erst suchen wo und wie das genau zu machen ist.

br_klaus
Beiträge: 244
Registriert: Do 21. Jan 2010, 22:33
OS, Lazarus, FPC: Windows Vista (L 0.9.31 FPC 2.5.1)
CPU-Target: 32Bit
Wohnort: z.z. Brasilien, sonst 82335 Berg-Leoni (südlich von München)

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von br_klaus »

Was ist denn stabs oder dwarf? Bei Google konnte ich da keine rechte Antwort finden.

Wenn der Compiler selbst die DebugInfos schreibt (wie ist denn deren Format aufgebaut?), wozu müssen dann die noch extra über GDB neu abgefragt werden? Nachdem das eh Fehler macht (zB kann es nicht unterscheiden zwischen PChar und string, habe ich zumindest im Internet gelesen), wozu dann noch extra aufrufen und Fehler korrigieren?
(Wenn Fehler korrigiert werden müssen, dann muß der Compiler ja wissen, wie das richtige Ergebnis lauten muss und dann braucht er da nicht noch extra GDB aufzurufen. Oder sehe ich da etwas verkehrt?)

Und warum läßt man nicht die IDE den Quelltext lesen? Geschieht das denn nicht zB bei den Codetools? Die werden ja auch aufgerufen, wenn man den Kopf einer Funktion anspringen will o.ä.
Und da habe ich gesehen, daß es ein PasType (oder so ähnlich) gibt und bei Arrays zB auch unterschieden wird zwischen openarray und rangedarray (in der Unit Pascalparsertool). Dann müsste man damit doch auch für jede Variable den Typ und die entsprechenden Informationen (zB Größe, ob Zeiger, etc.) speichern können und dann beim Anzeigen diese abfragen - und bräuchte kein GDB dazwischenzuschalten -...

martin_frb
Beiträge: 588
Registriert: Mi 25. Mär 2009, 21:12
OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
CPU-Target: mostly 32 bit

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von martin_frb »

Wie schon geschrieben. Debug info enthält Namen, Definitionen, ... All das kann natürlich in der Source gefunden werden. Da hat der Compiler es ja auch her. Das heißt, wenn man die Source hat.... Wenn z.b ein Record in einer Unit definiert ist, von der ich nur ein PPU aber keine Source habe, dann brauch ich debug info.

Außerdem steht in der Source nicht, in welcher Adresse im Memory der Wert ist. In der debug info steht das.
Ohne die Adresse kann man also nicht Debuggen. Und daher reicht die Source nicht.

Warum GDB:
Weil noch keiner die Zeit hatte, cross-platform einen Parser fuer debug-info zu schreiben.
Und weil man dann auch mit speziellen System Funktionen, Zugriff auf den Speicher der debuggten Applikation erlangen muss. Normalerweise blockiert das Betriebssystem solche Zugriffe.

Der Rest ist eine Frage der Zeit. Die Ideen sind alle bekannt. Aber die umzusetzen wird sehr sehr viel Zeit brauchen.

br_klaus
Beiträge: 244
Registriert: Do 21. Jan 2010, 22:33
OS, Lazarus, FPC: Windows Vista (L 0.9.31 FPC 2.5.1)
CPU-Target: 32Bit
Wohnort: z.z. Brasilien, sonst 82335 Berg-Leoni (südlich von München)

Re: Debugger stürzt ab beim Anzeigen zu großer Variablen

Beitrag von br_klaus »

Gibt es denn eine Möglichkeit, die Debug Infos "von Hand" einzulesen? Bzw wo kann man Näheres darüber erfahren, wie die erstellt und gelesen werden? Mit Google konnte ich nichts darüber finden, nur immer Informationen, wie man die verschwinden lassen kann...

Antworten