OpenRoads Out of Memory Crashes

Hi all,

We are having problems with OpenRoads in MX SS4 running out of memory after repeated processing of large corridors. It seems that OpenRoads doesn't release all its memory usage on every corridor processing run so eventually we get to approx. 2500Mb of memory usage and it crashes with a "System out of Memory" message.

We are running Windows 8.1 64-bit with 32Gb of RAM. We have also got the "Lock Pages in Memory" setting enabled in Windows, but that doesn't seem to have changed anything. Is anyone else having similar issues?

  • You're hitting the 32-bit application memory limit.  The limit for any 32-bit application is approximately 4 GB if programmed appropriately.  

    This is the reason for the anticipation for the Connect Edition of OpenRoads...64 bit application which allows much more memory to be used.

  • But shouldn't it switch to paging once it uses all the available 4Gb of memory (Virtual)?
  • No...any 32 bit application cannot use anymore than 4GB of memory...even if you have 128GB of memory on the machine.  The application wouldn't use paging file space unless the OS was running out of available memory for the application.  Page file space was a big deal years ago when computers were only outfitted with lower amounts of memory.

    For example, if you ran Windows NT 4.0/2000/XP (32 bit OS) on a machine that had 4GB of memory, the OS itself took about 1GB off the top to support itself.  Apps running on the OS then only could max out to 2GB (potentially 3GB) of memory for themselves due to programming limits.  That meant if you were running MicroStation/InRoads back then and were using about 1.5GB of memory (larger dataset), that meant only 1.5GB of memory was available for other apps running at the same time.  If you were a "multi-tasker" at the time...running Outlook, Winamp, photo editor at that time, etc., you could have exceeded the available 1.5 GB remaining.  If this was the case, this is when the page file was utilized...basically to off load memory from the memory module to "on-disk" storage to keep the application alive while you were trying to utilize the memory for other active applications.  This is why years ago you could alt-tab between applications and literally wait for a minute for your pc to react....waiting for the application you wanted to use to be read into memory and offload a different apps memory back to disk.

    MicroStation had a switch added to it years ago to attempt to address more than 4GB of memory on 64bit machines outfitted with more memory...I never did see it work myself.  Kept bombing MicroStation even with the switch set once I hit the 3.5+ GB memory usage.

    I don't believe InRoads/Geopak/MX were ever programmed with that same theoretical switch.

    Nowadays though, most people load enough memory onto their machine (running 64 bit OS) that the page file almost becomes not needed....almost, that is until the application(s) finally go 64 bit (Connect Edition).  At that time, even if you had a 32GB machine, you could potentially need the page file depending on what you have running and dataset sizes.

  • hmm...I just tried adding the MS_MEMORY_FREELIMIT config variable (the one you may have been referring to) with 999Mb (max virtual memory free limit allowable) and it seems to actually be working, ie. paging once it hits the 999Mb free limit for virtual memory.

    Now the question is why doesn't it page when the default (150Mb) value is used. Of course CONNECT 64-bit will resolve all these issues, but unfortunately we are stuck with 32-bit for our current project.

  • What version of the software are you running? Prior to version 845 this was a serious problem. It has been improved even more in the 872 and 878 versions of the program. I would suggest you move to one of the newer versions. I am running 878 with huge corridors and almost never see this error anymore.