Jump to content

TonyE

Recommended Posts

When using the autotest batch files against 2022.021 and 2022.022 Release builds, I'm getting assertions thrown in Stubs.c line 351, GetPtrSize.  Even if I ignore the assertion, the GE exits soon afterward without warning.  Instead of an exitcode of 0 (clean termination of the GE), I see an exitcode of -1073741819.  

I thought this might only be when using the AutoTest batch files where multiple copies of the GE are running simultaneously so I ran just EC2003 MEDC in single-file (one scenario at a time, one copy of GE running at a time) and still see the exitcode of -1073741819 for 50% of the scenarios (8 clean exits, 8 errors) so far.  

Error scenarios:

EC2003 MEDC 3.0 Blue

EC2003 MEDC 5.0 Blue

EC2003 MEDC 7.0 Blue

EC2003 MEDC 8.0 Blue

EC2003 MEDC 9.0 Blue

EC2003 MEDC 12.0 Blue

EC2003 MEDC 2.0 Red

EC2003 MEDC 4.0 Red

EC2003 MEDC 5.0 Red

EC2003 MEDC 6.0 Red

EC2003 MEDC 7.0 Red

Link to comment
Share on other sites

On 10/19/2022 at 1:58 PM, TonyE said:

EC2003 MEDC 3.0 seems to pretty consistently have a non-zero exitcode.

I removed the XML saving ability in the GE, that didn't help.

 

Then I ran this with the debugger and the VS2022 debugger crashed so didn't get any useful information.  Will try a debug build next.

Link to comment
Share on other sites

A debug build of 2022.022 running under the autotest batch files for EC2003 MEDC had zero errors.  Next up is turning off Optimization to see if that sneaks around whatever underlying problem is happening.

  • Like 1
Link to comment
Share on other sites

On 10/22/2022 at 7:56 PM, donaldseadog said:

I'm guessing us mortals are of no help?

 

At present I don't have a way for you to help.  I logged every memory allocation in EC2003 MEDC 3.0 and didn't have any of my favorite memory bug of allocating the size of a pointer (4 bytes) instead of the size of the structure.  That's rather unfortunate since they are relatively easy to detect when logging all of the allocations.  So on to tougher things to fix.

Link to comment
Share on other sites

Found and fixed a double-freeing of memory in eff102 (area defense) for a pretty specific situation of aircraft in a non-aircraft formation being shot down by surface to air gunfire.  The test case was indeed EC2003 MEDC 3.0 as Blue where Red ships get within a Blue carrier formation and start shooting down formation air patrols.  Re-running EC2003 autotest batch files now to see how much of an improvement is seen (this is without padding the memory allocations, so the most desirable situation).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...