different behaviour for Carbon VM depending on how it's started

 
Dear all,

today, I came across some interesting (and, so far, unsettling)
behaviour of the Carbon VM (on Mac OS X, of course).

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".

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. :-)

Best,

Michael

 
If the launch came from the Finder, the Carbon process serial number  
is placed in argv (to see what I mean do a ps -ax and notice the -
psn_* arguments).
Let me dig some more after I drop the teenager off at school.
On May 1, 2008, at 7:17 AM, Michael Haupt wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

 
Hi John,

On Thu, May 1, 2008 at 4:30 PM, John M McIntosh
<[hidden email]> wrote:
>  If the launch came from the Finder, the Carbon process serial number is
> placed in argv (to see what I mean do a ps -ax and notice the -psn_*
> arguments).
>  Let me dig some more after I drop the teenager off at school.

thanks. :-)

One thing that occurred to a colleague and myself is that it might
have something to do with difficulties in resolving the path to the
python executable. Would the PATH environment variable be different,
depending on whether the VM is started from the command line, or from
the Finder?

Best,

Michael

 

On May 1, 2008, at 17:07 , Michael Haupt wrote:

That would have been my first guess.
Check "OSProcess thisOSProcess environment"

Adrian

 
Hi Adrian,

On Thu, May 1, 2008 at 5:46 PM, Adrian Lienhard <[hidden email]> wrote:
>  That would have been my first guess.
>  Check "OSProcess thisOSProcess environment"

in both cases, $PATH contains /usr/bin, which contains a link to the
Python VM binary. In the "start from command line" version, $PATH also
contains /Library/Frameworks/Python.framework/Versions/Current/bin,
but the python file in there is also just a link, like the python in
/usr/bin.

Why is it a problem to execute one link, and none to execute another?
Both are lrwxr-xr-x.

Best,

Michael

 
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 #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.

Dave

 
Hi David,

On Fri, May 2, 2008 at 4:48 AM, David T. Lewis <[hidden email]> wrote:
>  I'm pretty sure we are not going to be able to blame this one on the VM ;-)

I totally agree. It looked like it at first sight.

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

That looks like a good starting point for further debugging... thanks.

Have you noticed my later e-mails in this thread? Do the details
mentioned there make any sense to you?

Best,

Michael

 
On Fri, May 02, 2008 at 09:15:45AM +0200, Michael Haupt wrote:
Well, I'd only be guessing (and I don't have a Mac to try it on), so
I can't really say. But there is a pretty good chance that /bin/sh
is printing an error message on its stderr, and you just can't see
it (I don't know where stderr ends up when you run Squeak on a Mac,
but I assume it's going someplace that you don't see). If you run
it with CommandShell, the stderr will be piped back into Squeak
where you can look at it.

Some other tips for debugging:

- When you run the python command line with CommandShell, you actually
will *not* be using /bin/shell to run Python. Instead, the work
of /bin/sh is done in Smalltalk, thus it's possible that the
behavior might be a little different.

- It also is convenient to just open up an interactive ComandShell
window (world menu -> open... -> Squeak shell) and enter your
"python /path/to/script.py -some -args" command directly into the
shell window. Any error messages would be shown in the window.

- One more variant of the expressions for debugging:
  (CommandShell pipeableProxyFor: 'python /path/to/script.py -some -args') value errorUpToEndOfFile.

Dave

 
Hi David, all,

thanks to everyone for the support.

The trouble was that the Python interpreter failed to find a library
from which it was supposed to import some symbols when the Squeak VM
was started from the Finder. While the Python VM binary could be
resolved without problems via /usr/bin (Finder PATH) or
/Library/Frameworks/Python.framework/Versions/Current/bin (Terminal
PATH), resolving the library depended on the latter.

Putting the appropriate PATH value in ~./MacOSX/environment.plist and
logging out and back in again solved the problem. :-)

Best,

Michael

 
On Mon, May 05, 2008 at 10:32:24AM +0200, Michael Haupt wrote:
> The trouble was that the Python interpreter failed to find a library
> from which it was supposed to import some symbols when the Squeak VM
> was started from the Finder. While the Python VM binary could be
> resolved without problems via /usr/bin (Finder PATH) or
> /Library/Frameworks/Python.framework/Versions/Current/bin (Terminal
> PATH), resolving the library depended on the latter.
>
> Putting the appropriate PATH value in ~./MacOSX/environment.plist and
> logging out and back in again solved the problem. :-)

Great! Thanks for the follow up.

Dave