fbpx

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

More
11 months 6 hours ago - 11 months 6 hours ago #1 by Boonnam S
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
Attachments:
Last edit: 11 months 6 hours ago by Boonnam S.

Please Log in or Create an account to join the conversation.

More
11 months 6 hours ago #2 by Chris Pyrgas
Replied by Chris Pyrgas on topic VS is crashing often after v1.1.1 and v1.1.2
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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
10 months 4 weeks ago #3 by Boonnam S
Replied by Boonnam S on topic VS is crashing often after v1.1.1 and v1.1.2
My PC have 16 GB, and Windows is automatically managing virtual memory.

Please Log in or Create an account to join the conversation.

More
10 months 4 weeks ago #4 by Chris Pyrgas
Replied by Chris Pyrgas on topic VS is crashing often after v1.1.1 and v1.1.2
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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
10 months 4 weeks ago #5 by Robert van der Hulst
Replied by Robert van der Hulst on topic VS is crashing often after v1.1.1 and v1.1.2
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)\XSharp\VOXPorter" 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

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

More
10 months 4 weeks ago #6 by Boonnam S
Replied by Boonnam S on topic VS is crashing often after v1.1.1 and v1.1.2
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.

Please Log in or Create an account to join the conversation.