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