[Vm-dev] VM Loaded?

[David T. Lewis]

On Thu, Apr 11, 2019 at 04:20:10PM -0400, Ron Teitelbaum wrote:
>  
> Hi All,
> 
> When processing the command line I ran into an interesting problem.  When
> running normally everything processes fine but if I'm also running Immunet
> which is scanning the VM for viruses as it starts up a quick command line
> can run into something that is not properly loaded and crash.  If I shut
> down the virus protection it runs fine, if I start the application first
> and then process the command line it runs fine.
> 
> Is there something I can check in the image to know that the image is fully
> loaded before processing the command line arguments?
> 

Hi Ron,

I am more familiar with the Unix VMs, but I think that what I will say here
applies to any of the compiled VMs.

When the VM and image are first started, the following things happen:

- VM executable is loaded and begins execution. it is not yet in the
  interpreter, but is loaded and running.

- Memory is allocated to contain the object memory.

- Contents of the image file are read into the allocated memory.

- The object memory is scanned, updating object pointers to match the
  position of the allocated memory

- The interpreter loop is entered.

- Smalltalk stuff happens, such as processing a command line.

The object memory scan for fixing pointers seems key with respect to
the problem you are seeing, because it means that both the VM executable
and the object memory are fully load prior to Smalltalk execution, and
also that (in most cases) memory locations will have been written
throughout the object memory space.

I am not entirely certain if the pointer fixups happen (or happen
always) on Windows, because the fixups are needed only if the memory
is loaded to a different virtual memory address than were in effect
when the image was last saved. Someone with better Windows experience
may be able to confirm or deny it.

In any case, it seems likely that both the VM executable and the
complete object memory will have been fully loaded prior to executing
anything on a command line.

The only other ideas I can think of are that 1) it might be somehow
related to jitted code, since the jit code generation kicks in after
Smalltalk is running, or 2) it might be somehow related to external
file or socket handles from the previous session, which are invalid
but possibly might confuse a virus scanner. 

I really can't guess what is going on here, but possibly the above
will prompt some better ideas from someone else.

Dave