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? Thanks! All the best, Ron Teitelbaum |
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 |
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: 6117E9C0Access 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) PNGReadWriter0x950188 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 <[hidden email]> wrote: On Thu, Apr 11, 2019 at 04:20:10PM -0400, Ron Teitelbaum wrote: |
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 <[hidden email]> 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 > > > > > > SmalltalkImage-jpegPluginLoaded.st (366 bytes) Download Attachment |
Free forum by Nabble | Edit this page |