[Vm-dev] VM Loaded?
David T. Lewis
lewis at mail.msen.com
Sat Apr 13 16:17:57 UTC 2019
D'oh! I did not think about plugins. So the external plugins are loaded
on first reference, in this case when referenced by the command line.
Presumably the virus checker is hooking into the module loading and
checking things before allowing the plugin to be executed. I don't
know how those things work, so I can't really guess what the actual
failure is coming from.
For purposes of debugging, you may be able to figure out more by
checking Smalltalk listLoadedModules as in the attached hack.
If the problem is specific to the JPEG plugin, then one possible
workaround would be to compile the plugin as an internal plugin.
That would ensure that it is loaded as part of the VM startup, so
that a later load on demand would not be needed and the virus
scanner would not need to separately check the plugin dll.
Dave
On Fri, Apr 12, 2019 at 11:11:30AM -0400, Ron Teitelbaum wrote:
> Hi Dave,
>
> Thanks! The particular error here is a failure to initialize a png plugin.
> We are definitely in the command line. I would imagine a delay to allow
> the virus checker to finish would fix this problem but it would be better
> to know if we can proceed if that is even possible. Notice the
> LdrResolveDelayLoadsFromDll maybe error handling at this point would work
> if it fails the problem may be scanning?
>
>
> Exception code: C0000005
> Exception addr: 6117E9C0
> Access violation (read access) at 7E31C014
> EAX:7E31C014 EBX:00000000 ECX:00000014 EDX:0000000E
> ESI:0002C014 EDI:0094D47C EBP:0094D40C ESP:0094D3C0
> EIP:6117E9C0 EFL:00010206
> FP Control: 0000027F
> FP Status: 00004022
> FP Tag: 0000FFFF
>
> Crashed in the VM thread
>
> Stack backtrace:
> [6117E9C0] ??? + 0 in (null)
> [6117F0F4] ??? + 0 in (null)
> [6117F8D2] ??? + 0 in (null)
> [6118024D] ??? + 0 in (null)
> [61181DA4] ??? + 0 in (null)
> [77779FCF] LdrUnregisterDllNotification + 2127 in ntdll.dll
> [77769E4E] LdrParentRtlResetNtUserPfn + 2062 in ntdll.dll
> [77781D7A] LdrResolveDelayLoadsFromDll + 1418 in ntdll.dll
> [777635EB] RtlDosSearchPath_U + 683 in ntdll.dll
> [7776D25F] LdrShutdownProcess + 1167 in ntdll.dll
> [77777279] RtlGetAce + 3641 in ntdll.dll
> [7777AEEB] RtlConsoleMultiByteToUnicodeN + 2763 in ntdll.dll
> [7777B1B3] LdrParentRtlRetrieveNtUserPfn + 147 in ntdll.dll
> [6117E6E2] ??? + 0 in (null)
> [6118907C] ??? + 0 in (null)
> [00A71000] ??? + 0 in (null)
> [75E5AB86] LoadLibraryW + 38 in kernelbase.dll
> [75E5A9C2] LoadLibraryExW + 50 in kernelbase.dll
> [0043BCC1] ??? + 244929 in Terf.exe
> [0043BD0A] ??? + 245002 in Terf.exe
> [004470D5] ??? + 291029 in Terf.exe
> [00447212] ??? + 291346 in Terf.exe
> [00447429] ??? + 291881 in Terf.exe
> [0040D8F1] ??? + 55537 in Terf.exe
> [0041E94D] ??? + 125261 in Terf.exe
> [0042373C] ??? + 145212 in Terf.exe
> [00423C14] ??? + 146452 in Terf.exe
> [0043E2F5] ??? + 254709 in Terf.exe
> [0043E603] ??? + 255491 in Terf.exe
> [00521C0D] ??? + 1186829 in Terf.exe
> [004010BB] ??? + 4283 in Terf.exe
> [004012C8] ??? + 4808 in Terf.exe
> [77620419] AcquireSRWLockExclusive + 25 in kernel32.dll
> [7779662D] RtlGetCompressionWorkSpaceSize + 237 in ntdll.dll
> [777965FD] RtlGetCompressionWorkSpaceSize + 189 in ntdll.dll
>
> Primitive trace:
> findFirstInString:inSet:startingAt:
> primOpen:writable:
> shallowCopy
> primitiveWait
> basicNew
> new:
> at:put:
> at:put:
> signal
> basicNew:
> species
> basicNew:
> basicNew
> ensure:
> valueNoContextSwitch
> basicNew:
> size
> basicNew:
> replaceFrom:to:with:startingAt:
> size
> primRead:into:startingAt:count:
> at:
> shallowCopy
> basicNew
> new:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> shallowCopy
> new:
> replaceFrom:to:with:startingAt:
> at:put:
> value:
> on:do:
> value
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> -
> +
> basicNew:
> value:
> on:do:
> value
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> value:
> on:do:
> value
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> basicNew:
> size
> basicNew:
> size
> replaceFrom:to:with:startingAt:
> at:
> primGetPosition:
> basicNew:
> at:put:
> at:put:
> at:put:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> replaceFrom:to:with:startingAt:
> basicNew
> findNextHandlerContextStarting
> tempAt:
> tempAt:
> tempAt:put:
> ensure:
> valueNoContextSwitch
> tempAt:
> valueWithArguments:
> findNextUnwindContextUpTo:
> tempAt:
> tempAt:put:
> tempAt:
> terminateTo:
> value
> tempAt:put:
> findNextUnwindContextUpTo:
> terminateTo:
> value:
> on:do:
> value
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> basicNew:
> replaceFrom:to:with:startingAt:
> primJPEGPluginIsPresent
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> value:
> on:do:
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> primJPEGPluginIsPresent
> value:
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> primSize:
> species
> basicNew:
> size
> replaceFrom:to:with:startingAt:
> =
> species
> basicNew:
> -
> +
> replaceFrom:to:with:startingAt:
> +
> =
> bitShift:
> at:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> =
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> basicNew
> basicNew:
> decompress:fromByteArray:at:
> beCursorWithMask:
> ensure:
> size
> basicNew:
> size
> replaceFrom:to:with:startingAt:
> -
> +
> at:
> at:put:
> at:put:
> at:put:
> at:put:
> basicNew:
> at:put:
> basicNew
> basicSize
> basicNew
> @
> @
> basicNew
> basicNew
> basicSize
> copyBits
> basicNew
> basicNew
> new:
> basicNew
> new:
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> +
> <
> pngPluginVersion
>
>
>
> Smalltalk stack dump:
> 0x950168 I PNGReadWriter>nextImage 295516516: a(n) PNGReadWriter
> 0x950188 M [] in ImageReadWriter class>formFromStream: 273588992: a(n)
> ImageReadWriter class
> 0x9501a8 M BlockClosure>ensure: 295516628: a(n) BlockClosure
> 0x9501d0 I CursorWithMask(Cursor)>showWhile: 273290060: a(n)
> CursorWithMask
> 0x950200 I ImageReadWriter class>formFromStream: 273588992: a(n)
> ImageReadWriter class
> 0x950228 I Form class>fromBinaryStream: 273599436: a(n) Form class
> 0x950250 M [] in QForms>import:from: 295487508: a(n) QForms
> 0x950270 M BlockClosure>ensure: 295506324: a(n) BlockClosure
> 0x9502a4 I [] in QForms>import:from: 295487508: a(n) QForms
> 0x9502c0 M BlockClosure>on:do: 295501124: a(n) BlockClosure
> 0x9502f8 I QForms>import:from: 295487508: a(n) QForms
> 0x950324 I QForms>initialize 295487508: a(n) QForms
>
>
> On Thu, Apr 11, 2019, 11:09 PM David T. Lewis <lewis at mail.msen.com> wrote:
>
> > 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
> >
> >
> >
-------------- next part --------------
'From Squeak4.6 of 11 December 2017 [latest update: #15117] on 13 April 2019 at 12:07:55 pm'!!SmalltalkImage methodsFor: '*kludging' stamp: 'dtl 4/13/2019 12:07'!jpegPluginLoaded "True if the JPEG plugin is an external plugin that has been loaded" "Smalltalk jpegPluginLoaded" self listLoadedModules detect: [ :e | 'JPEG*' match: e ] ifNone: [ ^false ]. ^true.! !
More information about the Vm-dev
mailing list