Smalltalk › Squeak › Squeak VM

new Cog VMs available...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Eliot Miranda-2

new Cog VMs available...

...at http://www.mirandabanda.org/files/Cog/VM/VM.r2496/.

CogVM binaries as per VMMaker.oscog-eem.128/r2496
Fix regression in object-as-method/cannot-interpret for single and polymorphic
inline cache misses (lookup:for:methodAndErrorSelectorInto:).
Fix formatting bugette in context printing.

This fixes a regression in objects-as-methods which Nicholas was suffering from as a crash during Run Coverage in the Test Runner.

--
best,

Eliot

laza

Re: new Cog VMs available...

Eliot,

using this version of the vm I ran into a problem. I have a bunch of
Unit-Tests and after some iterations of running them, the vm just
freezes. So I can't say where it's happening.
Sending USR1 won't give a stack dump, but I tried to get a backtrace using gdb.

Alex

Program received signal SIGSEGV, Segmentation fault.
0x08062f5c in remap (oop=2007759384) at
/home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:39851
39851 in /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c
(gdb) bt
#0 0x08062f5c in remap (oop=2007759384) at
/home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:39851
#1 0x0809057e in remapIfObjectRefpchasYoung (annotation=7,
mcpc=0x760e970f
"\211Ӊ؃\340\001u\022\213\003\301\350\n\203\340|u\017\213K\374\203\341\374\353\r\271\214\002dv\353\006\213\210<\025\025v\211ʉ\354]\302\004",
hasYoungPtr=-1074411928) at /home/eliot/oscogvm/src/vm/cogit.c:15309
#2 0x08085268 in mapForperformUntilarg (cogMethod=<value optimized
out>, functionSymbol=0x80904e0 <remapIfObjectRefpchasYoung>,
arg=-1074411928) at /home/eliot/oscogvm/src/vm/cogit.c:13517
#3 0x08090882 in mapObjectReferencesInMachineCodeForIncrementalGC
(gcMode=2) at /home/eliot/oscogvm/src/vm/cogit.c:13743
#4 mapObjectReferencesInMachineCode (gcMode=2) at
/home/eliot/oscogvm/src/vm/cogit.c:13775
#5 0x080668cf in mapPointersInObjectsFromto (memStart=2005795252,
memEnd=2007924496)
at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:20227
#6 0x0806755a in incCompBody () at
/home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:17099
#7 0x08074a55 in incrementalGC () at
/home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:17458
#8 0x08074d9f in sufficientSpaceAfterGC (minFree=-279448528) at
/home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:43265
#9 0x08077c21 in checkForEventsMayContextSwitch (mayContextSwitch=1)
at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:11223
#10 0x08077e01 in handleStackOverflowOrEventAllowContextSwitch
(mayContextSwitch=24)
at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:16950
#11 0x08078f53 in activateCoggedNewMethod (inInterpreter=0) at
/home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:8547
#12 0x080799c6 in ceSendFromInLineCacheMiss (oPIC=0x76100268) at
/home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:10663
#13 0x76100365 in ?? ()
#14 0x08081bf4 in initStackPagesAndInterpret () at
/home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:18004
#15 0x0805c3ba in main (argc=Cannot access memory at address 0x18
) at /home/eliot/oscogvm/platforms/unix/vm/sqUnixMain.c:1764

2011/9/28 Eliot Miranda <[hidden email]>:

>
> ...at http://www.mirandabanda.org/files/Cog/VM/VM.r2496/.
>
> CogVM binaries as per VMMaker.oscog-eem.128/r2496
> Fix regression in object-as-method/cannot-interpret for single and polymorphic
> inline cache misses (lookup:for:methodAndErrorSelectorInto:).
> Fix formatting bugette in context printing.
>
> This fixes a regression in objects-as-methods which Nicholas was suffering from as a crash during Run Coverage in the Test Runner.
> --
> best,
> Eliot
>
>

SystemInfo.txt (5K) Download Attachment

Yoshiki Ohshima-2

Re: new Cog VMs available...

In reply to this post by Eliot Miranda-2

At Wed, 28 Sep 2011 13:47:22 -0700,
Eliot Miranda wrote:
>
> ...at http://www.mirandabanda.org/files/Cog/VM/VM.r2496/.
>
> CogVM binaries as per VMMaker.oscog-eem.128/r2496
> Fix regression in object-as-method/cannot-interpret for single and polymorphic
> inline cache misses (lookup:for:methodAndErrorSelectorInto:).
> Fix formatting bugette in context printing.
>
> This fixes a regression in objects-as-methods which Nicholas was suffering from as a crash during Run Coverage in the Test Runner.

This probably is not an issue with the latest VM, and I now remember the
discussion related to my question here:

http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html
http://forum.world.st/Problems-with-Mac-VM-5-7-and-5-8-on-the-command-line-td3526363.html

but I'm not sure the current consensus is and let me ask it in the
context of my problem.

So, the switch apparently happened sometime after 'Croquet Closure Cog
VM [CoInterpreter VMMaker.oscog-eem.56] Croquet Cog 3.0.0', which I
have been using for a project. When I try to switch to the latest
version of VM, there are (at least) two things that has changed.

One is that

OSProcess thisOSProcess processAccessor primGetCurrentWorkingDirectory

now returns '/'. I used to launch an external command by:

PipeableOSProcess command: './demo'.

it stopped working. Is this just a known issue, and I should just
use longer interface to OSProcess with cwd explicitly specified?

Another is our custom VM plugin (.bundle) file in the same directory
cannot be found anymore. It works if I copy it into Resources
directory; but it is inconvenient.

What are the suggested solutions for these problems? Thanks!

-- Yoshiki

David T. Lewis

Re: new Cog VMs available...

On Fri, Sep 30, 2011 at 03:27:44PM -0700, Yoshiki Ohshima wrote:

>
> At Wed, 28 Sep 2011 13:47:22 -0700,
> Eliot Miranda wrote:
> >
> > ...at?http://www.mirandabanda.org/files/Cog/VM/VM.r2496/.
> >
> > CogVM binaries as per VMMaker.oscog-eem.128/r2496
> > Fix regression in object-as-method/cannot-interpret for single and polymorphic
> > inline cache misses (lookup:for:methodAndErrorSelectorInto:).
> > Fix formatting bugette in context printing.
> >
> > This fixes a regression in objects-as-methods which Nicholas was suffering from as a crash during Run Coverage in the Test Runner.
>
> This probably is not an issue with the latest VM, and I now remember the
> discussion related to my question here:
>
> http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html
> http://forum.world.st/Problems-with-Mac-VM-5-7-and-5-8-on-the-command-line-td3526363.html
>
> but I'm not sure the current consensus is and let me ask it in the
> context of my problem.
>
> So, the switch apparently happened sometime after 'Croquet Closure Cog
> VM [CoInterpreter VMMaker.oscog-eem.56] Croquet Cog 3.0.0', which I
> have been using for a project. When I try to switch to the latest
> version of VM, there are (at least) two things that has changed.
>
> One is that
>
> OSProcess thisOSProcess processAccessor primGetCurrentWorkingDirectory
>
> now returns '/'. I used to launch an external command by:
>
> PipeableOSProcess command: './demo'.
>
> it stopped working. Is this just a known issue, and I should just
> use longer interface to OSProcess with cwd explicitly specified?

I do not have a mac to test, but in case it may help:

The primGetCurrentWorkingDirectory method calls the C library function
getcwd(), which answers the current working directory of the calling
process (i.e. the process in which the VM is running). If the result
is '/' then I suspect there is something about the way the VM is being
launched that causes it to think it is running from the root directory,
or perhaps a chroot() is being done.

Unix systems also usually have a shell variable $PWD that points to
the current working directory. You can read its value with
'OSProcess thisOSProcess environmentAt: #PWD'. On my system (Linux)
this gives the same result as primGetCurrentWorkingDirectory, but
possibly it will give the result you need on OS X.

By the way, you can also call primGetCurrentWorkingDirectory with
'OSProcess thisOSProcess getCwd'.

Dave

>
> Another is our custom VM plugin (.bundle) file in the same directory
> cannot be found anymore. It works if I copy it into Resources
> directory; but it is inconvenient.
>
> What are the suggested solutions for these problems? Thanks!
>
> -- Yoshiki

laza

Re: new Cog VMs available...

In reply to this post by laza

The same thing seems to happen also on Windows with the same vm
version. Here I could capture a crash.dmp file.

Alex

crash.dmp (11K) Download Attachment

Yoshiki Ohshima-2

Current Working Directory (Re: [squeak-dev] Re: [Vm-dev] new Cog VMs available...)

In reply to this post by David T. Lewis

Hi, Dave,

At Fri, 30 Sep 2011 23:47:16 -0400,
David T. Lewis wrote:

>
> On Fri, Sep 30, 2011 at 03:27:44PM -0700, Yoshiki Ohshima wrote:
> >
> > At Wed, 28 Sep 2011 13:47:22 -0700,
> > Eliot Miranda wrote:
> > >
> > > ...at?http://www.mirandabanda.org/files/Cog/VM/VM.r2496/.
> > >
> > > CogVM binaries as per VMMaker.oscog-eem.128/r2496
> > > Fix regression in object-as-method/cannot-interpret for single and polymorphic
> > > inline cache misses (lookup:for:methodAndErrorSelectorInto:).
> > > Fix formatting bugette in context printing.
> > >
> > > This fixes a regression in objects-as-methods which Nicholas was suffering from as a crash during Run Coverage in the Test Runner.
> >
> > This probably is not an issue with the latest VM, and I now remember the
> > discussion related to my question here:
> >
> > http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html
> > http://forum.world.st/Problems-with-Mac-VM-5-7-and-5-8-on-the-command-line-td3526363.html
> >
> > but I'm not sure the current consensus is and let me ask it in the
> > context of my problem.
> >
> > So, the switch apparently happened sometime after 'Croquet Closure Cog
> > VM [CoInterpreter VMMaker.oscog-eem.56] Croquet Cog 3.0.0', which I
> > have been using for a project. When I try to switch to the latest
> > version of VM, there are (at least) two things that has changed.
> >
> > One is that
> >
> > OSProcess thisOSProcess processAccessor primGetCurrentWorkingDirectory
> >
> > now returns '/'. I used to launch an external command by:
> >
> > PipeableOSProcess command: './demo'.
> >
> > it stopped working. Is this just a known issue, and I should just
> > use longer interface to OSProcess with cwd explicitly specified?
>
> I do not have a mac to test, but in case it may help:
>
> The primGetCurrentWorkingDirectory method calls the C library function
> getcwd(), which answers the current working directory of the calling
> process (i.e. the process in which the VM is running). If the result
> is '/' then I suspect there is something about the way the VM is being
> launched that causes it to think it is running from the root directory,
> or perhaps a chroot() is being done.

Yes, as quoted in
http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html,
running the VM at '/' was a conscious decision. Sorry for not clearly
asking a question. My question was that how people deal with this
change, when the change has apparent drawback in a case such as this.
(Say, you want to distribute your application as a single directory,
the natural place to put an external executable is somewhere under the
directory. But now cwd is '/', you need to supply the current
directory.)

In my code, I already made a change so that instead of using
#command:, I now call
#command:environment:workingDir:input:output:error:errorPipelineStream:.
from a convenience method. Perhaps just having a variation of
#command: that invokes command in the image directory would be handy.

> Unix systems also usually have a shell variable $PWD that points to
> the current working directory. You can read its value with
> 'OSProcess thisOSProcess environmentAt: #PWD'. On my system (Linux)
> this gives the same result as primGetCurrentWorkingDirectory, but
> possibly it will give the result you need on OS X.

$PWD is certainly the same as the VMs cwd (checked with lsof
command). I get nil for environmentAt: #PWD.

> By the way, you can also call primGetCurrentWorkingDirectory with
> 'OSProcess thisOSProcess getCwd'.

Ah, thanks!

-- Yoshiki

Bert Freudenberg

Re: Current Working Directory (Re: [squeak-dev] Re: [Vm-dev] new Cog VMs available...)

On 03.10.2011, at 19:14, Yoshiki Ohshima wrote:

> Hi, Dave,
>
> At Fri, 30 Sep 2011 23:47:16 -0400,
> David T. Lewis wrote:
>>
>> On Fri, Sep 30, 2011 at 03:27:44PM -0700, Yoshiki Ohshima wrote:
>>>
>>> At Wed, 28 Sep 2011 13:47:22 -0700,
>>> Eliot Miranda wrote:
>>>>
>>>> ...at?http://www.mirandabanda.org/files/Cog/VM/VM.r2496/.
>>>>
>>>> CogVM binaries as per VMMaker.oscog-eem.128/r2496
>>>> Fix regression in object-as-method/cannot-interpret for single and polymorphic
>>>> inline cache misses (lookup:for:methodAndErrorSelectorInto:).
>>>> Fix formatting bugette in context printing.
>>>>
>>>> This fixes a regression in objects-as-methods which Nicholas was suffering from as a crash during Run Coverage in the Test Runner.
>>>
>>> This probably is not an issue with the latest VM, and I now remember the
>>> discussion related to my question here:
>>>
>>> http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html
>>> http://forum.world.st/Problems-with-Mac-VM-5-7-and-5-8-on-the-command-line-td3526363.html
>>>
>>> but I'm not sure the current consensus is and let me ask it in the
>>> context of my problem.
>>>
>>> So, the switch apparently happened sometime after 'Croquet Closure Cog
>>> VM [CoInterpreter VMMaker.oscog-eem.56] Croquet Cog 3.0.0', which I
>>> have been using for a project. When I try to switch to the latest
>>> version of VM, there are (at least) two things that has changed.
>>>
>>> One is that
>>>
>>> OSProcess thisOSProcess processAccessor primGetCurrentWorkingDirectory
>>>
>>> now returns '/'. I used to launch an external command by:
>>>
>>> PipeableOSProcess command: './demo'.
>>>
>>> it stopped working. Is this just a known issue, and I should just
>>> use longer interface to OSProcess with cwd explicitly specified?
>>
>> I do not have a mac to test, but in case it may help:
>>
>> The primGetCurrentWorkingDirectory method calls the C library function
>> getcwd(), which answers the current working directory of the calling
>> process (i.e. the process in which the VM is running). If the result
>> is '/' then I suspect there is something about the way the VM is being
>> launched that causes it to think it is running from the root directory,
>> or perhaps a chroot() is being done.
>
> Yes, as quoted in
> http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html,
> running the VM at '/' was a conscious decision. Sorry for not clearly
> asking a question. My question was that how people deal with this
> change, when the change has apparent drawback in a case such as this.
> (Say, you want to distribute your application as a single directory,
> the natural place to put an external executable is somewhere under the
> directory. But now cwd is '/', you need to supply the current
> directory.)
>
> In my code, I already made a change so that instead of using
> #command:, I now call
> #command:environment:workingDir:input:output:error:errorPipelineStream:.
> from a convenience method. Perhaps just having a variation of
> #command: that invokes command in the image directory would be handy.

I don't see the problem. Just give it an absolute path to the executable. You already know that the binary is in your image folder. cwd is pretty much irrelevant for that, no?

- Bert -

Yoshiki Ohshima-2

Re: Current Working Directory (Re: [squeak-dev] Re: [Vm-dev] new Cog VMs available...)

At Mon, 3 Oct 2011 19:18:59 +0200,
Bert Freudenberg wrote:

>
>
> On 03.10.2011, at 19:14, Yoshiki Ohshima wrote:
>
> > Hi, Dave,
> >
> > At Fri, 30 Sep 2011 23:47:16 -0400,
> > David T. Lewis wrote:
> >>
> >> On Fri, Sep 30, 2011 at 03:27:44PM -0700, Yoshiki Ohshima wrote:
> >>>
> >>> At Wed, 28 Sep 2011 13:47:22 -0700,
> >>> Eliot Miranda wrote:
> >>>>
> >>>> ...at?http://www.mirandabanda.org/files/Cog/VM/VM.r2496/.
> >>>>
> >>>> CogVM binaries as per VMMaker.oscog-eem.128/r2496
> >>>> Fix regression in object-as-method/cannot-interpret for single and polymorphic
> >>>> inline cache misses (lookup:for:methodAndErrorSelectorInto:).
> >>>> Fix formatting bugette in context printing.
> >>>>
> >>>> This fixes a regression in objects-as-methods which Nicholas was suffering from as a crash during Run Coverage in the Test Runner.
> >>>
> >>> This probably is not an issue with the latest VM, and I now remember the
> >>> discussion related to my question here:
> >>>
> >>> http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html
> >>> http://forum.world.st/Problems-with-Mac-VM-5-7-and-5-8-on-the-command-line-td3526363.html
> >>>
> >>> but I'm not sure the current consensus is and let me ask it in the
> >>> context of my problem.
> >>>
> >>> So, the switch apparently happened sometime after 'Croquet Closure Cog
> >>> VM [CoInterpreter VMMaker.oscog-eem.56] Croquet Cog 3.0.0', which I
> >>> have been using for a project. When I try to switch to the latest
> >>> version of VM, there are (at least) two things that has changed.
> >>>
> >>> One is that
> >>>
> >>> OSProcess thisOSProcess processAccessor primGetCurrentWorkingDirectory
> >>>
> >>> now returns '/'. I used to launch an external command by:
> >>>
> >>> PipeableOSProcess command: './demo'.
> >>>
> >>> it stopped working. Is this just a known issue, and I should just
> >>> use longer interface to OSProcess with cwd explicitly specified?
> >>
> >> I do not have a mac to test, but in case it may help:
> >>
> >> The primGetCurrentWorkingDirectory method calls the C library function
> >> getcwd(), which answers the current working directory of the calling
> >> process (i.e. the process in which the VM is running). If the result
> >> is '/' then I suspect there is something about the way the VM is being
> >> launched that causes it to think it is running from the root directory,
> >> or perhaps a chroot() is being done.
> >
> > Yes, as quoted in
> > http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html,
> > running the VM at '/' was a conscious decision. Sorry for not clearly
> > asking a question. My question was that how people deal with this
> > change, when the change has apparent drawback in a case such as this.
> > (Say, you want to distribute your application as a single directory,
> > the natural place to put an external executable is somewhere under the
> > directory. But now cwd is '/', you need to supply the current
> > directory.)
> >
> > In my code, I already made a change so that instead of using
> > #command:, I now call
> > #command:environment:workingDir:input:output:error:errorPipelineStream:.
> > from a convenience method. Perhaps just having a variation of
> > #command: that invokes command in the image directory would be handy.
>
> I don't see the problem. Just give it an absolute path to the executable. You already know that the binary is in your image folder. cwd is pretty much irrelevant for that, no?

Well, as I wrote, that is what I did. The API to OSProcess was not
designed this in mind, and the plugin loading became an issue also.

It is not a big deal, but I wondered how other people dealt with the
"problem".

-- Yoshiki