C++ Builder 10.1.2 Virtual-TreeView 6.5 Win64 Access Violation (Bug)

[somnomedics]

Linking VirtualTreesCR.bpl dynamically in a 64-bit (win64) application yields an access violation at runtime when trying to create TVirtualStringTree.

• static linking works
• linking in a 32-bit application works in any case
• the access violation seems to happen when trying to call the constructor

[joachimmarder]

Can you please provide a call stack of the exception?

[joachimmarder]

Maybe this is related to issue #642

[somnomedics]

I'm using the most recent release VirtualTreeView. Issue #642 is already fixed in that version.

TForm1 contains only the VirtualStringTree component with default property values.

Call stack:

• [ ] :00000000006a5cd7
• [ ] :00000000006A5DB0 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :00000000006970FA ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :0000000000697219 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000080E286 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :00000000008126B0 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000080F2AD ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000080F6F5 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000080FB81 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000080FAA5 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :0000000000824902 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000143A0D6 ; D:\Embarcadero\Studio\18.0\bin64\vcl240.bpl
• [ ] :0000000001440E7B ; D:\Embarcadero\Studio\18.0\bin64\vcl240.bpl
• [ ] :000000000080F7BA ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000080FB81 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000080FA83 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :0000000000824902 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000143A0D6 ; D:\Embarcadero\Studio\18.0\bin64\vcl240.bpl
• [ ] :0000000001440E7B ; D:\Embarcadero\Studio\18.0\bin64\vcl240.bpl
• [ ] :000000000161D3D4 ; D:\Embarcadero\Studio\18.0\bin64\vcl240.bpl
• [ ] :0000000000811162 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :0000000000807BEF ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :00000000007FA745 ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :00000000007FC60C ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :00000000007FC6CA ; D:\Embarcadero\Studio\18.0\bin64\rtl240.bpl
• [ ] :000000000161C242 ; D:\Embarcadero\Studio\18.0\bin64\vcl240.bpl
• [ ] :0000000000405ee4 ; Vcl::Forms::TForm::TForm(System::Classes::TComponent*)
• [ ] :0000000000405d14 ; TForm1::TForm1(System::Classes::TComponent*)
• [ ] :000000000162CC53 ; D:\Embarcadero\Studio\18.0\bin64\vcl240.bpl
• [ ] :00000000004055d9 ; wWinMain
• [ ] :00000000322152A8 ; D:\Embarcadero\Studio\18.0\bin64\CC64240MT.DLL

[joachimmarder]

The call stack needs to include the function names, otherwise it is useless. At least it does not include the Virtual TreeView package.

Issue #642 is already fixed in that version.

I know, but still may be related or the bug may have re-appeared.

[joachimmarder]

Did you use the RAD Studio/Delphi package, or the special C++ Builder package?

I tried compiling the 10.1 C++ Builder package but I ended up with errors. I ended up with other errors when using the 10.0 package under 10.1. The XE8 package worked, so have rebuilt the 10.2 packages based on the XE8 package.

I normally don't use C++ Builder at all.

[joachimmarder]

Can someone comment if this issue is still there?

[joachimmarder]

Any news on this issue? Without further feedback I will be closing this issue next month.

[sanjayssk]

Please refer to #669 where I added a C++ Builder project. There I mentioned that it causes access violation when runtime packages are used. That should be the same problem. I no longer have C++ Builder installed. So perhaps, you can take that C++ Builder project, compile in Rad Studio and see if something more can be found on the access violation that occurs in Borlandmm dll.

[somnomedics]

We can reproduce the issue with the sample project, for "64-bit windows". Workaround - static linking (can be forced by deleting the bpi-file)

[somnomedics]

Call stack trace with debug info:

:0000000000416327 ; System::UTF8ToUnicodeString(System::SmallString<(unsigned char)255> const&)
:00000000004163e0 ; System::UTF8ToString(System::SmallString<(unsigned char)255> const&)
:000000000040b28a ; System::TObject::ClassName()
:000000000040b3a9 ; System::TObject::ClassNameIs(System::UnicodeString)
:00000000004942fa ; System::Classes::TReader::GetFieldClass(System::TObject*, System::UnicodeString)
:00000000004989b0 ; System::Classes::TReader::FindComponentClass(System::UnicodeString)
:000000000049532d ; System::Classes::TReader::ReadComponent(System::Classes::TComponent*)::CreateComponent(void*)
:0000000000495765 ; System::Classes::TReader::ReadComponent(System::Classes::TComponent*)
:0000000000495bfa ; System::Classes::TReader::ReadDataInner(System::Classes::TComponent*)
:0000000000495b03 ; System::Classes::TReader::ReadData(System::Classes::TComponent*)
:00000000004a0bf2 ; System::Classes::TComponent::ReadState(System::Classes::TReader*)
:00000000004fe538 ; Vcl::Controls::TControl::ReadState(System::Classes::TReader*)
:00000000005050ab ; Vcl::Controls::TWinControl::ReadState(System::Classes::TReader*)
:00000000005d3585 ; Vcl::Forms::TCustomForm::ReadState(System::Classes::TReader*)
:000000000049723b ; System::Classes::TReader::ReadRootComponent(System::Classes::TComponent*)
:000000000049137f ; System::Classes::TStream::ReadComponent(System::Classes::TComponent*)
:0000000000486335 ; System::Classes::InternalReadComponentRes(System::UnicodeString, unsigned long long, System::Classes::TComponent*&)
:000000000048657b ; System::Classes::InitInheritedComponent(System::Classes::TComponent*, System::TMetaClass*)::InitComponent(void*, System::TMetaClass*)
:000000000048662a ; System::Classes::InitInheritedComponent(System::Classes::TComponent*, System::TMetaClass*)
:00000000005d2495 ; Vcl::Forms::TCustomForm::TCustomForm(System::Classes::TComponent*)
:0000000000405f14 ; Vcl::Forms::TForm::TForm(System::Classes::TComponent*)
:0000000000405424 ; TMainForm::TMainForm(System::Classes::TComponent*)
:00000000005e2e09 ; Vcl::Forms::TApplication::CreateForm(System::Classes::TComponentClass, void*)
:0000000000404a19 ; wWinMain
:00000000322087F8 ; D:\Embarcadero\Studio\19.0\bin64\CC64250MT.DLL

[joachimmarder]

It would make sense that someone with more C++ Builder experience than me would look into the problem. My best guess is a bug in C++ Builder or a wrong configuration of the Virtual Treeview runtime package.

[joachimmarder]

We can reproduce the issue with the sample project, for "64-bit windows".

@somnomedics : Which sample project exactly did you use?

[somnomedics]

The sample project can be found here: https://github.com/somnomedics/VirtualTreeView_Issue_695.git

Sample.zip

[joachimmarder]

C++ Builder 10.2.3: An AV still occurs for Win64 builds, but I can't even debug under C++ Builder Win64. All works fine (including debugging) on C++ Win32. I guess this issue needs a C++ Builder expert.

[zencode1]

~I confirmed this is still a problem in C++Builder 11.2. I made various changes to the packages and the application without success. The best outcome I am able to accomplish is this error message on startup which may offer some clue.~

TestVirtualView.exe - Entry Point Not Found

The procedure entry point _ZNKSt10error_code5valueEv could not be located in the dynamic link library C:\Issue-695\Win64\Debug\TestVirtualView.exe.

~I will continue looking into this problem.~

Edit: This was a problem with my setup. I accidentally copied the Release BPL to the Debug directory.

[zencode1]

It appears that Embarcadero fixed the problem in C++Builder 11.2. I tested for both Debug and Release, with runtime packages and without runtime packages. All test cases run.

I no longer have 11.0 or 11.1 installed so cannot confirm if it worked in either of those versions. However, I do have 10.4 installed and can confirm that the bug does exist for that compiler.

[joachimmarder]

Thank you @zencode1. So I am closing this issue as "Not our Issue".