Progress KB - ABL COMPILE statement fails and crashes AVM with error 290




Feedback
Did this article resolve your question/issue?

   

Article

ABL COMPILE statement fails and crashes AVM with error 290

« Go Back

Information

 
TitleABL COMPILE statement fails and crashes AVM with error 290
URL Nameabl-compile-statement-fails-and-crashes-avm-with-error-290
Article Number000117795
EnvironmentProduct: OpenEdge
Version: 11.7.5
OS: Windows
Question/Problem Description

Processes that are performing a COMPILE statement can cause other processes to crash with the below error.

When compiling code, a program that is in process of doing a COMPILE/SAVE can cause another _progres process to crash, if both sessions are reading/writing the same file.

SYSTEM ERROR: I/O error in , ret , file , addr . (290)

Stack trace from protrace reads:
 

Call Stack:
Address Frame
RaiseException
drexit
msgout
msgnCB
msgn
readit
crLoadSeg
crload
crLoadType
crFindOrGenerateType
smgetudtype
smTryTypeNameFromNode
smidnm
smidnm
smidnm
smidnm
smidnm
smidnm
smidnm
smidnm
smidnm
smidnm
smidnm
smidnm
smstmt
smsem
cr_compile
crpsrch
crrun_entry
rninterpret
Steps to Reproduce
Clarifying Information
Error MessageSYSTEM ERROR: I/O error <n> in <program>, ret <n>, file <n>, addr <n>. (290)
Defect/Enhancement Number
Cause
First, to clarify the scenario: One process is trying to compile a class file while the other is trying to read that class file in order to do a pass 1 compilation on a user of that class.

The system error does not just stem from the fact that one process has the file open for write and the other is trying to read the r-code. That by itself does not cause any problem. When the AVM opens an r-code file for writing, this is done using the share mode READ/WRITE, meaning other processes can read and write to the file at the same time!

On Unix/Linux, the AVM is able to create a temporary file, write out the r-code to that, and then at the end the file is renamed back to the correct name. However, the reason this works is because Unix/Linux has an unlink() function that works like this.

It hides the file name, but if another process has that file open, it does not interrupt what the other process is doing. When the other process is done with the file, it will get deleted. So after the temp file is created, the AVM unlink()s the original r-code file name, allowing any other process to keep reading from it, then uses link() to change the name of the temp file back to the <filename>.r.

Thus, the new compilation is now complete and the other process(es) reading the original r-code file are not disturbed.

Unfortunately, Windows does not provide this same unlink functionality. It does have an unlink() function, but it does not behave the way the Unix/Linux one does. It simply deletes the file.
 
Resolution
The ABL COMPILE statement is not synchronized with any other ABL sessions.  As such, compiling individual files in a common code base when applications are using that same code base for either compilation or execution can cause unpredictable behavior and is not advised.  

The best practice is to holistically compile a project in one ABL session prior to updating a running application.
 
Workaround
Avoid getting into a situation where you have processes reading r-code files and are recompiling them at the same time.  These are read as a full unit and, when rewritten by the compiler, may cause seek errors and potentially crash.
 
Notes
The Progress Application Server (PAS) for OpenEdge supports the ability to easily update an application in production.
 
Last Modified Date3/19/2020 5:08 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.