OutOfMemoryException

I am get this error after 15 minutes.  

Can I control the loading process?

Is there a document that describes the loading process?

ProcessRun: tmp = C:\ACCOUNTS\DEV10\IO\MGR01.io

ProcessRun: runProg = C:\MF-SYSTEM\WORKBENCH\BIN\ORDERMGT.EXE

ProcessRun: runProg = C:\MF-SYSTEM\WORKBENCH\BIN\ORDERMGT.EXE /P:C:\ACCOUNTS\DEV

10\IO\MGR01.io /D:C:\LISTENER\DEV10\DEV10.CONFIG

Unhandled Exception: OutOfMemoryException

Exception of type 'System.OutOfMemoryException' was thrown.

at Void  ORDERMGT.Main._MF_PERFORM_4_642(Int32 start_end)

at Int32  ORDERMGT.Main.Main()

at Int32  ORDERMGT.Main._MF_ENTRY()

  • What product and version number are you using?

    It looks like managed code so I am assuming Visual COBOL or Enterprise Developer?

    How are you starting the program?

    Can you run it under control of the debugger?

    Thanks.

  • Visual Cobol for visual studio 2012.

    No I can not run with the debugger.

  • So the application was compiled with Visual COBOL for Visual Studio 2012.

    Are you running the application on this same development system or are you running it under COBOL Server 2012 on a different computer?

    I am unsure of the question that you are asking about program loading.

    What is it that this program is doing?

    If the program has been running for 15 minutes before the out of memory error occurs then most likely the application is continuing to grow up until this point either because of recursive processing or it is calling additional modules.

    Can you please clarify what the program is doing up until the point of error?

    It is likely that you will have to open up a support incident with MF Customer Care for this problem as we will most likely need to set up tracing and/or get a recreate of the problem to run in-house.

    Thanks.

  • I am running on the same machine as the program was compiled on.

    Loading a large program.

    Are subroutines added to the program as they are called?

    Are there tips to breaking up large programs?  Will the use of SECTIONS in the PROCEDURE DIVISION help?

  • I am running on the same machine as the program was compiled on.

    Loading a large program.

    Are subroutines added to the program as they are called?

    Are there tips to breaking up large programs?  Will the use of SECTIONS in the PROCEDURE DIVISION help?

  • I am running on the same machine as the program was compiled on.

    Loading a large program.

    Are subroutines added to the program as they are called?

    Are there tips to breaking up large programs?  Will the use of SECTIONS in the PROCEDURE DIVISION help?

  • It is hard to give suggestions without seeing the program in question.

    If you are dynamically calling subprograms that are in other assemblies, then those assemblies will be loaded into the same process space as the calling program at the time they are called.

    If you are statically calling subprograms that are in other assemblies and the reference to the assemblies can be made at compile time then these assemblies will be loaded when the application starts.

    If you open up the Windows Task Manager while the program is running you will be able to monitor the process size as it grows.

    Splitting up the procedure division into sections and paragraphs can change how the compiler generates the code but it is unlikely to help in this situation as all of the code will be loaded when the program is run.

    Do you have any large data areas in the program like tables that may have large data records with many occurrences, etc.

    What is the size of the .EXE file that is produced for this application?

    What is the program doing when the Out of Memory error occurs?

    Is it calling a specific module or does this error occur in different locations of the application.

    If you would like us to look at the application, please open up a support incident with Customer Care.

    Thanks.

  • The program is loading a large subroutine when this problem occurs.

    Is there a limit to "process space"?   If so how big.

    when compiling with native mode data 10,845, 704  lits 43,312 code 3,621,417 

  • Verified Answer

    Customer opened up a support incident for this problem of running out of memory when loading a large managed code program in a .dll.

    I will post the solution to the reported issue here for sake of completeness.

    The problem really had nothing to do with the actual size of the program but it was caused by some overlapping perform ranges and errant go to statements that referenced paragraph labels which were outside of the current perform range.

    This can cause the compiler to generate incorrect code as it tries to place the referenced paragraph or section into the same method as the paragraph or section where the go to statement resides.

    program structure looked something like this. (only program > 150K lines)

    100-start.

          perform 200-process thru 200-exit

          perform 300-process thru 300-exit

          stop run.

    200-process.

          perform whatever

          perform whatever2

          if something

             go to 300-exit

          end-if

    200-exit.

         exit.

    300-process.

          perform whatever3

          perform whatever4

          go to 300-exit

    300-exit.

         exit.

    -----------------

    The problem was go to 300-exit instead of 200-exit in the 200-process paragraph.

    There is a directive called RESTRICT-GOTO which will flag these kind of errors when sections are being used but it does not work when only paragraph ranges are being used.

    Development is currently looking at providing some type of automated analysis of this type of problem.