[VM] Windows VM SurfacePlugin.dll LoadLibrary failure
Hi, recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Debug console # To close: F2 -> 'debug options' -> 'show output console' # To disable: F2 -> 'debug options' -> 'show console on errors' LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. ) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb 3 2017 (downloaded from files.pharo.org) This error results in Athens (and Roassal) not working, although Pharo itself seems fine. Reopening the image has no effect, and the only resolution is to do a system reboot. There is also crash.dmp from Feb 12 (possibly the day it started) containing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sun Feb 12 23:10:24 2017 Exception code: C0000005 Exception addr: 0040BDD0 Access violation (write access) at 00AFF43C EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54 EIP:0040BDD0 EFL:00010206 FP Control: 0000027F FP Status: 00000000 FP Tag: 0000FFFF Crashed in some other thread ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it. Thanks, Peter
On 16/02/2017 11:06, Peter Uhnak wrote:
Hi,
recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Debug console # To close: F2 -> 'debug options' -> 'show output console' # To disable: F2 -> 'debug options' -> 'show console on errors' LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.
) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.
) LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.
) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.
) LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.
) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.
) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb 3 2017 (downloaded from files.pharo.org)
This error results in Athens (and Roassal) not working, although Pharo itself seems fine.
Reopening the image has no effect, and the only resolution is to do a system reboot.
There is also crash.dmp from Feb 12 (possibly the day it started) containing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sun Feb 12 23:10:24 2017
Exception code: C0000005 Exception addr: 0040BDD0 Access violation (write access) at 00AFF43C EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54 EIP:0040BDD0 EFL:00010206 FP Control: 0000027F FP Status: 00000000 FP Tag: 0000FFFF
Crashed in some other thread ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it.
Thanks, Peter
Hi, I got the same problem with the latest vm some weeks ago on Windows 7. It vanished by downloading a new vm some days after. I did not try with the current latest. I'll maybe have the time to try this week end. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Well, I take that back. Today I had the same issue (with the latest VM). Closing the image and reopening it helped, but clearly there is something broken underneath. Peter On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
I got the same problem with the latest vm some weeks ago on Windows 7. It vanished by downloading a new vm some days after.
I've downloaded the latest VM and it works as expected. Thanks!
Peter
Same here, in #60442. Smalltalk vm version ---> "'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $ '" cmd ver ---> Microsoft Windows [Versión 10.0.14393] Additionally: And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script: Gofer new url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; package: 'ConfigurationOfRoassal2'; load. #ConfigurationOfRoassal2 asClass load. Martin On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
Well, I take that back.
Today I had the same issue (with the latest VM). Closing the image and reopening it helped, but clearly there is something broken underneath.
Peter
On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
I got the same problem with the latest vm some weeks ago on Windows 7. It vanished by downloading a new vm some days after.
I've downloaded the latest VM and it works as expected. Thanks!
Peter
I still do see it ocassionally too... sometimes corelated to dual-booting and network interface fuckery (by that I mean that Windows doesn't detect network, or even wireless perhiperhals like mouse... but Windows 10 yay...) for the load time... sometime firewall/AV can fuck it up... but generally it should be always slower than linux, because Windows can't files. (I am using the latest VM usually) Peter On Thu, Mar 16, 2017 at 01:11:03AM -0300, Martin Dias wrote:
Same here, in #60442.
Smalltalk vm version ---> "'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $ '"
cmd ver ---> Microsoft Windows [Versión 10.0.14393]
Additionally:
And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:
Gofer new url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; package: 'ConfigurationOfRoassal2'; load. #ConfigurationOfRoassal2 asClass load.
Martin
On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
Well, I take that back.
Today I had the same issue (with the latest VM). Closing the image and reopening it helped, but clearly there is something broken underneath.
Peter
On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
I got the same problem with the latest vm some weeks ago on Windows 7. It vanished by downloading a new vm some days after.
I've downloaded the latest VM and it works as expected. Thanks!
Peter
Hi Martin, hopefully the VMProfiler still runs on Windows so you could use it to profile the VM as it loads Rossal2 and I can help you decode the results. Alternatively you could use AndreasSystemProfiler and see which primitives are particularly expensive. But in any case, some kind of profiling would point to why things are so much slower on Windows. On Wed, Mar 15, 2017 at 9:11 PM, Martin Dias <tinchodias@gmail.com> wrote:
Same here, in #60442.
Smalltalk vm version ---> "'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $ '"
cmd ver ---> Microsoft Windows [Versión 10.0.14393]
Additionally:
And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:
Gofer new url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; package: 'ConfigurationOfRoassal2'; load. #ConfigurationOfRoassal2 asClass load.
Martin
On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
Well, I take that back.
Today I had the same issue (with the latest VM). Closing the image and reopening it helped, but clearly there is something broken underneath.
Peter
On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
I got the same problem with the latest vm some weeks ago on Windows 7. It vanished by downloading a new vm some days after.
I've downloaded the latest VM and it works as expected. Thanks!
Peter
-- _,,,^..^,,,_ best, Eliot
How does one use the VMProfiler? Phil On Thu, Mar 16, 2017 at 9:01 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Martin,
hopefully the VMProfiler still runs on Windows so you could use it to profile the VM as it loads Rossal2 and I can help you decode the results. Alternatively you could use AndreasSystemProfiler and see which primitives are particularly expensive. But in any case, some kind of profiling would point to why things are so much slower on Windows.
On Wed, Mar 15, 2017 at 9:11 PM, Martin Dias <tinchodias@gmail.com> wrote:
Same here, in #60442.
Smalltalk vm version ---> "'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $ '"
cmd ver ---> Microsoft Windows [Versión 10.0.14393]
Additionally:
And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:
Gofer new url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main' ; package: 'ConfigurationOfRoassal2'; load. #ConfigurationOfRoassal2 asClass load.
Martin
On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
Well, I take that back.
Today I had the same issue (with the latest VM). Closing the image and reopening it helped, but clearly there is something broken underneath.
Peter
On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
I got the same problem with the latest vm some weeks ago on Windows
On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote: 7.
It vanished by downloading a new vm some days after.
I've downloaded the latest VM and it works as expected. Thanks!
Peter
-- _,,,^..^,,,_ best, Eliot
Le 16/03/2017 à 05:11, Martin Dias a écrit :
And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:
Do you have an anti-virus? If yes did you excluded the .changes and ombu files from the files to check? If not the anti-virus might analyze your file at each compilation. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Hi all. I rarely use Windows but this night entered again to repeat the load test in Pharo. Cyril: I uninstalled the antivirus and excluded .changes and .images files in the "Windows Defender" (didn't know it exists). I may note some speed up but not much, so it wasn't THE solution. Peter: I didn't check firewall but "Compiling methods..." is what stays on screen so it shouldn't be the network. Eliot: this time I profiled it and can highlight from report that Leaves shows 91% in StandardFileStream>>primFlush:. I guess it isn't too surprising since file writing is expensive but it's a lot. However I didn't compare it yet with the respective report in linux. For the record, I attach the report. Code evaluated: AndreasSystemProfiler spyOn: [ Gofer new url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; package: 'ConfigurationOfRoassal2'; load. #ConfigurationOfRoassal2 asClass load.] Regards MartÃn On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com
wrote:
Le 16/03/2017 à 05:11, Martin Dias a écrit :
And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:
Do you have an anti-virus? If yes did you excluded the .changes and ombu files from the files to check? If not the anti-virus might analyze your file at each compilation.
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
AFAIR, flushing after each write was a workaround against some linux problem. I think that flush is not exagerately expensive on linux, because there's a difference between flush (transfer data from user space buffers to kernel space buffers) and sync (transfer data to the disc). In Win32 VM, the fileFlush and fileSync primitives do the same call to FlushFileBuffers. The msdn tells it's a bad thing to repeatedly call FlushFileBuffers https://msdn.microsoft.com/en-us/library/windows/desktop/aa364439(v=vs.85).a... I don't see such thing as a "cheap" flush on windows. But do we really need to flush? Couldn't we rather implement a linuxWorkaroundFlush: aFile method that would flush on linux and do nothing anywhere else? 2017-04-01 6:40 GMT+02:00 Martin Dias <tinchodias@gmail.com>:
Hi all. I rarely use Windows but this night entered again to repeat the load test in Pharo.
Cyril: I uninstalled the antivirus and excluded .changes and .images files in the "Windows Defender" (didn't know it exists). I may note some speed up but not much, so it wasn't THE solution.
Peter: I didn't check firewall but "Compiling methods..." is what stays on screen so it shouldn't be the network.
Eliot: this time I profiled it and can highlight from report that Leaves shows 91% in StandardFileStream>>primFlush:. I guess it isn't too surprising since file writing is expensive but it's a lot. However I didn't compare it yet with the respective report in linux. For the record, I attach the report.
Code evaluated: AndreasSystemProfiler spyOn: [ Gofer new url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; package: 'ConfigurationOfRoassal2'; load. #ConfigurationOfRoassal2 asClass load.]
Regards MartÃn
On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
Le 16/03/2017 à 05:11, Martin Dias a écrit :
And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:
Do you have an anti-virus? If yes did you excluded the .changes and ombu files from the files to check? If not the anti-virus might analyze your file at each compilation.
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
In squeak, that would be: Frank Shearar uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-fbs.513.mcz ==================== Summary ==================== Name: Collections-fbs.513 Author: fbs Time: 26 April 2013, 11:13:00.656 am UUID: dba4f808-6844-414c-a5bf-5cda0cf4e342 Ancestors: Collections-bf.512 This fixes the recent report of an Ubuntu 13.04 machine not being able to save a class comment. https://bugzilla.redhat.com/show_bug.cgi?id=956376 I presume that the workaround in Pharo appeared more or less simultaneously since Pavel was active in the bug report. Now we re-discover that such workaround can have side effects... 2017-04-01 10:06 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
AFAIR, flushing after each write was a workaround against some linux problem. I think that flush is not exagerately expensive on linux, because there's a difference between flush (transfer data from user space buffers to kernel space buffers) and sync (transfer data to the disc).
In Win32 VM, the fileFlush and fileSync primitives do the same call to FlushFileBuffers. The msdn tells it's a bad thing to repeatedly call FlushFileBuffers https://msdn.microsoft.com/en-us/library/windows/desktop/ aa364439(v=vs.85).aspx I don't see such thing as a "cheap" flush on windows.
But do we really need to flush? Couldn't we rather implement a linuxWorkaroundFlush: aFile method that would flush on linux and do nothing anywhere else?
2017-04-01 6:40 GMT+02:00 Martin Dias <tinchodias@gmail.com>:
Hi all. I rarely use Windows but this night entered again to repeat the load test in Pharo.
Cyril: I uninstalled the antivirus and excluded .changes and .images files in the "Windows Defender" (didn't know it exists). I may note some speed up but not much, so it wasn't THE solution.
Peter: I didn't check firewall but "Compiling methods..." is what stays on screen so it shouldn't be the network.
Eliot: this time I profiled it and can highlight from report that Leaves shows 91% in StandardFileStream>>primFlush:. I guess it isn't too surprising since file writing is expensive but it's a lot. However I didn't compare it yet with the respective report in linux. For the record, I attach the report.
Code evaluated: AndreasSystemProfiler spyOn: [ Gofer new url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main' ; package: 'ConfigurationOfRoassal2'; load. #ConfigurationOfRoassal2 asClass load.]
Regards MartÃn
On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
Le 16/03/2017 à 05:11, Martin Dias a écrit :
And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:
Do you have an anti-virus? If yes did you excluded the .changes and ombu files from the files to check? If not the anti-virus might analyze your file at each compilation.
-- Cyril Ferlicot
2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
On Sat, Apr 01, 2017 at 10:06:34AM +0200, Nicolas Cellier wrote:
AFAIR, flushing after each write was a workaround against some linux problem.
This was specifically for the case of writing a chunk to e.g. the changes file. The extra flush for that case is protecting for two processes writing to the same stream. This would not affect overall read/write performance though.
I think that flush is not exagerately expensive on linux, because there's a difference between flush (transfer data from user space buffers to kernel space buffers) and sync (transfer data to the disc).
The Windows VM uses a different FilePlugin. The I/O calls are made at the HANDLE level, not at the (FILE *) level as in the Unix plugin. A HANDLE on Windows would be loosely equivalent to a file descriptor number on Unix. If #primitiveFileFlush is intended to mean "flush everything from the VM out to the operating system", and #primitiveFileSync is intended to mean "tell the operating system to flush it all way to disk", then flush would be a no-op on Windows, and you would call the sync primitive only in cases where you really need to guarantee a flush to disk. An interesting project would be to adapt the Unix plugin to run on Windows (maybe it already just works, I never tried), or conversely to write a Unix plugin that reads and writes to the file descriptor level as in done with the Windows plugin. My guess is that both approaches are valid, and they probably will have differing performance advantages based on the I/O workload. But someone would have to try it to find out :-) Dave
In Win32 VM, the fileFlush and fileSync primitives do the same call to FlushFileBuffers. The msdn tells it's a bad thing to repeatedly call FlushFileBuffers https://msdn.microsoft.com/en-us/library/windows/desktop/aa364439(v=vs.85).a... I don't see such thing as a "cheap" flush on windows.
But do we really need to flush? Couldn't we rather implement a linuxWorkaroundFlush: aFile method that would flush on linux and do nothing anywhere else?
2017-04-01 6:40 GMT+02:00 Martin Dias <tinchodias@gmail.com>:
Hi all. I rarely use Windows but this night entered again to repeat the load test in Pharo.
Cyril: I uninstalled the antivirus and excluded .changes and .images files in the "Windows Defender" (didn't know it exists). I may note some speed up but not much, so it wasn't THE solution.
Peter: I didn't check firewall but "Compiling methods..." is what stays on screen so it shouldn't be the network.
Eliot: this time I profiled it and can highlight from report that Leaves shows 91% in StandardFileStream>>primFlush:. I guess it isn't too surprising since file writing is expensive but it's a lot. However I didn't compare it yet with the respective report in linux. For the record, I attach the report.
Code evaluated: AndreasSystemProfiler spyOn: [ Gofer new url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; package: 'ConfigurationOfRoassal2'; load. #ConfigurationOfRoassal2 asClass load.]
Regards Mart??n
On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
Le 16/03/2017 ?? 05:11, Martin Dias a ??crit :
And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:
Do you have an anti-virus? If yes did you excluded the .changes and ombu files from the files to check? If not the anti-virus might analyze your file at each compilation.
-- Cyril Ferlicot
2 rue Jacques Pr??vert 01, 59650 Villeneuve d'ascq France
participants (7)
-
Cyril Ferlicot D. -
David T. Lewis -
Eliot Miranda -
Martin Dias -
Nicolas Cellier -
Peter Uhnak -
phil＠highoctane.be