search

pharo-project / pharo

Pharo is a dynamic reflective pure object-oriented language supporting live programming inspired by Smalltalk.
http://pharo.org
Other
1.19k stars 353 forks source link

64 bit Pharo 7 loading packages fails #3418

Closed ghost closed 4 years ago

ghost commented 5 years ago

Windows 10, downloaded 64 bit pharo vm and image. Attempted to load packages using Catalogue Browser. Loading ZTimestamp just closes the Pharo window. Issue is repeatable with these steps. Note - no issue on 32 bit versions of vm and image

welcome[bot] commented 5 years ago

Thanks for opening your first issue! Please check the CONTRIBUTING documents for some tips about which information should be provided. You can find information of how to do a Pull Request here: https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo

GitHub
pharo-project/pharo
The Sources for Pharo. Contribute to pharo-project/pharo development by creating an account on GitHub.
astares commented 5 years ago

Doubt this will be fixed:

image

Did not check Pharo 7 but works without any problem in recent Pharo 8.

astares commented 5 years ago

Maybe you try a newer VM (from Pharo 8) with Pharo 7 image to find out if this is a VM or image problem.

svenvc commented 5 years ago

@astares note that ZTimestamp is only used as an example of a 'simple to load package'. The point of the OP is that he has trouble loading git/tonel packages on his OS. So he needs help from Windows users.

Though I did mention that he should load using the following expression (since things moved)

Metacello new
  baseline: 'ZTimestamp';
  repository: 'github://svenvc/ztimestamp';
  load.

I am not sure the catalog refers to baselines already ...

astares commented 5 years ago

I tried with Pharo 7 (64 bit) downloaded and started from PharoLauncher and ZTimeStamp from catalog works without a crash.

But it is not a fresh Windows 10, Git is installed locally and other.

Image is: Pharo-7.0.3+build.159.sha.87d28366ab24e00f43dbd5d91f1c0b01ec519e6f (64 Bit) VM is:

CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git

Win32 built on Jan 5 2019 20:24:52 GMT Compiler: 4.2.1 Compatible Clang 5.0.1 (tags/RELEASE_501/final) VMMaker versionString VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019

GitHub
OpenSmalltalk/opensmalltalk-vm
Cross-platform virtual machine for Squeak, Pharo, Cuis, and Newspeak. - OpenSmalltalk/opensmalltalk-vm
svenvc commented 5 years ago

That is what I suspected, in principle it just works (like it does for almost everybody).

Annoying.

astares commented 5 years ago

Yes - it is annoying that Windows is a second class citizen in the Pharo world.

But to reproduce/find the error @rogerthedog needs to check and give info about his local setup

[Pharo-dev] IceGenericError: failed to stat file, Pharo LAUNCHER images and long file names on Windows
ghost commented 5 years ago

I just went through the same process on a different pc and this time it all worked perfectly. The differences? I used a newer image (and potentially VM - I don't know how often the VM is updated). The other thing is that on the new PC I don't have GitHub installed. I will go back to original PC and try to repeat

ghost commented 5 years ago

oh - and the path would have been different too. Will look at that on old PC also.

bencoman commented 5 years ago

Thanks for the update.

bencoman commented 5 years ago

From Discord... Ellis Harris: I just downloaded a fresh Pharo 7 image using the Launcher. I tried to download Roassal and Seaside. Each crashed the image within seconds of clicking DoIt (closed with no message). No debug file found with fresh Pharo 64bit image. I am using Windows 10 Pro. Just updated to May 2019 update 1903.
I did some digging, libssh2-1.dll seems to be the offending file.

Antivirus off, Pharo 64 bit crashing. Antivirus off, Pharo 32bit successfully installed Roassal. Antivirus on Pharo 32 bit installing Roassal Antivirus on Pharo 32 bit successful Roassal install. @BenComan, have you installed the May 2019 update 1903?

BenComan: From the command line C:> ver ==> Microsoft Windows [Version 10.0.17134.885] which is 1803 according to according to https://en.wikipedia.org/wiki/Windows_10_version_history I've had a pending Windows Update for a week that I've been ignoring.

Ellis Harris: I suggest you continue to ignore it. I updated on Friday Before that I have used Windows 10 Pro without any issues including with Roassal. This is my first issue

BenComan: For tracking, could you post you C:\> ver output here.

Ellis Harris: @BenComan . C:\ver = Microsoft Windows [Version 10.0.18362.267]

Jan Bliznicenko: 64bit images do not properly work for me on Windows either ... in my case, Iceberg does not work

Windows 10 version history - Wikipedia
bencoman commented 5 years ago

Further from Discord... dusty: Hi All, can someone test something for me? On windows 10 64. Pharo7.0.3 x64. clean new image. and run 

Metacello new
    baseline: 'Roassal3';
    repository: 'github://ObjectProfile/Roassal3/src';
    load.

for me, on two images, one stand alone and one from launcher, it just crashes Pharo no stderr no pharodebug.log just crashed image looks like same problem as @Ellis Harris yeah, anything on windows 10 with 64 bit pharo when you use github

Ellis Harris: @dusty what version and edition of Windows 10 are you using? Did the 32 bit version work ?

dusty: c:\ver ==> Windows 10 x64 v10.0.18362 Build 18362 32bit version worked

Ellis Harris: @dusty How long ago did you update Windows ? I'm trying to determine if to roll back Windows to 1809 update to see if the 1903 update is the problem.

dusty: very recently. so it might be a cause

astares commented 5 years ago

I'm on Microsoft Windows [Version 10.0.17134.950] without issues

bencoman commented 5 years ago

Just this morning I had this WindowsUpdate forced on me. ISo now my C:\ver ==> Microsoft Windows [Version 10.0.18362.295] and this seems to have broken 64bits FFI git_remote_fetch() callout. Specifically I was trying...

m := Metacello new
  baseline: 'ChipDesigner';
  repository: 'github://pavel-krivanek/PharoChipDesigner/src';
  load

Putting a halt here...

LGitRemote >> remote_fetch: remote refspecs: refspecs opts: opts reflog_message: reflog_message
  self halt.
  ^ self
    call:
      #(LGitReturnCodeEnum git_remote_fetch #(self , LGitStringArray * refspecs , LGitFetchOptions * opts , String reflog_message))
    options: #(optCoerceNilToNull)

stops it crashing until I click Proceed.

Instead clicking Over doesn't crash but produces an error for requestor that... BlockClosure class(Object) DNU #asExternalTypeOn: in...

FFICallout >> directArgName: typeName ptrArity: ptrArity
  "Answer 'direct' type arguments (without argument names): 
    self, nil,true, false or a constant (like a number)"

  (typeName = 'NULL' or: [ typeName = 'nil' ])
    ifTrue: [ 
      ^ (self resolveType: #'void *')
        loader: (self valueArgumentLoader: ExternalAddress null);
        yourself ].
  typeName = 'false'
    ifTrue: [ ^ FFIConst value: 0 type: (self resolveType: #bool) ].
  typeName = 'true'
    ifTrue: [ ^ FFIConst value: 1 type: (self resolveType: #bool) ].
  ptrArity > 0
    ifTrue: [ self error: 'missing argument name' ].  "lone self"
  typeName = 'self'
    ifTrue: [ 
      ^ (requestor asExternalTypeOn: self) "<<<ERROR HERE"
        prepareAsSelfFromCalloutDeclaration;
        loader: self receiverArgumentLoader ].
  ^ self resolveType: typeName

Additionally, selecting the self call: ... options: ... and then DoIt produces a different error... FFIVariableNameNotFound: Could not find accessor for variable named "'refspecs'" in...

FFICallout >> loaderForArgNamed: argName
  | loader |
  "try getting the argument from the method arguments"
  loader := self loaderFromMethodArgsNamed: argName.
  loader ifNil: [ 
    "special case, receiver argument"
    argName = 'self' ifTrue: [ loader := self receiverArgumentLoader ].
    loader ifNil: [ 
      "Ask the requestor for the argument"
      loader := requestor ffiInstVarArgument: argName generator: self.
      loader 
        ifNil: [ FFIVariableNameNotFound signalFor: argName ] ] ]. "<<<ERROR HERE"
  ^ loader

After this I get a bit lost digging around the FFI code.

peteruhnak commented 5 years ago

Every program crash on Windows generates a Log Event (Event Viewer / eventvwr.msc) in Windows Logs > Application.

Which will tell you that it crashed inside libssh2-1.dll, so trying to debug it from within Pharo will probably not yield much result.

I've created a issue in opensmalltalk-vm https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/416

Ducasse commented 5 years ago

Can you add an issue in our fork too? Because Pharo is built from this one: https://github.com/pharo-project/opensmalltalk-vm

GitHub
pharo-project/opensmalltalk-vm
Cross-platform virtual machine for Squeak, Pharo, Cuis, and Newspeak. - pharo-project/opensmalltalk-vm
peteruhnak commented 5 years ago

done https://github.com/pharo-project/opensmalltalk-vm/issues/8

bencoman commented 5 years ago

Has Pharo VM enabled the FFI error masking? Maybe it masks seeing this access-violation error... https://github.com/libssh2/libssh2/issues/378

Also btw, it might not absolutely be Windows Version 1903. My old version was 1803 - which is the version Microsoft is force upgrading, so I skipped Windows Version 1809.

JanBliznicenko commented 5 years ago

I confirm the issue. I have one PC with Windows 1809 and second with Windows 1903. 32bit Pharo 7.0.4 works on both without any specific problem (except of those once-in-a-while random failed library calls that can be "fixed" by restarting PC once or twice). 64bit works on Windows 1809 (except of IceAuthenticationError when trying to fetch or push any repository), but crashes on 1903 (without any "crash" dialog window). Well, quite too many "except of" in one short post, right?

Ducasse commented 5 years ago

Thanks, Pablo will certainly have a look. Please also tells him at ESUG. We are really concerned with the stability of the window version. Now we faced bugs due to our virtualizer so we got some windows machines.

bencoman commented 4 years ago

I believe this can be closed.... [ANN] New Windows VM - Fixes 1903 error http://forum.world.st/ANN-New-Windows-VM-Fixes-1903-error-td5104127.html

Pharo Smalltalk Users - [ANN] New Windows VM - Fixes 1903 error
[ANN] New Windows VM - Fixes 1903 error. Hello, a new stable VM has been deployed. This VM uses a new version of libSSH allowing us to work in the latest Windows version. It can be directly...