#basicFileID was sent to nil

[santana]

Describe the bug When running Pharo Launcher as a non-admin user an error message pops up. Pharo Launcher is still usable after clicking on "Ignore".

To Reproduce Steps to reproduce the behavior:

1. Install Pharo Launcher as an admin user in macOS
2. Switch to another user and execute Pharo Launcher
3. You will then see the error

Expected behavior No error message

Screenshots

Version information:

• OS: macOS
• Version: 12.5.1

Expected development cost Given enough context, the solution shouldn't take more than an hour. I can give it a try.

Additional context The problem is that Pharo Launcher has a hack in place to get a sessionID from the baicFileID of the Pharo Launcher image file, after opening it for writing. That file however is not writable for a non-admin user.

[Bajger]

@santana Can you paste more of the stack content? I see just these 3 lines, but I'd like to see what is the chain of message sending during startup. I've looked by whom is that sessionID needed and it seems only sender of session ID is deprecated file stream, co maybe code can be removed, but we'd need to check it by someone from core devs.

[santana]

Thanks @Bajger , here it is:

[capsulecorplab]

I'm also encountering the same issue

[demarey]

Hello,

Thank you for the report. The first analysis is right: the error is due to a lack of permissions to read / write the file. OSSubProcess still uses an old API. Maybe you could try to redefine the #initializeSessionIDmethod with:

initializeSessionID
    sessionID := Smalltalk image imagePath asFileReference binaryReadStreamDo: 
        [ :stream | 
        (ZnEndianessReadWriteStream on: stream) nextLittleEndianNumber: self systemAccessor sizeOfInt ].

It will not survive Pharo Launcher restart but it will let us know if the fix is valid or not.

[capsulecorplab]

I get a FileDoesNotExistException when attempting to redefine initializeSessionID

[demarey]

Thanks for trying. What I do not understand is that the file not found refers to an Epicea file (.ombu extension) and that the given path looks like the path used on the CI server to build the Pharo Launcher package. What does give the evaluation of Smalltalk image imagePath in the debugger?

[capsulecorplab]

Inspector evaluation of Smalltalk image imagePath

[demarey]

ok, then would it be possible for you to track down where does come the reference to the Epicea file (.ombu extension) ?

[capsulecorplab]

I'm not an expert with the debugger, but my guess would be something to do with an OmBlockFileStore object

[demarey]

if you go down in the stack displayed by the debugger, you will find who triggers Epicea (OMxxx classes)

[capsulecorplab]

[demarey]

I can't get the information from the screenshot. Would it be possible to scroll the stack to have the selected entry on the top of the displayed stack? It will show callers that are hidden for now

[capsulecorplab]

I can't get the information from the screenshot. Would it be possible to scroll the stack to have the selected entry on the top of the displayed stack? It will show callers that are hidden for now

Not sure I follow. As in go through each call in the stack trace?

[demarey]

ah sorry, I did not see. There is no more stack entry. A new process was spawn and the interesting information is in another stack.

I guess when you edited the method, Epicea tries to log this change. Maybe you could evaluate EpMonitor current disable before saving the initializeSessionID method?

[capsulecorplab]

I seem to be getting a PrimitiveFailed error after evaluating EpMonitor current disable :confused:

[capsulecorplab]

So, I'm noticing the #basicFileID was sent to nil error occurs when pharo-launcher is installed in /opt but not if it's installed in my home directory (where writable files can persist). Are there any files created in the pharo-launcher directory at runtime? Perhaps that's what's causing the issue

[capsulecorplab]

So, I'm noticing the #basicFileID was sent to nil error occurs when pharo-launcher is installed in /opt but not if it's installed in my home directory (where writable files can persist). Are there any files created in the pharo-launcher directory at runtime? Perhaps that's what's causing the issue

Follow-up; although the #basicFileID was sent to nil issue disappears when installed in home directory, I'm getting a #firstSubMorph was sent to nil error with pharo-launcher running on Pharo 11. Pharo 10 seems to have neither issue.