My experience with X-Plane 11.52

[Cameron XA 272]

34 minutes ago, jarmstro said:

Hmmm. I was tempted by the TBM. It's disturbing to read that there are lots of people needing help and support! Is it buggy?

When you have one of the biggest selling products for the simulator, tech support is just a normal side effect. Some people prefer human interaction on learning to fly more complex systems, others are not as tech savvy and need help understanding how to use the installers. Some don't understand how to unzip a zip. It's just part of it. Trying to equate tech support to actual problems is silly. Granted, sometimes bugs occur, just like any product in the software world (including Apple and Microsoft). What matters is Goran is there to help them through it, even if the fault is not with his own product. That kind of support is valued by the consumer.

4 hours ago, mSparks said:

Yeah, so all the planes using an xlua base (except the 744, but that isn't short of its own issues ), which aiui, includes, sasl, flywithlua and gizmo, but I haven't followed if they have updated since it was confirmed early Feb, have a memory reuse bug inside of xplane, and the more complex the systems the more likely it is to cause random damage, eventually resulting in either insane behaviour or a CTD.

I'm actually having an issue understanding what you're speaking about. You're saying that Gizmo and even SASL has a memory use bug? I can't speak for SASL, but Gizmo is used on over 100,000 installs. I'm not aware of this issue you speak of. I've not seen any kind of CTD's due to it come my way, and I've not seen any complaints of performance degradation. Can you explain this one more?

Edited March 3, 2021 by Cameron XA

[mSparks 2,086]

8 minutes ago, Cameron XA said:

've not seen any kind of CTD's due to it come my way

You wouldn't. they go to Laminar

Or perhaps you were too busy telling them to be more concerned about your safe space than the broken software they paid for and were complaining about.

"Not my problem".

Edited March 3, 2021 by mSparks

[Cameron XA 272]

1 minute ago, mSparks said:

You wouldn't. they go to Laminar

Hmmm. I'm not so convinced by this statement. The problem there is Austin and Ben Supnik are on constant conversation level with me daily, especially when it comes to issues that would concern our products being affected. Both of them are very, very good about getting in touch the second something is amiss.

 

3 minutes ago, mSparks said:

Or perhaps you were too busy telling them to be more concerned about your safe space than the broken software they paid for and were complaining about.

"Not my problem".

No.

[Janov 2,383]

12 minutes ago, Cameron XA said:

I'm actually having an issue understanding what you're speaking about.

Oh, you obviously have just met mSparks, then! 😆 We are all taking that kinda as a given by now!

Edited March 3, 2021 by Janov

[benrussell 20]

4 hours ago, mSparks said:

Yeah, so all the planes using an xlua base (except the 744, but that isn't short of its own issues ), which aiui, includes, sasl, flywithlua and gizmo, but I haven't followed if they have updated since it was confirmed early Feb, have a memory reuse bug inside of xplane, and the more complex the systems the more likely it is to cause random damage, eventually resulting in either insane behaviour or a CTD.

Whatever the cause though, what is described in the OP is listed as a known bug in the latest release notes

https://www.x-plane.com/kb/x-plane-11-52-release-notes/

XPD-10830 Device loss crash when using Vulkan

Even if potential causes like the above aren't. 

 

  Reveal hidden contents

 

 

Are you refering to the recently discovered bug that I, author of Gizmo, reported to Laminar on ~5th Feb 2021 by Slack conversation with Ben Supnik and an email including working reprodcution to the Laminar bug tracker?

If so, you don't understand the bug properly.

I'll give the briefest of summaries...
1. This bug is _only_ triggered if a plugin attempts to ask X-Plane for a chunk of memory that is > 16megabytes in one single request.

2. This bug was never seen or reported "in the wild" that I know of. It was detected during our pre-sales bug testing.

3. The incorrect behaviour was present inside X-Plane. There was nothing any third party plugin could do to "not be buggy" if they were using Lua. It had nothing to do with what flavour of Lua plugin you used. It didn't matter if you had only one plugin or any combination of more than one installed. As soon as that single plugin asked for and released the Lua memory block of > 16 megabytes, crash.

If what I've described above -is- the bug you're referring to, please stop. You're making life harder for everyone.

Bug ID; XPD-11159

 

If you're talking about some other bug, please let me know.

Edited March 3, 2021 by benrussell
Added laminar bug track id.

[RXP 2,338]

1 minute ago, benrussell said:

If you're talking about some other bug, please let me know.

And in private or in a separate new topic please.

[mSparks 2,086]

10 minutes ago, benrussell said:

This bug was never seen or reported "in the wild" that I know of.

That's the one.

Its in the 744, 737, and anything else that uses 

XPLMSendMessageToPlugin(XPLM_PLUGIN_XPLANE, ALLOC_REALLOC,&r);

And has been being reported for years, but it got really bad with 11.50 (presumably things changed enough it started regularly hitting important things), we fixed it in XTLua back in ~April 2020 but didn't have a full recreate of exactly why it was behaving so badly.

Edited March 3, 2021 by mSparks

[benrussell 20]

2 minutes ago, mSparks said:

That's the one.

Its in the 744, 737, and anything else that uses 

XPLMSendMessageToPlugin(XPLM_PLUGIN_XPLANE, ALLOC_REALLOC,&r);

And has been being reported for years, but it got really bad with 11.50 (presumably things changed enough it started hitting important things), we fixed it in XTLua back in ~April 2020 but didn't have a full recreate of exactly why it was behaving so badly.

I haven't seen anything like it being reported and asking for a 16 meg chunk of Lua ram in one go is an exceptionally rare event on this side of the branding fence.

I've run into this problem exactly once in the last 11 years of heavy Gizmo use.

I think you're reporting something else.

This is a black and white issue. It took me a few hours to narrow it down and I wrote a repro using a script for XLua, Laminars lua plugin.

 

[mSparks 2,086]

24 minutes ago, benrussell said:

exceptionally rare event on this side of the branding fence.

16MB of ram is pretty small when you get into aircraft with 10s of thousands of datarefs juggling lots of navaid data around. When it happens depends randomly on Lua garbage collection, and exactly what the code is doing at the time.

It only needs to happen once to randomly nuke something that would otherwise be working fine.

It changed significantly with 11.50, prior to 11.50 it was too rare (or rather broke things to randomly) to even be sure where it was coming from, when 11.50 dropped I had Lua threads exploding every second or third startup, memory corruption traced back to that call.

Edited March 3, 2021 by mSparks

[benrussell 20]

17 minutes ago, mSparks said:

16MB of ram is pretty small when you get into aircraft with 10s of thousands of datarefs juggling lots of navaid data around. When it happens depends randomly on Lua garbage collection, and exactly what the code is doing at the time.

It only needs to happen once to randomly nuke something that would otherwise be working fine.

It changed significantly with 11.50, prior to 11.50 it was too rare (or rather broke things to randomly) to even be sure where it was coming from, when 11.50 dropped I had Lua threads exploding every second or third startup, memory corruption traced back to that call.

16 megabytes of 1024 byte chunks is easy to get to.

16 megabytes in one contiguous chunk is a lot rarer to need.

The entire simulator crashed to desktop when the plugin releases the 16 meg chunk.

This will happen when, say, the aircraft is unloaded.

This is not a "my plugin has random weird issues from ram sharing and overwrites". The entire sim is guaranteed to crash at some point when the ram is released.

 

As you have mistaken a contiguous chunk from a large pool of small vars I'm done here. Have fun trolling further if you must.

[benrussell 20]

[mSparks 2,086]

Just now, benrussell said:

The entire simulator crashed to desktop when the plugin releases the 16 meg chunk.

can crash

or it could just wreck a function that would then on ctd when the function is called

or it could just put a noop in the function and the button would stop working

or it could overwrite some data space and the ap would suddenly flip out and nose dive the plane into the ground.

etc etc.

memory corruption leading to a ctd is much rarer than memory corruption leading to unexplanable behavior, quite a few of my old collegues love windows precisely because its so easy to craft exactly what that insane behaviour is there.

Also pretty sure thats not the last of them, just the only one I could do anything about.

[benrussell 20]

1 minute ago, mSparks said:

can crash

or it could just wreck a function that would then on ctd when the function is called

or it could just put a noop in the function and the button would stop working

or it could overwrite some data space and the ap would suddenly flip out and nose dive the plane into the ground.

etc etc.

memory corruption leading to a ctd is much rarer than memory corruption leading to unexplanable behavior, quite a few of my old collegues love windows precisely because its so easy to craft exactly what that insane behaviour is there.

Also pretty sure thats not the last of them, just the only one I could do anything about.

I wrote the repro.

It's crash, 100% of the time when the ram is released.

In the meantime, it _might_ have clashed with your memory.

It still remains incredibly rare that anything scripted is asking x-plane for 16mb chunks in one contiguous blob.

 

[mSparks 2,086]

6 minutes ago, benrussell said:

It's crash, 100% of the time when the ram is released.

[Cameron XA 272]

ANYWAYS...

I'm glad we could clear up the fact that this was not any issue that ever affected a Gizmo enabled product for our customers. I'm not sure where you had ever got that idea.

We were the ones to report the bug, and it was only in our own internal testing under a unique situation that never once made it to customers' computers.

I cannot speak for SASL or xLua. Only Gizmo.