On the Cog VM shipped with latest Raspbian (3553, plugins 3543) running on a Pi3, after loading OSProcess, evaluating (PipeableOSProcess command: '/bin/echo this is a test') output segfaults the VM, crash.dmp indicating UnixOSProcessAccessor >> #forkAndExec: <snip>
The shipped interpreter vm (4.10.2 platform rev2614) works with OSProcess, so I can use that instead, but has anyone encountered this already and happen to have a plugin built for Cog/Pi that allows command: use?.
Cheers, Henry
PS. Doing the layman's hack (copying over and renaming so.AioPlugin/so.UnixOSProcessPlugin from interpreter vm) does not work very well, no more crashes, but the PipeableOSProcess created has pid nil, status notYetRunning and an empty string output, so I assume a Cog-specific variant is needed.
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?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim When all else fails, let a = 7. If that doesn't help, then read the manual.
Oh-oh, I might have to break down and buy a Raspberry Pi :-)
Have you (or anyone else) run the OSProcess/CommandShell test suite on a Pi before, or is this the first time someone is looking at it? If it is the first time, then I /strongly/ recommend trying it first on a V3 image with interpreter VM build as per http://wiki.squeak.org/squeak/6354. I'm afraid you will be flying blind if you don't try that first.
Dave
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?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim When all else fails, let a = 7. If that doesn't help, then read the manual.
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.
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.
- 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.
- 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 logged back in and ran the OSP/CommandShell tests again. Everything looks good now, except that tests related to file locking protocol are failing. These are rarely used functions and may be linux distro dependent, so I'm not worried about these failures.
- RemoteTask seems to be working also. Nice.
- Overall, most of the OSProcess functionality seems to be just working, so that is a pleasant surprise.
- I have gotten a few image lockups. I don't think it is related to OSProcess, more likely that I am trying to use a "trunk level" V3 image, maybe a bit buggy at this point.
I will try setting up a Cog/Spur build next, and see what that looks like. But probably not tonight :-)
Dave
Dave,
there are builds for Raspbian on our new bintray page. If all you want is the latest version, you should be able to just use these, no need to compile yourself: https://bintray.com/opensmalltalk/vm/cog/201606161953/view#files
cheers, Tim
On 17 June 2016 at 03:40, David T. Lewis lewis@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.
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.
- 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.
- 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 logged back in and ran the OSP/CommandShell tests again. Everything looks
good now, except that tests related to file locking protocol are failing. These are rarely used functions and may be linux distro dependent, so I'm not worried about these failures.
RemoteTask seems to be working also. Nice.
Overall, most of the OSProcess functionality seems to be just working, so
that is a pleasant surprise.
- I have gotten a few image lockups. I don't think it is related to OSProcess,
more likely that I am trying to use a "trunk level" V3 image, maybe a bit buggy at this point.
I will try setting up a Cog/Spur build next, and see what that looks like. But probably not tonight :-)
Dave
Thanks Tim,
I'll try the bintray.com builds, that helps. But I do also want to compile my own Cog/Spur VMs. That's the main reason I got the Pi, it is inexpensive enough that it was silly not to just get one and try it :-)
Dave
On Fri, Jun 17, 2016 at 09:12:56AM +0200, Tim Felgentreff wrote:
Dave,
there are builds for Raspbian on our new bintray page. If all you want is the latest version, you should be able to just use these, no need to compile yourself: https://bintray.com/opensmalltalk/vm/cog/201606161953/view#files
cheers, Tim
On 17 June 2016 at 03:40, David T. Lewis lewis@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.
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.
- 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.
- 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 logged back in and ran the OSP/CommandShell tests again. Everything looks
good now, except that tests related to file locking protocol are failing. These are rarely used functions and may be linux distro dependent, so I'm not worried about these failures.
RemoteTask seems to be working also. Nice.
Overall, most of the OSProcess functionality seems to be just working, so
that is a pleasant surprise.
- I have gotten a few image lockups. I don't think it is related to OSProcess,
more likely that I am trying to use a "trunk level" V3 image, maybe a bit buggy at this point.
I will try setting up a Cog/Spur build next, and see what that looks like. But probably not tonight :-)
Dave
On Fri, Jun 17, 2016 at 09:12:56AM +0200, Tim Felgentreff wrote:
Dave,
there are builds for Raspbian on our new bintray page. If all you want is the latest version, you should be able to just use these, no need to compile yourself: https://bintray.com/opensmalltalk/vm/cog/201606161953/view#files
Hi Tim,
The latest VM at bintray works fine, thanks.
I also tried running the Squeak 5.0 all-in-one. It crashes. Yikes.
The attached nohup.out shows the error. Has this been reported before?
Dave
On 17 June 2016 at 03:40, David T. Lewis lewis@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.
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.
- 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.
- 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 logged back in and ran the OSP/CommandShell tests again. Everything looks
good now, except that tests related to file locking protocol are failing. These are rarely used functions and may be linux distro dependent, so I'm not worried about these failures.
RemoteTask seems to be working also. Nice.
Overall, most of the OSProcess functionality seems to be just working, so
that is a pleasant surprise.
- I have gotten a few image lockups. I don't think it is related to OSProcess,
more likely that I am trying to use a "trunk level" V3 image, maybe a bit buggy at this point.
I will try setting up a Cog/Spur build next, and see what that looks like. But probably not tonight :-)
Dave
On 18-06-2016, at 7:18 AM, David T. Lewis lewis@mail.msen.com wrote:
I also tried running the Squeak 5.0 all-in-one. It crashes. Yikes.
The attached nohup.out shows the error. Has this been reported before?
I suspect that it could be the CPIC problem where we had to redesign the CPIC.. except the 5.0 all-in-one should postdate the fix for that by some time… oh, maybe not. The AiO vm is date last July and the CPIC change was last October, after I got my first prototype Pi3.
So, almost certainly bad CPIC. We ought to fix the AiO soon, but we’re heading towards that anyway.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 4) "This machine is a piece of GAGH! I need dual G5 processors if I am to do battle with this code!"
Hi David,
On Jun 16, 2016, at 6:40 PM, David T. Lewis lewis@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.
I recommend you either set up a VNC server on the Pi and VNC in or use X11. I never attach a monitor to the Pi except during setup.
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.
- 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.
- 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 logged back in and ran the OSP/CommandShell tests again. Everything looks
good now, except that tests related to file locking protocol are failing. These are rarely used functions and may be linux distro dependent, so I'm not worried about these failures.
RemoteTask seems to be working also. Nice.
Overall, most of the OSProcess functionality seems to be just working, so
that is a pleasant surprise.
- I have gotten a few image lockups. I don't think it is related to OSProcess,
more likely that I am trying to use a "trunk level" V3 image, maybe a bit buggy at this point.
I will try setting up a Cog/Spur build next, and see what that looks like. But probably not tonight :-)
Dave
On Fri, Jun 17, 2016 at 12:42:59AM -0700, Eliot Miranda wrote:
Hi David,
On Jun 16, 2016, at 6:40 PM, David T. Lewis lewis@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.
I recommend you either set up a VNC server on the Pi and VNC in or use X11. I never attach a monitor to the Pi except during setup.
Thanks Eliot, I'll do that. I was partly making fun of myself fumbling around trying to put the pieces together for the first time. Remember that classic old video (from DEC research labs I think?) showing a first time user trying to insert a floppy disk into a PC? That was me setting up my new Pi ;-)
Dave
On Jun 17, 2016, at 5:03 AM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Jun 17, 2016 at 12:42:59AM -0700, Eliot Miranda wrote:
Hi David,
On Jun 16, 2016, at 6:40 PM, David T. Lewis lewis@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.
I recommend you either set up a VNC server on the Pi and VNC in or use X11. I never attach a monitor to the Pi except during setup.
Thanks Eliot, I'll do that. I was partly making fun of myself fumbling around trying to put the pieces together for the first time. Remember that classic old video (from DEC research labs I think?) showing a first time user trying to insert a floppy disk into a PC? That was me setting up my new Pi ;-)
:-). I can relate :-)
Dave
On Thu, 2016-06-16 at 21:40 -0400, David T. Lewis wrote:
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.
You can use it with a regular computer monitor assuming you have an extra one lying around with HDMI input (or a DVI->HDMI adapter, also you might need to disable overscan in the config file.) You can also setup ssh / VNC / remote X11 like any other Linux box for headless operation. My biggest complaint is the things have no power/reset switch out of the box (it is possible to add via a DIY mod) but other than that, it's a quite useful little device for Smalltalk!
On 17-06-2016, at 2:33 AM, Phil (list) pbpublist@gmail.com wrote:
My biggest complaint is the things have no power/reset switch out of the box (it is possible to add via a DIY mod) but other than that, it's a quite useful little device for Smalltalk!
I’m inclined to agree, but my attempted solution is to start work on a HAT that would provide a) power input from a wider range of PSUs with a switchmode regulator etc b) cooling (for heavily worked Pi3’s particularly - I did manage to work one so hard it just shut down) c) power/reboot switch d) (maybe) a basic ADC e) (maybe) some other small missing item
It’s very up in the air right now, might be a first attempt at a kickstarter etc. Anyone here interested?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His head whistles in a cross wind.
Hi Tim,
How about a small battery back up that can signal the software that it need to save and shutdown cleanly when it loses power.
Lou
On Fri, 17 Jun 2016 09:52:01 -0700, tim Rowledge tim@rowledge.org wrote:
On 17-06-2016, at 2:33 AM, Phil (list) pbpublist@gmail.com wrote:
My biggest complaint is the things have no power/reset switch out of the box (it is possible to add via a DIY mod) but other than that, it's a quite useful little device for Smalltalk!
Im inclined to agree, but my attempted solution is to start work on a HAT that would provide a) power input from a wider range of PSUs with a switchmode regulator etc b) cooling (for heavily worked Pi3s particularly - I did manage to work one so hard it just shut down) c) power/reboot switch d) (maybe) a basic ADC e) (maybe) some other small missing item
Its very up in the air right now, might be a first attempt at a kickstarter etc. Anyone here interested?
tim
On 17-06-2016, at 10:09 AM, Louis LaBrunda Lou@Keystone-Software.com wrote:
Hi Tim,
How about a small battery back up that can signal the software that it need to save and shutdown cleanly when it loses power.
There are actually several HATs to provide assorted UPS type functionality and/or battery power etc.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Trinoc does it take to change a lightbulb?” "Why do you want to know about our maintenance schedules? Are you planning to attack us in the dark?"
On Jun 17, 2016, at 10:09 AM, Louis LaBrunda Lou@Keystone-Software.com wrote:
Hi Tim,
How about a small battery back up that can signal the software that it need to save and shutdown cleanly when it loses power.
+1
Lou
On Fri, 17 Jun 2016 09:52:01 -0700, tim Rowledge tim@rowledge.org wrote:
On 17-06-2016, at 2:33 AM, Phil (list) pbpublist@gmail.com wrote:
My biggest complaint is the things have no power/reset switch out of the box (it is possible to add via a DIY mod) but other than that, it's a quite useful little device for Smalltalk!
I’m inclined to agree, but my attempted solution is to start work on a HAT that would provide a) power input from a wider range of PSUs with a switchmode regulator etc b) cooling (for heavily worked Pi3’s particularly - I did manage to work one so hard it just shut down) c) power/reboot switch d) (maybe) a basic ADC e) (maybe) some other small missing item
It’s very up in the air right now, might be a first attempt at a kickstarter etc. Anyone here interested?
tim
-- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon
On 17-06-2016, at 5:34 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Jun 17, 2016, at 10:09 AM, Louis LaBrunda Lou@Keystone-Software.com wrote:
Hi Tim,
How about a small battery back up that can signal the software that it need to save and shutdown cleanly when it loses power.
+1
http://www.piups.net/ http://www.modmypi.com/raspberry-pi/breakout-boards/pi-modules/ups-pico http://homediyelectronics.com/projects/raspberrypi/ups/ http://www.pimodulescart.com/shop/item.aspx?itemid=24 http://www.mini-box.com/picoUPS-100-12V-DC-micro-UPS-system-battery-backup-s...
Lots of choices here.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Success always occurs in private, and failure in full view.
On 16-06-2016, at 6:40 PM, David T. Lewis lewis@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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CPE: Create Parity Error
tim Rowledge wrote
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?
Just a thought, but reading the list of optimizations enabled with -O0 from https://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Optimize-Options.html, -f-omit-frame-pointer seems like a suspect that has caused problems before...
Could it be the arm make files are missing -fno-omit-frame-pointer at some crucial place?
Cheers, Henry
-- View this message in context: http://forum.world.st/Cog-Pi-OSProcess-tp4893984p4901424.html Sent from the Squeak VM mailing list archive at Nabble.com.
On 17-06-2016, at 6:09 AM, Henrik Sperre Johansen henrik.s.johansen@veloxit.no wrote:
Could it be the arm make files are missing -fno-omit-frame-pointer at some crucial place?
Always a possibility. gcc’s flags and options are like paying whack-a-mole, with a mole of moles.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: XO: Execute Operator
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?
Hi Tim,
It looks like the oscog branch of OSPP is broken. I tried OSProcess on my new Raspberry Pi, and it fails as you describe. I recompiled using source from my unaltered main branch of the plugin, and it works fine.
A quick fix is to just copy the generated source from the interpreter VM (src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c) and use it in your Spur VM build.
#forkSqueak is still broken (no display opens for the child Squeak) but that seems to be a problem elsewhere in the platforms code. It used to work in Cog, but I have not hunted down the regression.
Dave
On Sun, Jul 17, 2016 at 12:52:21PM -0400, David T. Lewis 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?
Hi Tim,
It looks like the oscog branch of OSPP is broken. I tried OSProcess on my new Raspberry Pi, and it fails as you describe. I recompiled using source from my unaltered main branch of the plugin, and it works fine.
A quick fix is to just copy the generated source from the interpreter VM (src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c) and use it in your Spur VM build.
#forkSqueak is still broken (no display opens for the child Squeak) but that seems to be a problem elsewhere in the platforms code. It used to work in Cog, but I have not hunted down the regression.
Well here is a milestone. I just made my first git pull request to fix the broken #forkSqueak problem so that "UnixProcess forkSqueak" will open a forked child Squeak with a new X11 display window:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/29/commits/6b40d65465...
And I think that my memory was probably failing me. After looking through the changes history, I don't think this ever worked in Cog. But it should work now :-)
So with this patch, and if you also use the trunk OSProcessPlugin instead of the oscog version, then you should have a reasonably functional OSProcess and CommandShell on your Raspberry Pi.
Best of all, the OSProcess and CommandShell unit tests will once again entertain you with lots of child process Squeak windows opening and closing all over your screen.
Dave
I recently made an update to fix X11 display reopening for Cog/Spur. I put the change into my dtlewis290 branch on github, and issued a pull request to merge it into Cog:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/29
I think that the next step is for someone to merge it into the Cog branch. But this is the first time I've committed something here, and I don't want to cause any problems. I would appreciate if someone (Eliot?) could take a look at this and hit the "Merge pull request" button if you think it looks ok.
Thanks,
Dave
On Mon, Jul 18, 2016 at 12:10:05AM -0400, David T. Lewis wrote:
On Sun, Jul 17, 2016 at 12:52:21PM -0400, David T. Lewis 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?
Hi Tim,
It looks like the oscog branch of OSPP is broken. I tried OSProcess on my new Raspberry Pi, and it fails as you describe. I recompiled using source from my unaltered main branch of the plugin, and it works fine.
A quick fix is to just copy the generated source from the interpreter VM (src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c) and use it in your Spur VM build.
#forkSqueak is still broken (no display opens for the child Squeak) but that seems to be a problem elsewhere in the platforms code. It used to work in Cog, but I have not hunted down the regression.
Well here is a milestone. I just made my first git pull request to fix the broken #forkSqueak problem so that "UnixProcess forkSqueak" will open a forked child Squeak with a new X11 display window:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/29/commits/6b40d65465...
And I think that my memory was probably failing me. After looking through the changes history, I don't think this ever worked in Cog. But it should work now :-)
So with this patch, and if you also use the trunk OSProcessPlugin instead of the oscog version, then you should have a reasonably functional OSProcess and CommandShell on your Raspberry Pi.
Best of all, the OSProcess and CommandShell unit tests will once again entertain you with lots of child process Squeak windows opening and closing all over your screen.
Dave
On 17-07-2016, at 9:52 AM, David T. Lewis lewis@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?
Hi Tim,
It looks like the oscog branch of OSPP is broken. I tried OSProcess on my new Raspberry Pi, and it fails as you describe. I recompiled using source from my unaltered main branch of the plugin, and it works fine.
A quick fix is to just copy the generated source from the interpreter VM (src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c) and use it in your Spur VM build.
I finally got a copy in the right place and built it with no problems.
#forkSqueak is still broken (no display opens for the child Squeak) but that seems to be a problem elsewhere in the platforms code. It used to work in Cog, but I have not hunted down the regression.
listDirectory works, forkSqueakAndDo: worked, spawnTenHeadlessChildren worked, catAFile worked … all pretty good news. Now all we have to do is get that file integrated.
Oh, I noticed the startSwiki… method, which looks very out of date. Do we have working swiki package(s) these days? It must be a decade or more since I had reason to look! The one on SM seems about that old...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Wibble" said Pooh the stress beginning to show.
Any chance of having an official version built with these fixed/regenerated sources? I've tested 3663 (latest at the time through apt-get update) and the new 201608171728 cogspurlinuxhtRPi, both still have the crashing OSProcess plugin AFAICT.
Cheers, Henry
On 18 Jul 2016, at 10:28 , tim Rowledge tim@rowledge.org wrote:
On 17-07-2016, at 9:52 AM, David T. Lewis lewis@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?
Hi Tim,
It looks like the oscog branch of OSPP is broken. I tried OSProcess on my new Raspberry Pi, and it fails as you describe. I recompiled using source from my unaltered main branch of the plugin, and it works fine.
A quick fix is to just copy the generated source from the interpreter VM (src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c) and use it in your Spur VM build.
I finally got a copy in the right place and built it with no problems.
#forkSqueak is still broken (no display opens for the child Squeak) but that seems to be a problem elsewhere in the platforms code. It used to work in Cog, but I have not hunted down the regression.
listDirectory works, forkSqueakAndDo: worked, spawnTenHeadlessChildren worked, catAFile worked … all pretty good news. Now all we have to do is get that file integrated.
Oh, I noticed the startSwiki… method, which looks very out of date. Do we have working swiki package(s) these days? It must be a decade or more since I had reason to look! The one on SM seems about that old...
tim
tim Rowledge; tim@rowledge.org mailto:tim@rowledge.org; http://www.rowledge.org/tim http://www.rowledge.org/tim "Wibble" said Pooh the stress beginning to show.
On 19-08-2016, at 2:11 AM, Henrik Johansen henrik.s.johansen@veloxit.no wrote:
Any chance of having an official version built with these fixed/regenerated sources? I've tested 3663 (latest at the time through apt-get update) and the new 201608171728 cogspurlinuxhtRPi, both still have the crashing OSProcess plugin AFAICT.
Yeah, it’s borken. Looks like we failed to follow up enough in July when this came up. Might have something to do with Dave’s accident ;-)
I’m taking a quick look to see if I can compare the two versions.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A "politically savvy challenge to evolution" is as self-evidently ridiculous as an agriculturally savvy challenge to euclidean geometry would be.
On 19-08-2016, at 12:04 PM, tim Rowledge tim@rowledge.org wrote:
On 19-08-2016, at 2:11 AM, Henrik Johansen henrik.s.johansen@veloxit.no wrote:
Any chance of having an official version built with these fixed/regenerated sources? I've tested 3663 (latest at the time through apt-get update) and the new 201608171728 cogspurlinuxhtRPi, both still have the crashing OSProcess plugin AFAICT.
Yeah, it’s borken. Looks like we failed to follow up enough in July when this came up. Might have something to do with Dave’s accident ;-)
I’m taking a quick look to see if I can compare the two versions.
Well after finally making a vmmaker image, the comparison of the cog & non-cog versions of osprocess etc are far too different for me to feel at all happy about messing with it. Sure, there’s a few methods where it’s just a change from a string to a symbol for some constant but the rest… nah.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computer Science: solving today's problems tomorrow.
On Fri, Aug 19, 2016 at 02:50:04PM -0700, tim Rowledge wrote:
On 19-08-2016, at 12:04 PM, tim Rowledge tim@rowledge.org wrote:
On 19-08-2016, at 2:11 AM, Henrik Johansen henrik.s.johansen@veloxit.no wrote:
Any chance of having an official version built with these fixed/regenerated sources? I've tested 3663 (latest at the time through apt-get update) and the new 201608171728 cogspurlinuxhtRPi, both still have the crashing OSProcess plugin AFAICT.
Yeah, it???s borken. Looks like we failed to follow up enough in July when this came up. Might have something to do with Dave???s accident ;-)
I???m taking a quick look to see if I can compare the two versions.
Well after finally making a vmmaker image, the comparison of the cog & non-cog versions of osprocess etc are far too different for me to feel at all happy about messing with it. Sure, there???s a few methods where it???s just a change from a string to a symbol for some constant but the rest??? nah.
I am temporarily separated from my Raspberry Pi, but I should be able to check it next week. I'm pretty sure that I had confirmed OSProcess working properly on Pi as long as I used the generated sources from my trunk OSProcessPlugin (not the oscog variant). I'll try to verify next week.
Dave
On 19-08-2016, at 4:27 PM, David T. Lewis lewis@mail.msen.com wrote:
I am temporarily separated from my Raspberry Pi, but I should be able to check it next week. I'm pretty sure that I had confirmed OSProcess working properly on Pi as long as I used the generated sources from my trunk OSProcessPlugin (not the oscog variant). I'll try to verify next week.
I too was able to make a plugin ok that works well from those sources but comparing the smalltalk code for the two versions is a bit much when I have no real clue what any of it does :-) It would be great to get the two versions aligned for the future.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Cackles a lot, but I ain't seen no eggs yet.
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Eliot Miranda -
Henrik Johansen -
Henrik Sperre Johansen
-
Louis LaBrunda -
Phil (list) -
Tim Felgentreff -
tim Rowledge