Zugriffsverletzung 0x00.. in user32.dll auf chinesischem Server

[mquadrat]

Hallo zusammen,

ich habe gerade ein Problem bei dem ich ein wenig auf dem Schlauch stehe. Ausgangslage: Eine Anwendung (lokalisiert über gnugettext) läuft stabil auf deutschen, polnischen und amerikanischen Systemen. Auf chinesischen Systemen jedoch (Regionaleinstellung Chinese Simplified), kommt es zu Zugriffsverletztungen in der user32.dll?!

Code:

main thread ($1ac4):
00000000 +000 ???
77628d31 +00b USER32.dll                      GetKeyboardLayout
0052132c +02c abcdefg.exe  Vcl.Controls       TWinControl.MainWndProc
0048af70 +014 abcdefg.exe  System.Classes     StdWndProc
77627885 +00a USER32.dll                      DispatchMessageW
005ee3b7 +0f3 abcdefg.exe  Vcl.Forms          TApplication.ProcessMessage
005ee3fa +00a abcdefg.exe  Vcl.Forms          TApplication.HandleMessage
005ee739 +0c9 abcdefg.exe  Vcl.Forms          TApplication.Run
00f19d4b +1d7 abcdefg.exe  ABCDEFG        264 initialization
75c43388 +010 kernel32.dll                    BaseThreadInitThunk

Anwendung ist in XE2 programmiert, falls die Info irgendwem was hilft

Mir gehen da gerade irgendwie die Ideen aus

[Sherlock]

Verwendest Du UnicodeString bzw. String oder sowas wie WideString oder AnsiString?
Bei letzterem ist das Problem klar...

Sherlock

[mquadrat]

Eigentlich flächendeckend String (dachte ich zumindest). Aber mir fehlt gerade noch ein wenig der Zusammenhang zum Stack-Trace bzw. warum das als Zugriffsverletzung aufschlägt. Magst du da vielleicht noch den ein oder anderen Satz schreiben?

EDIT: Meine Verwirrung hat sich noch nicht so wirklich gelegt. Der Absturz passiert nach dem Schließen eines Fenster und zwar NACH dem Release. Das Release geht also noch korrekt durch. Außerdem ist es abhängig davon, was in dem Fenster angezeigt wurde. Ich löse nirgendwo manuell Windows Messages aus.

[Sherlock]

Ins Blaue hinein: Kann es sein, daß bei der Übersetzung eigentlich interne Bezeichner oder Unitnamen oder sowas in der Art übersetzt wurden/werden? Im europäischen Umfeld macht das ja weniger was aus, aber sobald da chinesische Zeichen reinrutschen könnte das Problematisch werden.

Sherlock

[mquadrat]

Das ganze ist sehr diffus. Ich habe immerhin jetzt die Stelle gefunden. Den Fehler verursacht hat ein TChart, obwohl der Fehler erst nach(!) dem Release des entsprechenden Formulars geworfen wird. Ebenso trittder Fehler nur auf, wenn das Objekt, das in diesem Form dargestellt wird, einen bestimmten Status hat. Der Status wirkt sich aber eigentlich gar nicht auf dieses TChart aus.

Wenn ich etwas Luft habe, werde ich da mal weiter testen.

[Dejan Vu]

Das ist ein Seiteneffekt: Der Fehler ist vermutlich ganz woanders. Hast Du dein Projekt mal mit Range- und Overflowchecks kompiliert? Mal FastMM mit FullDebugMode probiert? Erst wenn letzteres im normalen Betrieb (was deinen komischen Fehler verursacht) ohne Meckerei durchläuft, ist es ein Problem.

[Redeemer]

Ich weiß nicht, ob das mit deinem Problem zusammenhängen kann, aber ein Projekt von mir zeigte bei einem koreanischen Nutzer koreanische Zeichen als sehr seltsame andere Zeichen an, wenn es mit XE2 kompiliert wurde. Mit 2009 hingegen kein Problem. Falls du andere Compiler zur Hand hast - da gab es ja mal die Aktion, bei XE2 alle Vorgänger bis 2007 dazu zu kriegen - probier's mal damit.

Weitere Idee: Lädt dein Projekt über TStrings/TStringList Textdateien, die nicht in Unicode vorliegen und Nicht-ASCII-Zeichen enthalten?

[Memnarch]

Etwas auf das ich noch nicht gestoßen bin(weil noch nie mit Chinesischen Zeichen gearbeitet habe), aber mir habe mal sagen lassen:
Chinesisch nutzt Surrogate-Pairs in strings. das heißt, dass 2 Chars ein Chinesisches Zeichen ergeben. Wird so eines vllt ausversehen auseinander gepflückt bei einer String-Operation und verursacht murks?

[himitsu]

Alle Zeichen im Bereich von #0 bis #$FFFF sind ganz normale UCS2-Chars.
Falls Chinesisch Zeichen von #$010000 bis #$10FFFF nutzt, dann sind diese als Surrogates im String kodiert,
aber normales Stringoperationen/-konvertierungen sollten Diese eigentlich selten zerlegen.
Und ja, es sind zwar viele chinesische Zeichen in der BMP (Basic Multilingual Plane = bis #$FFFF), aber ein großer Teil liegt auch in den Surrogates.

Was man mal machen könnte:
- das Programm mit DebugDCUs (RET+VCL) kompilieren
- Fehlersuchcodes ala Eurekalog oder MadExcept einbauen (oder man debuggt das selber)
- und vielleicht auch noch einen FastMM im FullDebugMode

[Der schöne Günther]

Ich kenne mich da überhaupt nicht aus, aber das GetKeyboardLayout im Stacktrace hat nichts zu bedeuten?