Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory access violation #512

Closed
theebow opened this issue Dec 5, 2024 · 3 comments
Closed

Memory access violation #512

theebow opened this issue Dec 5, 2024 · 3 comments
Assignees
Labels
bug Confirmed bug - system not working as intended

Comments

@theebow
Copy link

theebow commented Dec 5, 2024

Hi Team

i've an exception reading a ifc file V 5.1.437 and reproduce in this last one, i've just cloned

image

Unfortunately, the ifc file i have is confidential then i can not publish here
but is there a way to provide it to an admin ?

many thanks

@andyward
Copy link
Member

andyward commented Dec 5, 2024

Hi, you can send a download link to my xbim.net email address (on my github profile) and we can take a look?

@theebow
Copy link
Author

theebow commented Dec 5, 2024

Ok thanks i'm going to do that (the e-mail subject will be "Memory acces violation")

@andyward andyward self-assigned this Dec 14, 2024
andyward added a commit that referenced this issue Dec 14, 2024
While an edge case, the root cause is that ages ago we incorrectly added OCC 'No_Exception' Preprocessor directive in Release builds, essentially making all managed exception handling useless outside of Debug builds

Slightly tidied OCC targets to remove duplicate elements.
andyward added a commit that referenced this issue Dec 14, 2024
* Fix for memory access violation when filling loop #512

While an edge case, the root cause is that ages ago we incorrectly added OCC 'No_Exception' Preprocessor directive in Release builds, essentially making all managed exception handling useless outside of Debug builds

Slightly tidied OCC targets to remove duplicate elements.
@andyward andyward added in progress Being worked on awaiting closure Issues that should be closed if we don't hear back on in a week labels Dec 14, 2024
andyward added a commit that referenced this issue Dec 14, 2024
- resulting in infinite sized Region. Follow up issue for #512
andyward added a commit that referenced this issue Dec 14, 2024
…518)

- resulting in infinite sized Region. Follow up issue for #512
@andyward
Copy link
Member

This is fixed and released to master. Nuget package to follow later this week.

The primary issue was that for ages we've been building OpenCascade with a flag that eliminated Exceptions in Release builds. This accounts for a whole class of errors and inconsistencies we've been seeing in v5.1 (vs v4 and v6 GE), because the error-handling in OCC was being optimised out, resulting in all kinds of low level C++ level errors and corruptions.

Related to #454 , #281 (comment) and #281 (comment)

@andyward andyward added bug Confirmed bug - system not working as intended and removed in progress Being worked on awaiting closure Issues that should be closed if we don't hear back on in a week labels Dec 20, 2024
andyward added a commit that referenced this issue Dec 30, 2024
* Fix for memory access violation when filling loop #512

While an edge case, the root cause is that ages ago we incorrectly added OCC 'No_Exception' Preprocessor directive in Release builds, essentially making all managed exception handling useless outside of Debug builds

Slightly tidied OCC targets to remove duplicate elements.
andyward added a commit that referenced this issue Dec 30, 2024
…518)

- resulting in infinite sized Region. Follow up issue for #512
andyward added a commit that referenced this issue Jan 9, 2025
… get correct exception handling in Release mode

Related to #512. OCC now built with public repo at https://github.com/xBimTeam/xbimGeometryOcct using repeatable script.

Deployment of OCC native dlls now left to Xbim.Geometry.Occt package, reducing size of Xbim.GE.Interop package
andyward added a commit that referenced this issue Jan 31, 2025
Replaced static instance with dynamically allocated once since this static resource triggers error code C0020001 to be returned
when the host process exits, due to C's atexit() disposal of managed resources after CLR shutdown.

This is a tactical V5 only fix to improve the situation for 99.99% of use cases. It may confuse genuine out of memory conditions, but
given CPP No_Exception has been in place until very reccently this exception handling would not have been raised anyway (see #512)

Do not apply to OCC in V6 GE
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bug - system not working as intended
Projects
None yet
Development

No branches or pull requests

2 participants