Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025

 


Article

ABL COMPILE statement fails and crashes AVM with error 290

« Go Back

Information

 
Article Number000098855
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 NumberDefect OCTA-16825
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 we open the r-code file for writing, we make 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
None at this time.
 
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
Attachment 
Last Modified Date1/17/2020 6:28 PM