Memory can not be "Read" Erro

Memory can not be "Read" Erro

Hi Guys,

I am using FORTRAN as my coding language for ASPEN PLUS. Frequently I come across an error which says :

                     " Instruction at "0x749860b0" refernced at "0x000000000". The memory can not be "read".

Is this error due to system Hardware issues (I have 2 GB RAM)?

Can you please help me to resolve this error.



11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

No - it is a software (i.e. probably your code) issue.  For whatever reason, your code is looking for data at a memory address of zero.  There is never any valid data for a program at that address and the operating system responds appropriately by issuing the error.

It has been a few years now (developing custom models for Aspen Plus is why I started using Fortran), but I found it very easy to make mistakes when interfacing Fortran code and Aspen Plus (long argument lists, extensive use of large common blocks, weak typing, hollerith everywhere).  Chances are you have some sort of mismatch between your code and what Aspen Plus wants or provides, or perhaps there is some other logic error in your code.

I can't provide accurate details due to the passage of time, but you can compile a debug version of your code and then run (or attach to) the aspen plus model under the Visual Studio debugger.  This may give you more insight into where the problem is occurring.


Thanks Ian for the response. I am quite new to FORTRAN language. Can you please guide me how to carry on the process you have mentioned. 

Thanks in advance.


It is highly likely that the argument lists are not what you expect.  Look carefully at the number and type of arguments in your code and in what AspenPlus is expecting.  Be careful becuase the AspenPlus F77 code will use implicit typing of variables, so the types may be what you expect.  Also, check for any misspelling of variable names, which again could lead to undefined or uninitialized variables.




Thanks for the response.

I was able to run the program earlier without any glitches. I did some changes in Previous block's code and now it has started to show this error.

In this program I am using IVPRK function to solve 15 differential equations. I am able to run it for 50% of total 100 steps  and but after that it shows this particular error. In my previous encounters with this error, I was able to resolve it by changing PARAM(3) parameter (Increasing this parameter from 10-5 to 10-4 sometimes resolves the issue). But this time, there seems no solution to it.


Are you calling IVPRK from inline code in A+,or areyou calling your own function?

I would assume that IVPRK is sufficiently debugged and robust that I would not expect this error to be coming from there.  I still suggest that there is something wrong with your A+ calling code - in particular the routine interfaces.  If you can write out the arguments to the logfile immediately after entering your code, it may point to where the error is coming from (I know this can be done in ACM, but I've never done it in A+).  It is likely that an argument has the wrong type and is not being passed correcty.




Rajesh S. wrote:

Thanks Ian for the response. I am quite new to FORTRAN language. Can you please guide me how to carry on the process you have mentioned. 

Too long ago for me to remember details I'm afraid - and I no longer have access to an Aspen Plus environment to check (details may have also changed).  This is also not really a Fortran language question - more around how to use the tools available.  Explaining how to use those tools is not trivial.

I emailed a colleague who has used A+ for many years.  Here is his reply:

Not sure if I can add any suggestions to what you and Ian have already made. I have come across this error in my lifetime. Unfortunately I can’t remember the circumstances but I’m pretty sure it would have been one of the things that have been mentioned. To re-state,

  • Check all COMMON blocks and arguments in subroutine calls, specially that all variables are double precision, dimensions, the order and number of arguments
  • It is not an error caused by a problem in the memory hardware, but I think 2GB RAM may be too little, try at least 4GB.
  • I’m not familiar with the IVPRK function but does the fact that changing the PARAM(3) parameter from 10-5 to 10-4 helped in the past, give us a clue? Does he mean he changed it from 10.5 to 10.4 or from 10 to 5 and from 10 to 4?
  • Compare the code in the previous version (where it worked) with the current version (where this error appeared).
  • Is the Fortran in question coded in-line in the model, e.g., within a Fortran block or design-spec, or is it in an external user subroutine (e.g., unit operation, property, kinetics etc.)?

You can write to a file from a Fortran block or user subroutine as follows: write (nhstry,*) xyz or write (ntrmnl,*) xyz. Nhstry and ntrmnl are the I/O unit numbers of the history file and terminal (control panel) output file. They are available through the argument list of the subroutines that are generated to handle fortran blocks (zzfort) and design-specs (zzspcs). The body of these subroutines contains the user’s Fortran code, thus the user can use these statements directly in that code:


     +                  IZNSAM, IMISS,  RMISS,  IPASS,  ICONVG,

     +                  LMSG,   NHSTRY, NTRMNL, NRPT,   KOUNT,

     +                  JPASS,  NBOPST)





     3                  IZNUNC,ZZSPC1,ZZSPC2,ZZTOLR,ZZLOWR,

     4                  ZZUPPR,NHSTRY,NTRMNL,NRPT,  IMISS,

     5                  RMISS)                          

The unit numbers are also available to user subroutines (I think as USER_NHSTRY, USER_NTRMNL) through system COMMONs inserted via include statements e.g. #include "dms_global.cmn". Can’t find the source for the system commons at this stage, but they are somewhere in the package.


Thanks David and Ian for the efforts.

I talked with A+ guys on friday. Apparently, Param(3) was the cause of error. In my function I also using ZBREN function to find the root of an equation. upper and lower limit given were incorrect and thats why it keeps on showing same sign on both limits and hence the error. (Higher param(3) i.e, 0.001 instead of 0.00001 led to less smooth curve and it sometimes went outside of Zbren limit)

I think i should use some function which solves an equation without asking for upper and lower limit (To be future proof). Can you suggest one?

>>>   " Instruction at "0x749860b0" refernced at "0x000000000". The memory can not be "read".>>>

That's mean that code(instruction) at virtual memory address 0x749860b0 referenced probably null pointer. It is software error. You can  inspect with debugger faulting code.


Rajesh S. wrote:
I think i should use some function which solves an equation without asking for upper and lower limit (To be future proof). Can you suggest one?

Zbren has the convention that the user should call it with a root bracketed. It would be nice if it checked the input arguments to see if this requirement is satisfied, but there would be a price to pay for needless checking.

It may be convenient to try to avoid providing a bracket, but the results can be disastrous. Consider a real function such as x^2-4x+8, whose zero you wish to find. You can give -1e20, +1e20 as the root brackets, but Zbren will still fail, because there is no real root for this function. Next, consider x tan(x) - 10 = 0. Again, if you give a wide range, you will run into problems because the equation has multiple roots, and the numerical root finding subroutine may yield different roots depending on the starting bracket/starting value given to it.

Leave a Comment

Please sign in to add a comment. Not a member? Join today