RE: [Pharo-project] [Vm-dev] Debugging Cog crash

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: [Pharo-project] [Vm-dev] Debugging Cog crash

Schwab,Wilhelm K

Levente,

It is indeed not the UUID plugin - Dave already suggested deleting it, and I tried that w/o success.

As for running gdb, I will gladly do so, but I have zero experience with it.  The most relevant posts I can find mention attaching to a vm that is already running, and I can't get that far.  Below is my attempt to modify the one-click shell script to run the vm under gdb.  Perhaps you or someone else can show me the errors of my ways and produce something that would yield a callstack.

Bill



#!/bin/sh

# path
ROOT=`dirname $0`
LINUX="$ROOT/Contents/Linux"
RESOURCES="$ROOT/Contents/Resources"

# icon
gvfs-set-attribute \
        "$0" \
        "metadata::custom-icon" \
        "file://$RESOURCES/Squeak.png" \
                2> /dev/null

# execute
gdb "$LINUX/squeakvm"

gdb run -plugins "$LINUX" \
        -encoding latin1 \
        -vm-display-X11 \
        "$RESOURCES/Pharo.image"


Levente wrote:

Well, the file OneClick.txt says the vm is "Linux Intel x86 4.0.3.2202".
But that's not true, because that's not a CogVM.

The UUIDPlugin seems to have the patch which avoids the crash, so it's
pretty unlikely that it's an issue with the UUIDPlugin. Even if the patch
is wrong (which is unlikely, because we're using Eliot's latest build on
64-bit Ubuntu 8.04 and it doesn't crash, but previous unpatched builds did
crash), it's pretty unlikely that the cause of the crash is the related to
UUIDPlugin at all, because UUIDs are normally not created during startup
and your image is crashing on startup.
To be 100% sure you can try deleting UUIDPlugin and see if your image
is crashing or not.
If it still crashes, then use gdb to see where it crashes. The VM seems to
be unstripped (8MB), so it should be easy to identify the cause of the
crash.


Levente


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
Sent: Friday, April 08, 2011 11:56 AM
To: [hidden email]; Squeak Virtual Machine Development Discussion
Subject: Re: [Pharo-project] [Vm-dev] FW:  Debugging Cog crash

Levente,

The image will not load at all.  It simply dies with "Segmentation fault" - NOTHING else happens.  gdb is maybe a possibility, but it is not an approach I ordinarily take, so some guidance would be helpful.

I have a reproducible crash, but poor access to the affected box.

Bill



On Fri, 8 Apr 2011, Schwab,Wilhelm K wrote:

>
> Gratuitous default recipient...
>
> If there is a verbose dump option or other diagnostic efforts that will help, I will do my best to run them and report the results.  I am fairly certain the vm is 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54]' (can verify later today), but this happened with an earlier Cog one-click too.  There is something about the machine (UUID again?) that is different.  I do not have root access to it, but I can get to a terminal.  Ubuntu 10.10.

Where did you download the VM?
Does it crash when you're trying to evaluate [UUID new]?
Did you try gdb?


Levente





________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
Sent: Friday, April 08, 2011 11:42 AM
To: [hidden email]; Squeak Virtual Machine Development Discussion
Subject: Re: [Pharo-project] [Vm-dev] FW:  Debugging Cog crash

Dave,

It was, I did :)  No help :(  What else can I try?

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of David T. Lewis [[hidden email]]
Sent: Friday, April 08, 2011 10:32 AM
To: Squeak Virtual Machine Development Discussion
Cc: [hidden email]
Subject: Re: [Pharo-project] [Vm-dev] FW:  Debugging Cog crash

Yes, the libuuid.so bug would be a likely suspect. If the UUIDPlugin was
built as an external library, just delete it and you will probably be
good to go.

If you need further info, look here:
http://bugs.squeak.org/view.php?id=7358

Dave

On Fri, Apr 08, 2011 at 07:58:39AM -0400, Schwab,Wilhelm K wrote:

>
> Gratuitous default recipient...
>
> If there is a verbose dump option or other diagnostic efforts that will help, I will do my best to run them and report the results.  I am fairly certain the vm is 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54]' (can verify later today), but this happened with an earlier Cog one-click too.  There is something about the machine (UUID again?) that is different.  I do not have root access to it, but I can get to a terminal.  Ubuntu 10.10.
>
>
> ________________________________________
> From: Schwab,Wilhelm K
> Sent: Friday, April 08, 2011 7:44 AM
> To: Mariano Martinez Peck
> Subject: RE: [Pharo-project] Debugging Cog crash
>
> Mariano,
>
> I first identified this problem/opportunity a while ago.  At the time, there was no log - the vm just died.  I can sniff around again as there might be one this time.  My question at the time was whether there was something that I could enable to perhaps get more info.
>
> The output from the vm is, and I quote<g> "Segmentation fault".  There is no other output.  Perhaps it does not get far enough to have a call stack??
>
> Bill
>
>
>
> ________________________________________
> From: Mariano Martinez Peck [[hidden email]]
> Sent: Friday, April 08, 2011 3:42 AM
> To: Squeak Development Discussion Virtual Machine; Pharo Development
> Cc: Schwab,Wilhelm K
> Subject: Re: [Pharo-project] Debugging Cog crash
>
> also...shouldn't be a crash/dump file somewhere?
>
> can you write the output of the console where you invoke the VM into a file ?   (using > to redirect)
>
> Cheers
>
> Mariano
>
> On Thu, Apr 7, 2011 at 11:10 PM, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> wrote:
> Hello all,
>
> I have an account on an Ubuntu terminal server (at least I think that's what it would be called) running 10.10.  The Cog one-click image crashes with "Segmentation fault" (if run from a terminal); the legacy VM seems to run the image nicely on the box.  Any ideas?  I will happily collect any facts that will be of help, but I need some
> direction.
>
> Bill
>
>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com



Reply | Threaded
Open this post in threaded view
|

RE: [Pharo-project] [Vm-dev] Debugging Cog crash

Levente Uzonyi-2
 
On Fri, 8 Apr 2011, Schwab,Wilhelm K wrote:

>
> Levente,
>
> It is indeed not the UUID plugin - Dave already suggested deleting it, and I tried that w/o success.
>
> As for running gdb, I will gladly do so, but I have zero experience with it.  The most relevant posts I can find mention attaching to a vm that is already running, and I can't get that far.  Below is my attempt to modify the one-click shell script to run the vm under gdb.  Perhaps you or someone else can show me the errors of my ways and produce something that would yield a callstack.
>
> Bill
>
>
>
> #!/bin/sh
>
> # path
> ROOT=`dirname $0`
> LINUX="$ROOT/Contents/Linux"
> RESOURCES="$ROOT/Contents/Resources"
>
> # icon
> gvfs-set-attribute \
>        "$0" \
>        "metadata::custom-icon" \
>        "file://$RESOURCES/Squeak.png" \
>                2> /dev/null
>
> # execute
> gdb "$LINUX/squeakvm"
>
> gdb run -plugins "$LINUX" \
>        -encoding latin1 \
>        -vm-display-X11 \
>        "$RESOURCES/Pharo.image"

This doesn't work, because the "run" command should be evaluated from gdb.
It's better to do it by hand. Enter the oneclick root directory and start
the vm with gdb:

gdb ./Contents/Linux/squeakvm

Then from gdb start the program (use the VM switches from the shell script
if they're mandatory):

run ./Contents/Resources/Pharo.image

>From here it's like a normal execution of the vm, but gdb will stop if you
get a segfault. Then you can use the "bt" command to see what's on the
stack when the bug happened and "info registers" to see what's in the
registers. Pasting the output of those commands is usually enough to
identify the cause of the problem.


Levente

P.S.: here's an example how others did it:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-July/005099.html

>
>
> Levente wrote:
>
> Well, the file OneClick.txt says the vm is "Linux Intel x86 4.0.3.2202".
> But that's not true, because that's not a CogVM.
>
> The UUIDPlugin seems to have the patch which avoids the crash, so it's
> pretty unlikely that it's an issue with the UUIDPlugin. Even if the patch
> is wrong (which is unlikely, because we're using Eliot's latest build on
> 64-bit Ubuntu 8.04 and it doesn't crash, but previous unpatched builds did
> crash), it's pretty unlikely that the cause of the crash is the related to
> UUIDPlugin at all, because UUIDs are normally not created during startup
> and your image is crashing on startup.
> To be 100% sure you can try deleting UUIDPlugin and see if your image
> is crashing or not.
> If it still crashes, then use gdb to see where it crashes. The VM seems to
> be unstripped (8MB), so it should be easy to identify the cause of the
> crash.
>
>
> Levente
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
> Sent: Friday, April 08, 2011 11:56 AM
> To: [hidden email]; Squeak Virtual Machine Development Discussion
> Subject: Re: [Pharo-project] [Vm-dev] FW:  Debugging Cog crash
>
> Levente,
>
> The image will not load at all.  It simply dies with "Segmentation fault" - NOTHING else happens.  gdb is maybe a possibility, but it is not an approach I ordinarily take, so some guidance would be helpful.
>
> I have a reproducible crash, but poor access to the affected box.
>
> Bill
>
>
>
> On Fri, 8 Apr 2011, Schwab,Wilhelm K wrote:
>
>>
>> Gratuitous default recipient...
>>
>> If there is a verbose dump option or other diagnostic efforts that will help, I will do my best to run them and report the results.  I am fairly certain the vm is 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54]' (can verify later today), but this happened with an earlier Cog one-click too.  There is something about the machine (UUID again?) that is different.  I do not have root access to it, but I can get to a terminal.  Ubuntu 10.10.
>
> Where did you download the VM?
> Does it crash when you're trying to evaluate [UUID new]?
> Did you try gdb?
>
>
> Levente
>
>
>
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
> Sent: Friday, April 08, 2011 11:42 AM
> To: [hidden email]; Squeak Virtual Machine Development Discussion
> Subject: Re: [Pharo-project] [Vm-dev] FW:  Debugging Cog crash
>
> Dave,
>
> It was, I did :)  No help :(  What else can I try?
>
> Bill
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of David T. Lewis [[hidden email]]
> Sent: Friday, April 08, 2011 10:32 AM
> To: Squeak Virtual Machine Development Discussion
> Cc: [hidden email]
> Subject: Re: [Pharo-project] [Vm-dev] FW:  Debugging Cog crash
>
> Yes, the libuuid.so bug would be a likely suspect. If the UUIDPlugin was
> built as an external library, just delete it and you will probably be
> good to go.
>
> If you need further info, look here:
> http://bugs.squeak.org/view.php?id=7358
>
> Dave
>
> On Fri, Apr 08, 2011 at 07:58:39AM -0400, Schwab,Wilhelm K wrote:
>>
>> Gratuitous default recipient...
>>
>> If there is a verbose dump option or other diagnostic efforts that will help, I will do my best to run them and report the results.  I am fairly certain the vm is 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54]' (can verify later today), but this happened with an earlier Cog one-click too.  There is something about the machine (UUID again?) that is different.  I do not have root access to it, but I can get to a terminal.  Ubuntu 10.10.
>>
>>
>> ________________________________________
>> From: Schwab,Wilhelm K
>> Sent: Friday, April 08, 2011 7:44 AM
>> To: Mariano Martinez Peck
>> Subject: RE: [Pharo-project] Debugging Cog crash
>>
>> Mariano,
>>
>> I first identified this problem/opportunity a while ago.  At the time, there was no log - the vm just died.  I can sniff around again as there might be one this time.  My question at the time was whether there was something that I could enable to perhaps get more info.
>>
>> The output from the vm is, and I quote<g> "Segmentation fault".  There is no other output.  Perhaps it does not get far enough to have a call stack??
>>
>> Bill
>>
>>
>>
>> ________________________________________
>> From: Mariano Martinez Peck [[hidden email]]
>> Sent: Friday, April 08, 2011 3:42 AM
>> To: Squeak Development Discussion Virtual Machine; Pharo Development
>> Cc: Schwab,Wilhelm K
>> Subject: Re: [Pharo-project] Debugging Cog crash
>>
>> also...shouldn't be a crash/dump file somewhere?
>>
>> can you write the output of the console where you invoke the VM into a file ?   (using > to redirect)
>>
>> Cheers
>>
>> Mariano
>>
>> On Thu, Apr 7, 2011 at 11:10 PM, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> wrote:
>> Hello all,
>>
>> I have an account on an Ubuntu terminal server (at least I think that's what it would be called) running 10.10.  The Cog one-click image crashes with "Segmentation fault" (if run from a terminal); the legacy VM seems to run the image nicely on the box.  Any ideas?  I will happily collect any facts that will be of help, but I need some
>> direction.
>>
>> Bill
>>
>>
>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: [Pharo-project] [Vm-dev] Debugging Cog crash

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K

Is there a debug version of Cog that I can run on the box?  I have casually avoided learning how to build Cog in part because that means I can't hack the FFI plugin, which forces me to play by the rules on library paths/ldconfig, etc.  It also means that I don't have a build environment ready to go, so I can't readily add syslog() calls to bracket where it quits.  gdb isn't helping as described below.

If there is something you want me to try, let me know.  We have a reproducible Cog crash.


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
Sent: Friday, April 08, 2011 6:03 PM
To: [hidden email]; Squeak Virtual Machine Development Discussion
Subject: Re: [Pharo-project] [Vm-dev] FW:  Debugging Cog crash

Levente,

I follow on why my shell script did not work.  Your instructions got me going, but we still don't have an answer.  The vm is running, but I cannot attach:

    http://lists.squeakfoundation.org/pipermail/vm-dev/2008-March/001840.html

>From what I read, one answer is the get the image loaded and then attach - my problem is that the vm never gets far enough to actually load the image.

Any ideas?

Bill


Reply | Threaded
Open this post in threaded view
|

RE: [Pharo-project] [Vm-dev] Debugging Cog crash

Schwab,Wilhelm K

Levente,

Yes, I did follow your instructions, and got the same error message reported in the post I cited.  The solution only solution I have found to that problem is the get the image up and running and THEN attach gdb to it.  I can't do that, because the vm dies way too early for that to work.  So, I would need to attach, or find another solution to the problem.

Bill




Levente wrote:

Did you follow my instructions? If so, then you don't have to attach at
all, because you started the VM process from gdb, so gdb is attached to
the process already. Just do exactly what I wrote and you'll have what you
need.

If you need more help, then try the following links (first hits for
http://www.google.com/search?ie=UTF-8&q=how+to+use+gdb btw):
- http://www.unknownroad.com/rtfm/gdbtut/gdbuse.html
- http://www.cs.cmu.edu/~gilpin/tutorial/


Levente


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
Sent: Saturday, April 09, 2011 8:19 AM
To: [hidden email]; Squeak Virtual Machine Development Discussion
Subject: Re: [Pharo-project] [Vm-dev] Debugging Cog crash

Is there a debug version of Cog that I can run on the box?  I have casually avoided learning how to build Cog in part because that means I can't hack the FFI plugin, which forces me to play by the rules on library paths/ldconfig, etc.  It also means that I don't have a build environment ready to go, so I can't readily add syslog() calls to bracket where it quits.  gdb isn't helping as described below.

If there is something you want me to try, let me know.  We have a reproducible Cog crash.


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
Sent: Friday, April 08, 2011 6:03 PM
To: [hidden email]; Squeak Virtual Machine Development Discussion
Subject: Re: [Pharo-project] [Vm-dev] FW:  Debugging Cog crash

Levente,

I follow on why my shell script did not work.  Your instructions got me going, but we still don't have an answer.  The vm is running, but I cannot attach:

    http://lists.squeakfoundation.org/pipermail/vm-dev/2008-March/001840.html

>From what I read, one answer is the get the image loaded and then attach - my problem is that the vm never gets far enough to actually load the image.

Any ideas?

Bill



Reply | Threaded
Open this post in threaded view
|

RE: [Pharo-project] [Vm-dev] Debugging Cog crash

Levente Uzonyi-2
 
On Sat, 9 Apr 2011, Schwab,Wilhelm K wrote:

>
> Levente,
>
> Yes, I did follow your instructions, and got the same error message reported in the post I cited.  The solution only solution I have found to that problem is the get the image up and running and THEN attach gdb to it.  I can't do that, because the vm dies way too early for that to work.  So, I would need to attach, or find another solution to the problem.

See the best answer here:
http://stackoverflow.com/questions/2702628/gdb-cannot-find-new-threads-generic-error


Levente

>
> Bill
>
>
>
>
> Levente wrote:
>
> Did you follow my instructions? If so, then you don't have to attach at
> all, because you started the VM process from gdb, so gdb is attached to
> the process already. Just do exactly what I wrote and you'll have what you
> need.
>
> If you need more help, then try the following links (first hits for
> http://www.google.com/search?ie=UTF-8&q=how+to+use+gdb btw):
> - http://www.unknownroad.com/rtfm/gdbtut/gdbuse.html
> - http://www.cs.cmu.edu/~gilpin/tutorial/
>
>
> Levente
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
> Sent: Saturday, April 09, 2011 8:19 AM
> To: [hidden email]; Squeak Virtual Machine Development Discussion
> Subject: Re: [Pharo-project] [Vm-dev] Debugging Cog crash
>
> Is there a debug version of Cog that I can run on the box?  I have casually avoided learning how to build Cog in part because that means I can't hack the FFI plugin, which forces me to play by the rules on library paths/ldconfig, etc.  It also means that I don't have a build environment ready to go, so I can't readily add syslog() calls to bracket where it quits.  gdb isn't helping as described below.
>
> If there is something you want me to try, let me know.  We have a reproducible Cog crash.
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
> Sent: Friday, April 08, 2011 6:03 PM
> To: [hidden email]; Squeak Virtual Machine Development Discussion
> Subject: Re: [Pharo-project] [Vm-dev] FW:  Debugging Cog crash
>
> Levente,
>
> I follow on why my shell script did not work.  Your instructions got me going, but we still don't have an answer.  The vm is running, but I cannot attach:
>
>    http://lists.squeakfoundation.org/pipermail/vm-dev/2008-March/001840.html
>
>> From what I read, one answer is the get the image loaded and then attach - my problem is that the vm never gets far enough to actually load the image.
>
> Any ideas?
>
> Bill
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: [Pharo-project] [Vm-dev] Debugging Cog crash

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K

Eliot,

I modified the one-click's shell script as shown below and ran it from a terminal.  It still says only "Segmentation fault."  I could be doing this incorrectly or maybe not looking in the correct place for the output???  My first attempt was to add -sendTrace=9 (note case), and it complained, which is vastly better than ignoring my mistake; it also suggests that I got -sendtrace=9 correct, or it would presumably complain again.

Did I botch it, or is it really quitting before it reaches Smalltalk code?  If you suspect the latter, is there something else we can do to prove it, and/or what's next?  I am not opposed to building from source.  I avoided it for a while because I was afraid that I would "hack" the vm again and not really fix my FFI oddities.  I am close to having the latter sorted, and can probably now trust myself with vm source :)

Bill



#!/bin/sh

# path
ROOT=`dirname $0`
LINUX="$ROOT/Contents/Linux"
RESOURCES="$ROOT/Contents/Resources"

# icon
gvfs-set-attribute \
        "$0" \
        "metadata::custom-icon" \
        "file://$RESOURCES/Squeak.png" \
                2> /dev/null

# execute
exec "$LINUX/squeakvm" \
        -sendtrace=9 \
        -plugins "$LINUX" \
        -encoding latin1 \
        -vm-display-X11 \
        "$RESOURCES/Pharo.image"



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] [Vm-dev] Debugging Cog crash

Eliot Miranda-2
 


On Sun, Apr 10, 2011 at 1:00 PM, Schwab,Wilhelm K <[hidden email]> wrote:

Eliot,

I modified the one-click's shell script as shown below and ran it from a terminal.  It still says only "Segmentation fault."

If you see Segmentation Fault on the console/terminal then you would be able to see the send trace.  So we can conclude it's not getting as far as running Smalltalk.  Since another VM runs your image just fine we could conclude there's nothing wrong with the image, except perhaps for the Cog VM scanning the heap to convert Float endianness etc. In any case you now need to debug the VM's start-up under gdb.  Your problems lie before Smalltalk starts to run.
 
 I could be doing this incorrectly or maybe not looking in the correct place for the output???  My first attempt was to add -sendTrace=9 (note case), and it complained, which is vastly better than ignoring my mistake; it also suggests that I got -sendtrace=9 correct, or it would presumably complain again.

Did I botch it, or is it really quitting before it reaches Smalltalk code?  If you suspect the latter, is there something else we can do to prove it, and/or what's next?  I am not opposed to building from source.  I avoided it for a while because I was afraid that I would "hack" the vm again and not really fix my FFI oddities.  I am close to having the latter sorted, and can probably now trust myself with vm source :)

Bill



#!/bin/sh

# path
ROOT=`dirname $0`
LINUX="$ROOT/Contents/Linux"
RESOURCES="$ROOT/Contents/Resources"

# icon
gvfs-set-attribute \
       "$0" \
       "metadata::custom-icon" \
       "file://$RESOURCES/Squeak.png" \
               2> /dev/null

# execute
exec "$LINUX/squeakvm" \
       -sendtrace=9 \
       -plugins "$LINUX" \
       -encoding latin1 \
       -vm-display-X11 \
       "$RESOURCES/Pharo.image"




Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] [Vm-dev] Debugging Cog crash

Mariano Martinez Peck
In reply to this post by Schwab,Wilhelm K
 
For the next time Bill, this blog post may help you: http://marianopeck.wordpress.com/2011/04/23/how-to-debug-the-vm/

Cheers

Mariano

On Sun, Apr 10, 2011 at 10:00 PM, Schwab,Wilhelm K <[hidden email]> wrote:

Eliot,

I modified the one-click's shell script as shown below and ran it from a terminal.  It still says only "Segmentation fault."  I could be doing this incorrectly or maybe not looking in the correct place for the output???  My first attempt was to add -sendTrace=9 (note case), and it complained, which is vastly better than ignoring my mistake; it also suggests that I got -sendtrace=9 correct, or it would presumably complain again.

Did I botch it, or is it really quitting before it reaches Smalltalk code?  If you suspect the latter, is there something else we can do to prove it, and/or what's next?  I am not opposed to building from source.  I avoided it for a while because I was afraid that I would "hack" the vm again and not really fix my FFI oddities.  I am close to having the latter sorted, and can probably now trust myself with vm source :)

Bill



#!/bin/sh

# path
ROOT=`dirname $0`
LINUX="$ROOT/Contents/Linux"
RESOURCES="$ROOT/Contents/Resources"

# icon
gvfs-set-attribute \
       "$0" \
       "metadata::custom-icon" \
       "file://$RESOURCES/Squeak.png" \
               2> /dev/null

# execute
exec "$LINUX/squeakvm" \
       -sendtrace=9 \
       -plugins "$LINUX" \
       -encoding latin1 \
       -vm-display-X11 \
       "$RESOURCES/Pharo.image"






--
Mariano
http://marianopeck.wordpress.com