VS 2019 Debugger, Version 16.11.2, seltsames Verhalten "GetOutputTextExtent"

elmut19

@DocShoe Evtl. ist es doch ein anderes Problem.
Bitte um Entschuldigung!

Nun ist es auch in den anderen Release-Versionen aufgetreten.
Habe dort die Anzahl der Tabellen-Objekte auf gleiche Anzahl erhöht.

Nur warum das passiert, weiss ich leider nicht. Hat doch der Font einen Schaden?
Danke jedenfalls.

DocShoe

@elmut19
Tja, was soll man dazu sagen? Meine Kristallkugel ist zu 100% mit der Lottozahlvorhersage beschäftigt, die will ich da nicht unterbrechen.
Die erste Vermutung ist UB durch ungültige Speicherzugriffe, aber das musst du selbst rausfinden. cppcheck ist da schon mal ein guter Static Code Analyzer, ansonsten musste mal gucken, ob du nicht nen Profiler findest, der dir ungültige Speicherzugriffe meldet.

wob

@elmut19 sagte in VS 2019 Debugger, Version 16.11.2, seltsames Verhalten "GetOutputTextExtent":

Text

Welchen Wert hat denn Text? Was steht drin? Vielleicht irgendwas ungültiges mit fehlendem Nullterminator?

yahendrik

Text ist vom Typ CString, fehlende Nullterminierung würde ich da eher ausschließen (klar, das zu überprüfen schadet natürlich nicht).
Allerdings passt die Höhe überhaupt nicht, sodass ich wie @DocShoe davon ausgehen würde, dass Inhalte auf dem Stack überschrieben werden.
Ich würde nicht davon ausgehen, dass die Schrift irgendwie beschädigt ist oder GetOutputTextExtent, das vermutlich auch nur GetTextExtentPoint32 aufruft, falsch arbeitet.

elmut19

@wob Hallo wob,
vielen Dank, dass Du trotz meiner ersten Fehlanalyse noch versuchst zu helfen.
Gestern musste ich erstmal abbrechen

Das Problem besteht natürlich noch immer und ist, da es unabhängig vom Debugger ist,
auch noch schlimmer.

Ich habe den Text natürlich angesehen. Der ist/war immer OK!
Ich habe mir überlegt, ob es entweder der font sein kann, der evtl. nicht initialisiert ist.
Aber der wird eigentlich initialisiert. Dann noch der Device Context, der vielleicht
irgendwie ein anderes Device zugeordnet bekommen haben könnte.

Ich weiss gerade nicht, wie ich das überprüfen kann, was da schief läuft.
Und ich bin wirklich schon seit einer Woche permanent an diesem Problem, bis ich
zu dem Stand gekommen bin, dass es an der berechneten Textlänge liegt, woraus sich
ein Plausi-Fehler ergibt, um die Ausgabe abzubrechen. (Eine Länge von 8153 statt 28
würde eh zu Mist führen)

Man kann auch nicht sagen, wann die Aussetzer eintreten. Mal ist es beim ersten
Aufruf der Tabelle, mal muss ich zehn mal zwischen mehreren Tabellen hin u her schalten.
Und wenn ich wüsste, dass ich was mit dem Device Context in letzter Zeit gemacht hätte,
hätte ich einen kleinen Anhaltspunkt.

Also, wie prüfe ich am Besten, was mit dem Device Context nicht stimmt?
Die Längen, die es bringt sind auch immer dieselben, als ob ein merkwürdiges
Ausgabegerät initialisiert wurde.

DocShoe

Ich finde es faszinierend, dass du meine Vermutung mit UB und Codeanalyse durch Tools wie cppcheck und Memory Profiler einfach ignorierst. UB sind Fehler der übelsten Sorte und durch blosses Draufgucken meist nicht zu finden, es wird um so schwieriger, je größer das Projekt wird. Ich bin raus, ich wünsch dir noch viel Erfolg.

elmut19

@DocShoe Danke Dir. Hatte Deinen Kommentar leider noch nicht gelesen.
Werd ich aber nun machen (müssen). Dauert dann, bis ich mich eingearbeitet habe.
Bin trotzdem für alle möglichen Ratschläge offen.

... Mein Device Context wird einfach der "OnDraw(pDC)" über geben.
Aufgerufen wird die über irgendein Event, das im Hintergrund ausgelöst wird.
Und ich weiss nicht wie (habe das Programm auch nicht geschrieben).
Dieser "pDC" wird auch nirgends initialisiert. Bisher lief auch alles und immer.
Mein "Textsearch" liefert zumindest weder Aufrufe von "OnDraw(..)" oder Eventzuordnungen, noch
Initialisierungen des "pDC". Nur wenn ich drucken will schreibe ich explizit da was rein.

Vielleich kann da ja was durcheinander kommen?

elmut19

@elmut19
Ich hatte wirklich über eine Woche verzweifelt gesucht.
Bis ich dann bemerkt habe, dass in meiner (veralteten) INI-Datei ein nicht initialisierter Wert
für einen Font drin stand. Ich schäme mich! Aber was tut man nicht aus Verzweiflung.
Ich fühle mich nun doch gezwungen es hier aufzulösen.
Danke für Eure Mühe

hustbaer

@elmut19 Ich würde dir empfehlen trotzdem zu schauen wieso da so komische Werte rauskommen, also die von dir erwähnten "8164 oder 20987, oder 139665 oder ähnlich". Das sollte auch nicht passieren trotz dem im .ini File kein Font eingetragen ist.

Vermutlich prüft das Programm irgendwo den Returnwert nicht. Also ich könnte mir vorstellen dass es versuchst den Font zu erzeugen, was dann schief geht, und dann verwendest es das nicht initialisierte/ungültige Font-Handle trotzdem.

Was dein OnDraw angeht: Das klingt sehr nach MFC. Da wird das vom Framework (also von der MFC) aufgerufen. Einen Zeiger auf einen passenden DC bekommt die Funktion ebenfalls vom Framework mitgegeben. Daher auch ganz normal dass du keinen Aufruf von OnDraw findest. Verdrahten muss man diese Funktionen auch nicht extra. Die Funktionen sind in der Basisklasse definiert, und es reicht dass man die überschreibt bzw. evtl. noch in der Message-Map einträgt (bei manchen Funktionen nötig, bei anderen nicht).

elmut19

@hustbaer Vielen Dank Hustbaer.
Ich habe dann schon genauer nachgesehen.
Ein leerer Wert in der INI hätte im Programm eine "0" ergeben, also kein Problem.
Aber da stand dann leider typischerweise "-87475926579" (oder ähnlich) drin.
Das war schon saudooof. Und ich habe nicht bemerkt, dass die Korrekturen am INI
nicht automatisch auch den Inhalt dessen korrigieren. Stehen auch ein Haufen Daten drin.