[Vm-dev] different behaviour for Carbon VM depending on how it's started

David T. Lewis lewis at mail.msen.com
Fri May 2 02:48:24 UTC 2008

On Thu, May 01, 2008 at 04:17:42PM +0200, Michael Haupt wrote:
> Dear all,
> today, I came across some interesting (and, so far, unsettling)
> behaviour of the Carbon VM (on Mac OS X, of course).

I'm pretty sure we are not going to be able to blame this one on the VM ;-)

> The scenario is this: inside the image, OSProcess is used to start a
> Python script that goes to daemon state after some time. The command
> line passed to OSProcess>>#waitForCommand: is 'python
> /path/to/script.py -some -args'.
> Here's the interesting bit.
> The OSProcess has an exit value of 256 (and does not work) when I
> start the image the "normal" way, i.e., by double-clicking it, or by
> drag-and-dropping it to a VM, or by issuing "open -a
> /path/to/SqueakVM.app my.image". The VM process, as shown by "ps x",
> looks like this: "/path/to/Squeak VM Opt.app/Contents/MacOS/Squeak VM
> Opt -psn_0_4199425".

The #waitForCommand: method uses /bin/sh to run your Python interpreter,
so the exit status is that of the /bin/sh process. That means that
the /bin/sh had some problem finding or running python, but it does
not tell you much about what the problem was.

> Conversely, when I start the same image by first starting the VM,
> either by double-clicking it or by starting it directly from the
> terminal command line ("open /path/to/SqueakVM.app" or
> "/path/to/SqueakVM.app/Contents/MacOS/Squeak\ VM\ Opt"), and then
> selecting the image from the file selection dialogue, everything is
> fine. The VM process, then, looks like this: "/path/to/Squeak VM
> Opt.app/Contents/MacOS/Squeak VM Opt" (i.e., without the "-psn...").
> What is the difference, and why? I'm puzzled. Someone, please enlighten me. :-)

To look at the command line arguments and $PATH for your VM, use these:
  OSProcess thisOSProcess arguments.
  OSProcess thisOSProcess path.

Do you have CommandShell loaded in addition to OSProcess? If so, this
will probably lead you directly to the source of the problem:

  (CommandShell pipeline: 'python /path/to/script.py -some -args') errorUpToEnd inspect

Or the same basic thing broken down in steps:

  | p |
  p := CommandShell pipeableProxyFor: 'python /path/to/script.py -some -args'.
  p value.
  [p isComplete] whileFalse: [(Delay forMilliseconds: 20) wait].
  p errorUpToEnd inspect.


More information about the Vm-dev mailing list