Author Topic: Evacuation Under Fire - Ply Campaign Scenario  (Read 44676 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #50 on: September 18, 2019, 03:31:24 AM »
Yeah, we're doing some work to overhaul the module code in op2ext. Once that's done, we'll probably write up the patch as an internal module within op2ext.

As for the likelihood of getting that 0 value, it's probably not all that unlikely. Based on experience, it was roughly 1/15 tries. I haven't yet analysed exact details, but the math involves division by the unit size, which is 120 bytes. I suspect there is some modulo effect, which is why we were typically seeing small values in a limited range. Couple that with memory alignment requirements for the unit array, which is likely at least 4 bytes, we are further limiting possible values. Actually, if the memory alignment requirements were 8 bytes, which would be quite reasonable for an array of large objects, and that worked in conjunction with a modulus of 120, we might expect a given outcome to take on any of 120 / 8 = 15 values. Highly suspicious.

As things like memory alignment requirements are architecture specific, yes, there would be some degree of hardware dependence, though that choice would be made at compile time, and I wouldn't expect it to vary based on end user's machines. Granted, memory allocator's sometime defer responsibility to the OS's memory allocator, so there could be some difference in alignment possibilities if a particular OS/version imposes a larger minimum alignment than the language requires.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Evacuation Under Fire - Ply Campaign Scenario
« Reply #51 on: November 17, 2019, 06:48:36 AM »
Quick update here, the garage save/load bug has now bubbled to the top of the priority list and is getting some traction. Some discussion can be found at:
Create Built In Module to address garage data corruption during saving

The conditions and mechanism of the bug now seem to be understood, and are detailed in the issue report. The next step is to create a reproducer level that contains a bit of memory hacking to ensure the problem case always occurs. That will help verify the conditions and mechanism are actually well understood and correct. It will also help with patch verification when the time comes. I expect the patch will be written sometime within the next few days. Hopefully a new release of op2ext containing the patch will be out within the next couple of weeks.