IfcParse.lib crashing because IfcFile::header() is returning a bad reference.

[RickBrice]

I have been experiencing a weird situation using IfcParse.lib from my Windows DLL. A call to IfcHierarchyHelper<Schema> file; is crashing when setDefaultHeaderValues() is called from the IfcFile constructor. IfcFile::header() is returning a reference to the wrong address. The address of the referenced object is different than IfcFile::_header. The exact line it is crashing on is header().file_description().implementation_level("2;1");.

Everything worked fine using code from the 0.6 branch a year ago. Now, this is happening. The only difference is I changed my compiler to VS2022. The problem also happens when I use the 0.7 branch.

I know the problem is entirely on my end because the IfcOpenHouse example uses the same IfcHierarchyHelper<Schema> file; code and it works just fine.

Any ideas as to what could be wrong?

[aothms]

Strange. setDefaultHeaderValues() is also used in a lot of other scenarios (e.g on the python side of things). It would be unlikely if there is an issue there.

Is this with compiler optimizations? In that case it's possible that "the address of the referenced object is different " is only a side effect of some compilation that has confused the debugger, but that the real issue is actually elsewhere. In that case using a Debug build would help.

Is there a way you can turn this into something I can reproduce on my end?

[RickBrice]

My guess it is a compiler setting issue also. I compared the IfcOpenHouse settings to my project's and they seem to be identical.

If I do the following, the call to setDefaultHeaderValues() succeeds, but then it crashes later.

auto& my_header = header();
my_header.file_description().implementation_leve("2:1"); // actually, I replace all header().file_... with my_header.file... but you get the idea

The address of &my_header and &(this->header_) are different.

The call to implementation_level() eventually gets down to setArgument() at IfcParse.cpp line 1458 if(attributes[i] != 0) with i = 1, evaluates to true because attributes_[1] = 0x00000000fdfdfdfd. fdfdfdfd is a MSVC marker for no man's land at the end of an array to guard against buffer overruns.

Somehow the call to header() shifts pointer by 4 bytes.

I created a very simple analog for my program, but it does not reproduce the issue.

I'll keep after this. If you can think of anything, let me know.

[aothms]

Did you try setting a Data breakpoint in msvc to see when the value at the memory address is overwritten? Sent from a mobile device. Excuse my brevity. Kind regards, Thomas Op do 16 feb. 2023 18:37 schreef Richard Brice ***@***.***>:

…

My guess it is a compiler setting issue also. I compared the IfcOpenHouse settings to my project's and they seem to be identical. If I do the following, the call to setDefaultHeaderValues() succeeds, but then it crashes later. auto& my_header = header(); my_header.file_description().implementation_leve("2:1"); // actually, I replace all header().file_... with my_header.file... but you get the idea The address of &my_header and &(this->header_) are different. The call to implementation_level() eventually gets down to setArgument() at IfcParse.cpp line 1458 if(attributes[i] != 0) with i = 1, evaluates to true because attributes_[1] = 0x00000000fdfdfdfd. fdfdfdfd is a MSVC marker for no man's land at the end of an array to guard against buffer overruns. Somehow the call to header() shifts pointer by 4 bytes. I created a very simple analog for my program, but it does not reproduce the issue. I'll keep after this. If you can think of anything, let me know. — Reply to this email directly, view it on GitHub <#2777 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAILWV5AGG3SJNOVGKDKM4LWXZQV5ANCNFSM6AAAAAAU5VVSJY> . You are receiving this because you commented.Message ID: ***@***.*** com>

[RickBrice]

I did - it doesn't break becasuse the header_ object doesn't actually change.

If you think of the returned reference like a pointer, it's address is (&(this->header_) + 4 bytes). Which seems to be why attributes_[1] seems to be going into no man's land. Totally weird. I've never seen anything like this before.

[aothms]

But &this->header_ and &attributes_[1] are not related to each other, right, or not reliably at least? Maybe a data breakpoint on &attributes_[1]? I can only think of some sort of memory corruption by wrong free or allocation (which would be caught by the data breakpoint). But it would be strange if that is so reliably consistent...

[RickBrice]

I've set data breaks on &attributes_[1] as well. It doesn't break. I don't think the data is actually getting changed.

I'm trying to use IfcParse.lib in a DLL that is loaded by another DLL that is loaded by an EXE. There must be some kind of binary incompatibility in all these levels of complexity.

I'm going to try to create IfcHierarchyHelper objects in the various binary components of the application to see if it works. I may have to just throw away my DLL plugin and start over.

Like I said, the problem is on my end, not yours. I'll keep experimenting and will let you know if I find a cause and solution.

Thanks for your time.

[aothms]

I'm trying to use IfcParse.lib in a DLL that is loaded by another DLL that is loaded by an EXE.

Hm that could indeed be a another issue. Are they all compiled by the same compiler against the same standard lib? Because otherwise indeed stl types could perhaps have different sizes. That could maybe explain this offset you're observing? That an stl container is 4 bytes larger on one of the dll boundary causing its data pointer to be misaligned when read on the other side.

[RickBrice]

I finally found a way to recreate the problem in a small project.

In the IfcDriver project (the DLL that uses IfcParse.lib) there is a class called Worker. Worker::BuildIfcFile() creates a IfcHierarchyHelper<Ifc4x3_add1> object. Inside the constructor is where it all goes bad.

void Worker::BuildIfcFile()
{
   IfcHierarchyHelper<Ifc4x3_add1> file;
   InitializeFile<Ifc4x3_add1>(file);
   //InitializeFile(file);
}

However, if you comment out the InitializeFile<Ifc4x3_add1>(file); call, there isn't a problem.

I though perhaps this has something to do with the template generated code. To test this idea, I created a new InitializeFile method without using a template and commented out all the template code. The problem remains.

I build IfcParse.lib using visual studio 2022 with boost 1.78 #2524 (comment) and I'm using the 0.7 branch

IfcTest.zip

[aothms]

I can't reproduce it on my end on a clean msvc 2022. I simply used ifcopenshell build-all.cmd (so that's the RelWithDebInfo default), configured the paths (IfcTest Release conf), I had to add bcrypt.lib (is it indicative of something that you don't require this??), but that's about it. The project runs without issue. I added std::cout << file << std::endl; to BuildIfcFile() just to be sure and that also went fine.

My version info:

Microsoft Visual Studio Community 2022
Version 17.4.5
VisualStudio.17.Release/17.4.5+33403.182
Microsoft .NET Framework
Version 4.8.04161

Installed Version: Community

Visual C++ 2022   00482-90000-00000-AA284
Microsoft Visual C++ 2022

ASP.NET and Web Tools   17.4.337.25083
ASP.NET and Web Tools

Azure App Service Tools v3.0.0   17.4.337.25083
Azure App Service Tools v3.0.0

C# Tools   4.4.0-6.23101.15+72dbad1d47f6065730a65c97621a4e93dc3efdf2
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

NuGet Package Manager   6.4.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

Test Adapter for Boost.Test   1.0
Enables Visual Studio's testing tools with unit tests written for Boost.Test.  The use terms and Third Party Notices are available in the extension installation directory.

Test Adapter for Google Test   1.0
Enables Visual Studio's testing tools with unit tests written for Google Test.  The use terms and Third Party Notices are available in the extension installation directory.

TypeScript Tools   17.0.10921.2001
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools   4.4.0-6.23101.15+72dbad1d47f6065730a65c97621a4e93dc3efdf2
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual Studio IntelliCode   2.2
AI-assisted development for Visual Studio.

[RickBrice]

I was only looking at the Debug build and it links against bcrypt.lib. Sorry - I should have been more specific.

I went to a different computer, one where I've never had IfcOpenShell before, and downloaded and complied everything. My sample project and my real project worked just fine. I don't know what kind of binary shenanigans are happening on my primary development computer. I'm going to blast everything IfcOpenShell related and start over. Hopefully that clears up the problem. I'll let you know what happens (it will probably be in a week or so since I'm traveling next week). Thanks for the help.

[aothms]

I was only looking at the Debug build and it links against bcrypt.lib. Sorry - I should have been more specific.

Oh no worries at all.

I don't know what kind of binary shenanigans are happening on my primary development computer. I'm going to blast everything IfcOpenShell related and start over.

It's not uncommon that I have to do a full project clean, usually the symptoms are: internal linker errors or breakpoints not getting triggered, but wrong generated code is not very reassuring.. Could still also be a compiler version issue though maybe, let's see in a week or so.

[RickBrice]

I'm happy to report that after deleting everything and starting over, I got a build that works.

Thanks for your help

[RickBrice]

I experienced this same issue when moving to v0.8.0. I think I've found the root cause and wanted to share in case someone else has experienced this problem.

My application and IfcParse both use the boost libraries. However, I had boost installed in two locations (one for my application and one in the IfcOpenShell file structure). When I made my application use the exact same boost libraries as IfcParse, the issue went away.

I think the mixing of different installations of boost was the root cause problem.