xBimTeam
The Exit code of application is non zero when used latest myGet feed on develop.
Hello Team, The exit code of a c# console application is non zero (-1073610751) when I use the latest MyGet on develop branch for xBIM Geometry. There is no exception or error in the application. I do get the expected output from my application so ideally the exit code should be 0 but it is not.
Assemblies and versions affected:
Adding screen shot of the version's that I have installed using MyGet feed.
Steps (or code) to reproduce the issue:
How do we check the error/exit code ?
Adding screen shot showcasing to check the exit code of application.
Minimal file to reproduce the issue:
I think it will get reproduced for any IFC file.
Expected behavior:
Exit code of application should be 0, when using latest MyGet feed.
Actual behavior or exception details:
It is not 0, it is -1073610751.
Additional Details
On previous version of xbim.geometry package, or any version that is installed using nugget.org, we are able to get exit code as 0. I have discussed this issue on this PR. Please have a look.
Thank you !!
I know you said you can't share the code but you'll have to provide some kind of minimal repo. The exit code on an app is usually just what you return from main().
-1073610751 = 0xC0020001 , which is the error code for an Unhandled Exception. Do you have any top level error handling code to trap and log the exception? The develop code is in wide use, so it's likely an environmental issue.
@andyward @SteveLockley
Hello Andy, Thank you for your reply.
I have prepared minimal repository to reproduce this issue. I have added steps to reproduce the issue.
Just to highlight the issue of exit code being non zero is still there in this minimal repo.
Thank you !!
Confirmed this is a bug in v5.1 Geometry Engine.
Clearly something in the application is being disposed/etc during application termination after main has returned. Global Exception Handlers don't pick this up.
It's the call into Xbim3DModelContext.CreateContext() that is the trigger so clearly something in the managed transition.
My guess is it's related to something related to Mixed mode resources. Sounds a bit similar to https://stackoverflow.com/questions/18098331/program-has-exited-with-code-1073610751-0xc0020001
Tested in v6 GE and we don't have the issue. Main returns zero. Since getting V6 released is our focus I don't know if we'll have time to investigate more deeply any time soon. Feel free to do more investigation and see if you can determine an error or exception that will help track down.
Hello @andyward
I was able to fix this bug in my application with a workaround.
I have added this line,
<loadFromRemoteSources enabled="true"/>
in the app.config of my visual studio solution.
Thank you for your support.
I did some investigation into this with windbg - what's happening is a statically constructed mixed model resource in OpenCascade is being disposed off too late by the CRT 'atexit' handler. E.g. this statically constructed Standard_OutOfMemory instance from Standard_OutOfMemory is being free, but the CLR has already been shut down.
// global instance must be allocated at load-time
static Handle(Standard_OutOfMemory) anOutOfMemInstance = new Standard_OutOfMemory;
Almost certainly introduced by an update to OCC, or how we compile/integrate it. Am still getting it tracked down
Some initial analysis
On Master branch
5.1.541.0 (01 Jan 2023) ✔️OK 5.1.790.0 (15 Dec 2024) ❌ (broken after the recent merged from develop)
Note v6 (dynamically linked OCC7.7+) does not have the issue.
In develop branch 5.1.100-develop (4 Dec 2020) ✔️ OK (Xbim.Geometry.Engine.Interop & ModelScene combination) from Myget develop 5.1.436-develop (21 March 2022) ❌ oldest remaining Xbim.Geometry in Myget develop with the issue
Sot it's a change to OCC between 4/12/2020 (67837ce24aada9d818283a2dad6fd0839614b0cd) and 21/3/2022 (commit 33624f2eed148ab9123a79297cb90c5541af4988) in develop
... roughly in this range https://github.com/xBimTeam/XbimGeometry/compare/67837ce24aada9d818283a2dad6fd0839614b0cd...33624f2eed148ab9123a79297cb90c5541af4988
Wondering if we should be building linking with /NOENTRY as per this SO
Have fixed this with a bit of a clunky fix as I haven't been able to work out the 'proper' solution - or the breaking change that actually triggered this, seeing as it broke year 4-5 ago.
The actual OCC codebase seems to have had the code that causes the failure since 2016, (OCC issue 0024836). So my guess is it's something like the move to v142 VC runtime that could be behind the issue (or even a update to the VC runtime)
For now I've locally reversed the 2016 optimisation which is for handling an edge case when out of memory, as fixing this issue in GE 5.1 is probably for the greater good vs the edge case. Bear in mind OCC exception handling was pretty U/S until #512 got fixed recently.
Reminder this issue doesn't affect v6 GE (possibly since we use v143 runtime, possibly since we dynamically link OCC, or just because it's OCC7.7+ not 7.6.2).