waldo: Insufficient stack to continue executing the program safely

[Blog bot]

Источник: https://dynamicsuser.net/nav/b/waldo...program-safely
==============

The better half ofmy past week can be summarized best by this oh-so-descriptive-error-message:

Right: a message Ihave spent a long time on to find out what was happening – and what causedit. Multiple days – so let me try tospare you the pain when you would encounter this error.

(tip: if you don’tcare about the story, just skip to the conclusion ;-)).

History

We are rebuildingour product to Business Central – and are almost finished. In fact, we have spent about 500 daysbuilding it – and since the recent release of Wave 2, we are fully in theprocess of upgrading it – because obviously, since all is extensions (we have acollection of 12 dependent extensions), that should be easy. (think again – Wave 2 came with a lot of breakingchanges … but that’s for another blogpost ;-)).

Symptoms

Our DevOps buildshad been acting strange for a while – just not “very” strange ... In fact: when a build failed with astrange error (yep, the above one), we would just retry, and if ok, we wouldn’tcare.

That was a mistake.

Since our move toWave2 .. the majority of the builds from only 1 of the 12 apps failed – andeven (what never happened before), the publish from VSCode failed as well withthe same error message:

Insufficient stack to continue executing the programsafely. This can happen from having too many functions on the call stack orfunction on the stack using too much stack space.

We are developingwith a team of about 9 developers – so people started to NOT being able tobuild an environment, or compile and publish anymore. Sometimes.

Yes indeed: sometimes. I had situations where I thought I had a fix, and after 10 builds orpublishes – it started to fail again.

And in case youmight wonder – the event log didn’t show anything either. Not a single thing. Except from the error above as well.

Whatdidn’t help

I started to look atthe latest commits we did. But that wasmainly due to the upgrade – stuff we HAD to do because of the breakingchanges Microsoft introduced in Wave 2.

Since it failed atthe “publish” step, one might think we had an install codeunit thatfreaked out. Well, we have quite a fewinstall-codeunits (whenever it makes sense for a certain module in that app) ..I disabled all of them – I even disabled the upgrade-codeunits. To no avail.

Next, I started tolook at the more complex modules in our app, and started to remove them ..Since one of the bigger modules had a huge job during install of the app – ANDit publishes and raises events quite heavily, I was quite sure it was thatmodule that caused the pain. To test it,I removed that folder from VSCode, made the code compile .. and .. thingsstarted to work again. But only shortly. Moments later, it was clear in DevOps thatcertain builds started to fail because of the exact same error. From victory .. back to the drawing board;-).

Another thing wetried was playing with the memory on our build agents and docker hosts. Again, to no avail .. that absolutely didn’thelp one single byte.

…

And I tried so muchmore .. really. I was so desperate thatI started to take away code from our app (which we have been building for over6 months with about 9 developers (not fulltime, don’t worry ;-)). It’s a whole lot of code – and I don’t knowif you ever tried to take away code and make the remaining code work again ..it takes time :-/. A lot!

Whatdid help

It took so muchtime, I was desperately seeking help .. and from pure frustration, I turned toTwitter. I know .. not the best way toget help .. but afterwards, I was quite glad I did ;-).

You can find theentire thread here:

I'm getting desperate here .. anyone has seen this error when publishing from VSCode? (or buiding from DevOps). #AL #msdyn365bc
No installcode, no upgradecode, enough memory, no code analysis issues, …. pic.twitter.com/QM8PVKgZ8u

— waldo (@waldo1001) October 25, 2019

First of all: thanksso much for all of the people for their suggestions. There were things I didn’t try yet. There were some references to articles Ididn’t find yet. All these things gaveme new inspiration (and hope) .. which was invaluable! Translation files, recursive functions, eventlog, dependencies, remove all code, force sync, version numbers, …

Until phenno mentioned this:

Have you checked this (similar) issue? https://t.co/k1FvZj0xKM

— phenno (@phenno1) October 25, 2019

Exactly the sameerror message, with a big xmlport. Itfirst pointed me to the wrong direction (recursive functions / xmlport) ..

But after one of ourdevelopers remembered me that from months back, we also had a big object: A1.2Mb codeunit, auto generating all Business Central icons as data in a table,to be able to use them as icons in business logic. Initially I didn’t think it would ever havean effect on the stability of the app (in this case – the inability to publishit) .. we wrote the damn thing more than 4 months back, for crying out loud :-/and the code was very simple – nothing recursive, no loops, very straightforward. Just a hellofalot of code;-). But .. It doesn’t hurt to try whatit would do when I would remove the code .. so I tried .. and it worksnow! Victory!

Conclusion

The size of a file (or object) does matter. If you have the error above – it makes senseto list your biggest files, and see if you can make them smaller by splittingthe objects in multiple (if possible.. ).

While in our case,it was one huge object in one file. AndI don’t know what exactly was the problem: the size of the file, or the size ofthe object. There is a difference. If I wanted to have kept the functionality, Imight have had to split the object in multiple codeunits, and on top of that Imight have had to split them in multiple files (which – in my honest opinion –is best practice anyway..).

Also, I have thefeeling that Wave 2, is a bit more sensitive to these kind of situations.. Idon’t know. It’s just – we had this filefor quite a while already, and it’s just with the upgrade to Wave2 that itstarted to be a problem.

In any case – I hopeI won’t wake up tomorrow, concluding the error is back and all the above wasjust one pile of crap. Wish me luck ;-).




Источник: https://dynamicsuser.net/nav/b/waldo...program-safely