[Vm-dev] Cog + Pi + OSProcess

[tim Rowledge]

> On 16-06-2016, at 6:40 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> 
> On Wed, Jun 08, 2016 at 11:42:57AM -0700, tim Rowledge wrote:
>> 
>> I finally got a moment to look at this - not that I really have much clue
>> about the whole unix process thing - and it appears that something is odd
>> with the compiled code in the plugin.
>> 
>> My test is very simple - run the UnixProcess class>listDirectory example.
>> It exits with a segfault and the forkAndExec??? method as the last thing
>> on the stack.
>> 
>> I build a debug vm (and had some fun with asserts and the ARM fp offset in
>> the process, all fixed now) and??? it doesn???t fail. I???ve tried compiling
>> the plugin with varying levels of optimisation, since we???ve fairly regularly
>> seen problems there, and even at -O0 it fails. So debug -> OK, no-debug -> boom.
>> Nice.
>> 
>> Ideas?
>> 
> 
> I just unpacked my new Raspberry Pi (thanks Ben and Tim for the shopping and
> setup advice). Very cool. My only usability complaint is that the TV monitor
> is in the next room, so I am getting a stiff neck trying to look at the monitor
> while I type on my chiclet keyboard here in the kitchen. But it works, and it
> is a real computer.

As previously mentioned I use xrdp to solve this. The only issue it causes me is having to use ‘sudo’ in a lot of places you might not expect; running Squeak is almost understandable (though you don’t need it when running a direct display) but needing it to make a vm is crazy, but the ‘install’ part simply won’t work without it.

> 
> I started by compiling an interpreter VM to run against "trunk level" V3 image
> with OSProcess/CommandShell loaded. What I found so far:
> 
> - The 32-bit VM running 64-bit image does not work, cannot load X11 driver.
> This used to work 6 or 8 years ago on 64 bit x86, so probably some regression
> because I have not been testing on 32-bit host, and Raspbian is 32-bit.

Yup, an will stay that way for a while at least, even on the 64 bit ARM v8.

> 
> - After loading OSProcess/CommandShell, I was getting errors, something like
> fork not being able to allocate memory. Sorry, I did not capture the error,
> and it's gone now.
> 
Is it possible that we are simply grabbing too much address space and the fork fails because of that? I know the images are tiny by today’s standards - I swear my camera sometime produces image file bigger than my .image files - but how much address space are we grabbing? 
I can’t find any notes but I’m pretty sure there was a time when the Scratch ‘help’ couldn’t work because the OS couldn’t find enough memory to fire up the web browser.

> - I then ran the OSP/CommandShell test suite. This crashed my login session
> and took me to a login prompt. WTF?!? This is supposed to be impossible on
> a Unix system. I'm still provisionally impressed with Raspbian, but …

I’ve never been massively impressed with the claims of unix perfection. I’ve been able to lock up and crash both applications on, and actual unices on ppc, x86, ARM, HPPA, 68k etc etc.
> 
> 
> I will try setting up a Cog/Spur build next, and see what that looks like.
> But probably not tonight :-)

If using xrdp, you’ll need to use `sudo ./mvm` etc.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: CPE: Create Parity Error