You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OSSVMProcess>>initialize bails altogether on Windows, meaning that if OSSubprocess is installed on Windows, and the image is saved and later started on Linux, the VMProcess is not initialized. Less importantly, if an image is built and saved on Linux, then started on Windows, the old VMProcess sticks around, retaining values from the previous session.
Seems like a simple enough fix to:
Always registerToolClassNamed: regardless of the platform we're installing on.
In startUp:, nil the old VMProcess after finalizePreviousSession, then initialize a new one only on not-Windows. This is a change from the current Linux behavior of reusing the old instance, but it seems like most or all instance variables are overwritten in initialize, and any that aren't seem more likely to be the cause of a bug than anything.
PR incoming shortly.
The text was updated successfully, but these errors were encountered:
OSSVMProcess>>initialize
bails altogether on Windows, meaning that ifOSSubprocess
is installed on Windows, and the image is saved and later started on Linux, theVMProcess
is not initialized. Less importantly, if an image is built and saved on Linux, then started on Windows, the oldVMProcess
sticks around, retaining values from the previous session.Seems like a simple enough fix to:
registerToolClassNamed:
regardless of the platform we're installing on.startUp:
, nil the oldVMProcess
afterfinalizePreviousSession
, then initialize a new one only on not-Windows. This is a change from the current Linux behavior of reusing the old instance, but it seems like most or all instance variables are overwritten ininitialize
, and any that aren't seem more likely to be the cause of a bug than anything.PR incoming shortly.
The text was updated successfully, but these errors were encountered: