System.UStrClr Access Violation

Question

Porting an old desktop app to the modern age using RAD Studio 10.1 Berlin. App was last built in C++ Builder 6 (many, many moons ago).

Managed to sort out all the component and external library dependencies, but it appears that there is some lingering issues with the Unicode port. The app used to rely heavily on the built-in String type, which now corresponds to AnsiString.

The source code builds, but the binary throws an Access Violation somewhere before any application code executed. The error stack trace:

rtl240.@System@@UstrClr$qqrpv + 0x12
largest_pos
__linkproc__ Attributebitmaps::Initialize 0x18
__init_exit_proc
__wstartup

The largest_pos function does some numerical manipulation - no String dependencies of any kind.

Attributebitmaps is a static class, with no member called Initialize. In Delphi you use to be able to declare an Initialize and Finalize call at the unit level, but that construct is not used in C++ Builder.

Any ideas around why an error would occur in System.UStrClr? Where would you go digging to get more insight into this?

Code running prior to the user-defined entry point are usually static initializers, and an access violation is more often than not a result of the undefined order of initialization of static objects. Does the Attributebitmaps class depend on other static objects being initialized? — IInspectable
Does Attributebitmaps have any UnicodeString members? UStrClr() is the RTL's function to release memory for a UnicodeString variable. So either a UnicodeString variable is getting corrupted before released, or the call stack itself is getting corrupted and is jumping into UStrClr() by accident. Either way, there is no way to diagonose this without seeing some real code. — Remy Lebeau
Attributebitmaps does not have any UnicodeString members. It does depend on TCanvas and some related VCL classes, but no String members of any kind. Thanks for the hint though. Just have to keep looking,. — Ryan

Ryan Ryan · Accepted Answer · 2016-06-22T17:42:26

Related to the static initializer fiascos referred to in numerous other posts on SO, the culprit in this case was the following pattern:

.h file:

class SomeClass {
    static String SOME_STATIC_STRING;
};

String SomeClass::SOME_STATIC_STRING("foo");

If you do elect to use an initializer like this, it should be moved to the .cpp file.

System.UStrClr Access Violation

1 Answers