Strange Messages During Class Compilation (oops: ...)

During programmatic classes compilation performed by the code like this:

set status=$system.OBJ.Load(updaterFile,"cruk-d",,.resList)

strange messages appear in console log, e.g.

05/06/18-15:54:12:424 (308512) 0 oops: was expecting crc 0x21e96e85,5a4c8b2c for rtn (Update.Import.1) rbufnum-15523
...
05/06/18-16:17:45:305 (4224) 0 oops: was expecting crc 0x21e96e85,5a4c8b2c for rtn (Update.Import.1) rbufnum-15523
05/06/18-16:22:30:485 (4224) 0 oops: was expecting crc 0x21e96e85,5a4c8b2c for rtn (Update.Import.1) rbufnum-15523...(repeated 3 times)

Classes that were concerned stayed not compiled (with old object code untouched) till they were recompiled manually. To be fair, it happened only ones during several years.

I met such kind of messages several years ago in our development environment during attempts to compile a class that was opened for editing by somebody else. In the case under discussion it was very unlikely as it happened in production environment with no developers on site.

What are the possible reasons of such errors? 

(Cache for Windows (x86-64) 2015.1.4)

  • 0
  • 0
  • 219
  • 10
  • 2

Answers

Could it be there was some Tune Table running that saves its statistic in Storage part of Class ?

BTW. oops is really new style surprise

only 1 .int in %SYS uses "oops:"
MIRRORCOMM.int(2845): if $zb(+$SYSTEM.Mirror.DebugFlags(),1,1) do $zu(9,"","oops: jrn.log has incorrect entry, exp("_newpath_") logentry("_jrnfname_"), file num-"_mirfilecnt)
 

 could be an indicator to some MIRROR issue

The message in the original description comes from the kernel, so you wouldn't be able to find it searching the code. It is not related to mirroring (though the message you reference would certainly be a mirroring issue).

Thank you for taking part, Robert.

BTW. oops is really new style

Not so new:  I met them ~ 5 years ago during bulk classes recompilation task that was scheduled in our development environment. It was one of many temporary tasks, so I don't remember the details.

These messages generally mean that a process is trying to run a routine as it is re-compiled, and the kernel realizes that the routine has changed out from under it. They don't necessarily indicate a problem, hence the informational 'level-0' message.

Thank you, Pete, 
I will pass your answer to the class developer who hesitated to write here by himself.

The developer insists that the attempt to compile the class was before its first call. Here is a fragment of his internal log. Alas, no idea how to reproduce the error as so called Updater is not a new project and runs without any problem at many production sites.

***
[06.05.2018 15:54:11.897] Starting importing classes
[06.05.2018 15:54:11.897] &runUpdateCommon.int,Update.Import
Error while importing classes: ERROR #5123: Could not find an entry point 'zguiUpdateFileAction' in routine 'Update.Import.1'
  > ERROR #5030: Error compiling class Update.Import
ERROR #5123: Could not find an entry point 'zguiUpdateFileAction' in routine 'Update.Import.1'
   > ERROR #5030: Error compiling class Update.Import
[06.05.2018 15:54:12.382] Classes sucessfully imported
[06.05.2018 15:54:12.382] Starting importing globals
[06.05.2018 15:54:12.382] There is no globalList
[06.05.2018 15:54:12.382] Starting processing afterAction
[06.05.2018 15:54:12.382] d ##class(Update.Import).update(0)
Error while processing afterAction: <METHOD DOES NOT EXIST>processAfterAction+30^updaterV201712261 
 

I just can guess for possible reasons
- dependencies in parallel compiling 
- some kind of complex or circular "CompileAfter" constructs 

those things often vanish at 2nd compile with freshly loaded classes.  (Hard to reproduce.)

In this very case Update.Import was the single class being compiled, so no parallel compiling was involved.
But its old version was running by the "parent" process, which jobbed the "child" that tried to compile a new one.

AFAIK, it's possible to compile a class which old version is running by another process, isn't it?

You are right!  
And I'm not aware of a different behavior.  Except:  oops!

Comments

Is this error happens only once, or you can reproduce it?

you said that classes not compiled after that, but what said $system.OBJ.Load, is there were some errors, too?

Thank you, Dima.
Could I reproduce, I'd call WRC.

Ther were some errors stipulated by the fact that the class was not compiled. Posting them in another comment.