Repeatable Simulator Freeze and/or Crash Only with Release WASM

Bug Reports WASM
1

Version: SU15 - 1.37.5.0*

Frequency: Consistently

Severity: Blocker

Context: TFDi Design MD-11 (development version)

Bug description:
Recently, we discovered that our WASM causes the simulator to completely freeze upon loading. Commenting/reordering the code around causes arbitrary access violations in the WASM at otherwise working locations. In the case of the freeze, the loading screen finishes (usually) and you’ll get the first second or two of simulator visuals, then it’s a complete freeze. Sound continues, but no interaction or redrawing.

This only occurs with a Release mode WASM. WASM Debug Mode in the simulator itself makes no difference. The exact same code works as expected in Debug mode, and works correctly in both Release and Debug when compiled in x64 (for our standalone environment/P3D).

Some of the recent changes included large data allocations and AI traffic data acquisition, both of which I have tried removing to no avail. Since this problem began, I have been 100% unable to use a Release-built WASM without disabling enormous (and previously working) sections of code (reducing the aircraft to an unflyably-simplified state).

I have tried with SU14 and SU15 beta and the results are identical. My SDK is up to date and I am compiling from Windows 11 and Visual Studio 2022.I have also had another developer on a different machine test and he experienced the same results.

My current suspicion is that some runtime optimizations in release mode are generating incorrect instructions or silently changing the expected behavior. I have not ruled out that our code may be at fault, but even disassembly analysis has revealed strange recursive functions we didn’t write or weird iterator behavior.

Repro steps: Load the aircraft with the attached release WASM. Observe that it does not work when the same code in Debug does.

Attachments: I have sent our installer and an activation key to the PrivateContent group. Please take care to install the package via the installer first, then apply the Release WASM I sent. The installed version does not include the afflicted WASM but has the rest of the required files.

Private Attachments: tfdi_design_md11_package.zip (send to group)

1 Like
2

We continued debugging and finally managed to isolate what line/code is causing the freeze. Coindentially, it’s the same code that the debugger previously blamed for an access violation. We were able to determine with a log that “EventCreate 2d” was executed hundreds of thousands of times when the events container size was 0.

The code is as follows:

for (std::map<int, std::weak_ptr<SharedEvent::Allocator>>::iterator it = events.begin(); it != events.end(); it++)
{
	Logger::D(L"EventCreate 2d");

	std::shared_ptr<SharedEvent::Allocator> itobj = it->second.lock();
	std::wstring olname = itobj->name;
	std::transform(olname.begin(), olname.end(), olname.begin(), ::towlower);

	if (lname == olname && evtID == itobj->eventID && flag == itobj->evtFlag)
	{
		Logger::D(L"EventCreate 2e");
		obj = itobj;
		break;
	}
}

Logger::D(L"EventCreate 2f");

Section 2e was never hit (as expected) and neither was 2f (or beyond). What’s curious about this is the .size() method of the events container returned 0 - the code is aware it’s empty. Despite this, the iterator never reports being at the end.

We also then tested by adding a manual exclusion when the size is 0 to see if maybe it just needed to have at least one element to work. In that case, it just looped infinitely after adding the first element (with size() == 1 instead).

We’ve been experiencing random freezes with recent released builds that we can’t recreate in our test environment, either - I’m beginning to wonder if there is a bug with iterators specifically.

I look forward to your response.

Edit: Attached WASM with this specific freeze.
md11host.zip (3.9 MB)

Edit 2: I rewrote the loop in question using a for(int i = 0; i < events.size(); i++) then used std::advance to access it and unsurprisingly, it worked. The initialization routine continued until it encountered the next iterator loop where it then hung forever again. I wanted to rule out memory corruption on our part by trying to get this problem to occur in another space in memory. I feel that the problem is becoming clear here.

4

Hello @turbofandude

We were able to replicate this issue and it was added to our backlog.

Regards,
Sylvain

3 Likes
5

Thank you for confirming it, this puts my mind at ease a bit. I recognize there are other issues in the list, of course, but given that this is preventing us from releasing builds, is there a timeline we can expect to see the fix? Thanks in advance.

6

@FlyingRaccoon Just wanted to see if there was an ETA or a workaround we could use in the mean time. Thank you!

7

Hello @turbofandude

No news at the moment, I’ll update this topic as soon as I have more information.

Regards,
Sylvain

8

Just as an update to this thread, we’ve sent over full source of the project to aid in debugging this.

1 Like
9

Just wanted to follow up and report that we’re now seeing this manifested in other areas than just iterators. A recent build in Release mode is showing altitude restrictions in our FMC a factor of 10 larger than they exist in the database (FL500 instead of FL50). Debug mode reports the restrictions properly.