AL icon indicating copy to clipboard operation
AL copied to clipboard
verified publisher icon microsoft

Out Of Memory (OOM) Error Opening AL Project Folder

Open wm-camelot opened this issue 1 year ago • 2 comments

Please include the following with each issue:

1. Describe the bug When opening an AL project folder I receive the following error: image

Using Help: Start Extension Bisect I was able to narrow down the issue to the AL Language Extension for Microsoft Dynamics 365 Business Central: image

In an attempt to clear any cache files causing issues I deleted all files in the following folders:

  • C:\Users\%USERPROFILE%\AppData\Roaming\Code\Cache
  • C:\Users\%USERPROFILE%\AppData\Roaming\Code\CachedData
  • C:\Users\%USERPROFILE%\AppData\Roaming\Code\CachedExtensions
  • C:\Users\%USERPROFILE%\AppData\Roaming\Code\CachedExtensionVSIXs
  • C:\Users\%USERPROFILE%\AppData\Roaming\Code\Code Cache

Inside of C:\Users\%USERPROFILE%\AppData\Roaming\Code\Crashpad\reports I found a series of DMPs. I attached two different files that were generated during the crashes so that you may review. 05a1701c-56fc-4e52-b120-b5bef21dd499.dmp 3b91a8f1-354f-4a3c-a007-2a3f110879b8.dmp

2. To Reproduce Steps to reproduce the behavior:

  1. Open Visual Studio Code
  2. Press Ctrl+K, Ctrl+O to open the target folder
  3. Wait ~3 seconds
  4. OOM Error is produced

3. Expected behavior I would expect that I am able to open and load my AL project, allowing me to benefit from IntelliSense, code completion, and other features of the AL extension.

4. Actual behavior Instead, within ~3 seconds of opening the AL project Visual Studio Code freezes and provides the following error: image

5. Versions:

  • AL Language: 13.0.1027618
  • Visual Studio Code: 1.90.0
  • Business Central: 24.0.18037.0
  • List of Visual Studio Code extensions that you have installed:
    • AL Language Extension for Microsoft Dynamics 365 Business Central

Final Checklist

Please remember to do the following:

  • [x] Search the issue repository to ensure you are reporting a new issue

  • [x] Reproduce the issue after disabling all extensions except the AL Language extension

  • [ ] Simplify your code around the issue to better isolate the problem

wm-camelot avatar Jun 07 '24 20:06 wm-camelot

To help us investigate this, can you answer the following?

  1. Does this reproduce on a specific project/workspace, or all projects?
  2. If it is a specific project, is it particularly large? What is the estimate of the number of application objects in the project?
  3. Do you have a minimal repro project that you can share?
  4. What settings have you enabled for the extension in your settings.json?
  5. Can you share the verbose telemetry logs? To do that, do the following:
  1. In your VSCode settings.json, set "al.editorServicesLogLevel": "Verbose"
  2. Reproduce the scenario
  3. Under the path C:\Users\<username>\.vscode\extensions\ms-dynamics-smb.al-<version>\bin\win32, collect the editorservice.log and debuggerservices.log files.

thloke avatar Jun 17 '24 03:06 thloke

Answers to questions below:

  1. This is currently only an issue for one project
  2. Project is fairly large with 679 total objects, total project size (including .app dependencies) is 68.2 MB. However, I can successfully open the Base App project (version 23.0.12034.12841) from the DVD without any issues. The Base App is 8363 total objects, total project size (including .app dependencies) is 367 MB). I can open other custom projects and Microsoft projects with various sizes and total objects without issue.
  3. I don't think I have a way to share the project with you, however I did just copy the project to a different location on my C drive and the project loaded successfully when opened via VSCode. Would you have a suggestion based upon that scenario?
  4. The following settings are enabled for the extension:
    • image
    • image
  5. Attached the EditorServices.log but a debuggerservices.log was not generated upon reproducing the error (see below)

wm-camelot avatar Jun 19 '24 18:06 wm-camelot

Sorry for taking a long time to get back to this. Based on your response, it's hard for us to investigate this further without getting a dump file or loading the project in a debug build of the compiler to see what exactly is consuming all the memory. That it works when loaded from a different location on the drive is also really weird, and I'm not sure why that would change things.

To proceed, I think the best thing to do is to move this to a support case. It doesn't seem to be a general issue with the compiler, so we can't address this in the limited capacity that we have for Github issues. With a support case we'll have a bit more bandwidth, and we'd be able to receive the project for additional investigation too.

thloke avatar Sep 10 '24 02:09 thloke

Hey, no worries. I was able to get around this issue by deleting my entire repo directory and re-cloning it from Azure DevOps. This resolved the issue for me and it has not come up since, so I have no way to reproduce it for a support case. I spoke with another developer on my team and they suspected it was an issue with git, but it was just a guess. I think this issue can be closed if that's okay, and if it comes up again I can create a support ticket through normal channels. Thanks!

wm-camelot avatar Sep 10 '24 22:09 wm-camelot