VS is crashing often after v1.1.1 and v1.1.2

[boonnam]

Hello XSharp team!

I am using version 1.1.2. With this version and version 1.1.1, my VS is crashing often again. The error is "Assertion Failed". I attached the JPG. This crash happened while I'm trying to edit my codes, or even clicking within the comment line for update the comment. I also happened during compiling. When I click on the spot I need to edit, VS would pause momentarily. Once the pause is gone, I could type. The pause would come back again as soon as I finished typing or try to move to other area.

Yesterday, this crash even happened when I comment out a line of code, and then hit the "End" and "Tab" buttons to add more comments.

I am using VO dialect. This solution contains 11 projects.

Before version 1.1.1, VS was stable.

Thanks,
Boonnam

[Chris]

Hi Boonnam,

That's an out of memory problem. I think we need to improve the (amount of) memory usage of both the compiler and the VS integration, but if you can add some more memory to your system (and/or not use many other memory-hungry programs) should help.

Please also check your Virtual memory system options, in control Panel/System/Advanced System/Settings/Performance/Advanced/Virtual memory/Change (yes, I know, MS could had buried it a little bit deeper...), is this option set to automatic? If yes, please turn automatic one, as another developer had set this to a manual size and had similar memory problems with VS, but once he turned it to automatic (so windows has more freedom to allocate and release memory) the problems were gone.

Chris

[boonnam]

My PC have 16 GB, and Windows is automatically managing virtual memory.

[Chris]

Hi Boonnam,

It can still be filled up, especially if the projects are very large. When this happens again (VS has low response), please open the Task Manager and check how much memory is used by devenv.exe (VS) and XSCompiler.exe (the compiler process). The compiler process you can safely kill it if it has taken too much memory (and you are not compiling at that moment of course!).

Robert is looking into decreasing the memory footprint, I hope we'll have some improvements in this area soon. In the meantime, just make sure you do not have other memory hungry tools loaded as well, to help with this.

Chris

[robert]

Boonnam,

- Are you working with very large source files ?
- Are you using many #include files, such as VOWin32ApiLibrary.vh

At this moment the VS IDE parser is always parsing the #include files as well, since there could be UDCs hidden in these files. And it does that for every change you make in the editor. However the standard Vulcan Header files only contain #defines.

For the next update we will only parse #include files that contain UDCs (so we will parse them once to determine this) so the parser speed (and memory usage) will be better.
Hopefully that helps to avoid the memory problems.

What you can also do this moment is comment out the #include lines for the common Vulcan header files and add a reference to the file SDK_DEFINES.dll in the
"c:Program Files (x86)XSharpVOXPorter" folder.
This replaces the #defines that Vulcan needed with the X# style DEFINES.
If you want to use the same source with Vulcan as well, then I would advise to leave the #include lines unchanged and surround them with #ifndef __XSHARP__ .... #endif. That way the files are not included when compiled by our compiler.
That should already make a difference.
And if you have lots of defines in GLobalDefines.vh I would also recommend to convert these from #defines to DEFINES

So
#define WND_TIMER_ID 1205
#define DELAY_QUIT 0

becomes
define WND_TIMER_ID := 1205
define DELAY_QUIT := 0

This will most likely NOT work for defines generated by the Vulcan menu editor.
Our menu editor does not have this problem since it generates DEFINES in the PRG file and includes #defines in the generated RC files. It does not use the Globaldefines.vh to store menu defines.
In the same way our Form editor generates STATIC DEFINES for control IDs in the PRG and includes #defines in the generated RC file, including the #defines for windows styles etc so there is no need to include VOWin32ApiLibrary.vh anymore in generated RC files.
Of course this will make the generated source incompatible with Vulcan because vulcan does not know the DEFINE syntax.
If your globaldefines.vh contained #defines that were also available in one of the Vulcan header files, you might see a warning 9043 about ambiguous fields since the compiler then does not know which definition to use, the one from your app or the one in SDK_Defines.DLL


Robert

[boonnam]

Thank you, Chris and Robert!

This project was xport from VO. I did some search. There are 79 #define. Zero #include. The largest project has 60 prg files. Roughly 11.8 MB in total size. I will keep an eye out for the memory usage.