Hoi,
Does OSProcess work for other people with a 64-bit Linux VM? I am seeing strange errors specifically when I build in 64-bit mode: Processes always immediately print an obscure error and exit with status 127. The error is printed by the child process. It seems to contain some control characters, or a funky text encoding, and a large number for its error code. [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177", 6}, {": ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2}, {"Error 18446744073136382760", 26},\ {"\n", 1}], 10) = 52 More complete strace output in this gist: https://gist.github.com/ Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter what command is chosen.) Anybody else see this / not see this? Any ideas? Could be that some of the magic in the UnixOSProcessPlugin fork method is not working on 64-bit or with my toolchain...? |
Hi Luke,
I'm using OSProcess for my day to day development work in 64bits on the snap and default pharo vms, and it works. Regards, Thierry 2017-07-19 14:25 GMT+02:00 Luke Gorrie <[hidden email]>:
|
Thanks for that data point, Thierry! On 19 July 2017 at 14:29, Thierry Goubier <[hidden email]> wrote:
|
In reply to this post by Luke Gorrie
Hi Luke,
On Wed, Jul 19, 2017 at 02:25:55PM +0200, Luke Gorrie wrote: > Hoi, > > Does OSProcess work for other people with a 64-bit Linux VM? > > I am seeing strange errors specifically when I build in 64-bit mode: Processes > always immediately print an obscure error and exit with status 127. > > The error is printed by the child process. It seems to contain some control > characters, or a funky text encoding, and a large number for its error code. > > [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177", 6}, {": > ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2}, {"Error > 18446744073136382760", 26},\ > {"\n", 1}], 10) = 52 > > More complete strace output in this gist: https://gist.github.com/ > 81ca7b1c6b8cc412b66951bb6d57e1ea > > Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter what > command is chosen.) > > Anybody else see this / not see this? Any ideas? > > Could be that some of the magic in the UnixOSProcessPlugin fork method is not > working on 64-bit or with my toolchain...? I wanted to try and reproduce this with my locally built VM but can't even load OSProcess because it is using the deprecated message #ifNotNilDo:. I'm currently loading OSProcess using: Metacello new configuration: 'OSProcess'; version: #stable; repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main'; load. Would you please let me know how you load OSProcess? Thanks, Alistair |
Hi Alistair, I'm loading via the Gofer commands that I found here: Is that what fails for you? On 19 July 2017 at 15:56, Alistair Grant <[hidden email]> wrote: Hi Luke, |
In reply to this post by alistairgrant
Hi Alistair,
OSProcess use of ifNotNilDo: will simply get rewritten on the fly when you load it via Metacello. Thierry 2017-07-19 15:56 GMT+02:00 Alistair Grant <[hidden email]>: Hi Luke, |
In reply to this post by Luke Gorrie
Hi Luke,
On Wed, Jul 19, 2017 at 03:58:59PM +0200, Luke Gorrie wrote: > Hi Alistair, > > I'm loading via the Gofer commands that I found here: > http://pharo.gemtalksystems.com/book/PharoTools/OSProcess/ > > Is that what fails for you? Loading it in to Pharo 6 instead of Pharo 7 works :-) I'm not seeing the problems you mention below (using my locally built VM): $ pharo --version 5.0-201705310241 Mon Jun 12 17:15:39 CEST 2017 gcc 4.8.5 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 Jun 12 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2227 uuid: 7ea146b4-39ce-4de7-afa3-a76ed1d1da35 Jun 12 2017 VM: 201705310241 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Tue May 30 19:41:27 2017 -0700 $ Plugins: 201705310241 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux 95f17752871f 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /snap/pharo/9/usr/bin/pharo-vm/5.0-201705310241 [default: /snap/pharo/9/usr/bin/pharo-vm/5.0-201705310241/] Thierry, thanks for letting me know about the re-write, I'll look in to that next. Cheers, Alistair > On 19 July 2017 at 15:56, Alistair Grant <[hidden email]> wrote: > > Hi Luke, > > On Wed, Jul 19, 2017 at 02:25:55PM +0200, Luke Gorrie wrote: > > Hoi, > > > > Does OSProcess work for other people with a 64-bit Linux VM? > > > > I am seeing strange errors specifically when I build in 64-bit mode: > Processes > > always immediately print an obscure error and exit with status 127. > > > > The error is printed by the child process. It seems to contain some > control > > characters, or a funky text encoding, and a large number for its error > code. > > > > [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177", > 6}, {": > > ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2}, {"Error > > 18446744073136382760", 26},\ > > {"\n", 1}], 10) = 52 > > > > More complete strace output in this gist: https://gist.github.com/ > > 81ca7b1c6b8cc412b66951bb6d57e1ea > > > > Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter > what > > command is chosen.) > > > > Anybody else see this / not see this? Any ideas? > > > > Could be that some of the magic in the UnixOSProcessPlugin fork method is > not > > working on 64-bit or with my toolchain...? > > I wanted to try and reproduce this with my locally built VM but can't > even load OSProcess because it is using the deprecated message > #ifNotNilDo:. > > I'm currently loading OSProcess using: > > Metacello new > configuration: 'OSProcess'; > version: #stable; > repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/ > main'; > load. > > > Would you please let me know how you load OSProcess? > > Thanks, > Alistair |
In reply to this post by Thierry Goubier
Hi Thierry,
On Wed, Jul 19, 2017 at 04:01:46PM +0200, Thierry Goubier wrote: > Hi Alistair, > > OSProcess use of ifNotNilDo: will simply get rewritten on the fly when you load > it via Metacello. This doesn't work in Pharo 7 because the methods are no longer present (thus the re-write rule isn't present). Cheers, Alistair > Thierry > > 2017-07-19 15:56 GMT+02:00 Alistair Grant <[hidden email]>: > > Hi Luke, > > On Wed, Jul 19, 2017 at 02:25:55PM +0200, Luke Gorrie wrote: > > Hoi, > > > > Does OSProcess work for other people with a 64-bit Linux VM? > > > > I am seeing strange errors specifically when I build in 64-bit mode: > Processes > > always immediately print an obscure error and exit with status 127. > > > > The error is printed by the child process. It seems to contain some > control > > characters, or a funky text encoding, and a large number for its error > code. > > > > [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177", > 6}, {": > > ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2}, {"Error > > 18446744073136382760", 26},\ > > {"\n", 1}], 10) = 52 > > > > More complete strace output in this gist: https://gist.github.com/ > > 81ca7b1c6b8cc412b66951bb6d57e1ea > > > > Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter > what > > command is chosen.) > > > > Anybody else see this / not see this? Any ideas? > > > > Could be that some of the magic in the UnixOSProcessPlugin fork method is > not > > working on 64-bit or with my toolchain...? > > I wanted to try and reproduce this with my locally built VM but can't > even load OSProcess because it is using the deprecated message > #ifNotNilDo:. > > I'm currently loading OSProcess using: > > Metacello new > configuration: 'OSProcess'; > version: #stable; > repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/ > main'; > load. > > > Would you please let me know how you load OSProcess? > > Thanks, > Alistair |
Free forum by Nabble | Edit this page |