[Vm-dev] OSProcess fork issue with Debian built VM

[Eliot Miranda]

Hi Max,

On Thu, May 18, 2017 at 4:32 AM, Max Leske <maxleske at gmail.com> wrote:

>
> We managed to figure out that OSProcess works when we use gcc <= 4.8 on
> Debian. We are happy to use 4.8 for now, so we're good. It would of course
> be super cool if we could use the series 6 gcc as that will soon ship with
> Debian 9 (stretch) but it's probably not trivial to just move to a new
> compiler version (as seems evident from the fact that a minor version
> change can mess up compilation).
>

For the sake of revisiting this when we have time and can debug it can you
state which version(s) you tried to use which didn't work? Also, what are
the compilation flags (full gcc invocation example) for the case(s) that
work and the case(s) that don't?

Debugging this can be straight-forward if one can build the two versions
and execute them side-by-side to pin-point the failure.  Coming with a fix
may be more challenging ;-)


> Thanks for your help Alistair and Eliot.
>
> Cheers,
> Max
>
>
> On 18 May 2017, at 11:00, vm-dev-request at lists.squeakfoundation.org wrote:
>
> On 18 May 2017, at 00:50, vm-dev-request at lists.squeakfoundation.org wrote:
>
> Hi Max, Hi Alistair,
>
> On Wed, May 17, 2017 at 1:06 AM, Alistair Grant <akgrant0710 at gmail.com <
> mailto:akgrant0710 at gmail.com <akgrant0710 at gmail.com>>>
> wrote:
>
>
> On Tue, May 16, 2017 at 04:59:24PM +0200, Alistair Grant wrote:
>
> Hi Max,
>
> On 16 May 2017 15:40, "Max Leske" <maxleske at gmail.com <mailto:
> maxleske at gmail.com <maxleske at gmail.com>>> wrote:
>
>   Hi Alistair,
>
>       On 16 May 2017, at 15:32, vm-dev-request at lists.
>
> squeakfoundation.org <http://squeakfoundation.org/>
>
>       wrote:
>
>       Hi Max,
>
>       I can't answer your question directly, but just wondering why
>
> you are
>
>       using
>       the itimer VM when the are known issues with external calls, and
>
> not
>
>       the
>       heartbeat VM?
>
>   Because of the root user issue, and also because I don't care about
>
> that
>
>   much at the moment. I'm still experimenting and for those
>
> experiments it
>
>   doesn't matter which VM I use. Thirdly, the itimer VM is the one I
>
> get when
>
>   I use 'curl get.pharo.org/60+vmLatest <http://get.pharo.org/60+vmLatest>
> | bash', which is convenient
>
> to get
>
>   the latest VM, and to minimise differences between the VM's we built
>
> the
>
>   same one. I will definitely consider using the threaded VM for
>
> production.
>
>
>       P.S. I would love to see OSProcess working in 32 bit mode.
>
>   Well, it does work already, just not when we build the VM ourselves
>
> :/
>
>
> Interesting, I had the impression that for Pharo 6 OSProcess didn't work
>
> in
>
> 32bits, only 64, but I'm also building my own VM.  I'm away from my PC,
>
> but
>
> I'll try and take a look.
>
>
> I'm seeing the same behaviour as you, i.e. OSProcess works in a VM
> downloaded from get.pharo.org <http://get.pharo.org/>, but locks up when
> using the VM I
> compiled.
>
>
> Have you looked at the build logs and eliminated compiler version, command
> line flags, etc?  One important file is the config.h that is produced in
> the build directory.  It might be informative to compare the one configure
> is producing on your systems and the one that the binary builds creates.
>
>
> Thanks for the pointer. I'll look into it.
>
>
>
>
> Both VMs (threaded heartbeat) are based on the same source code, i.e.:
>
> VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git <
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git> $
> Date: Tue May 2 16:26:41 2017 -0700 $
>
> I'll try and take a look at this eventually, but I'm not sure how long
> that will be (several weeks away, at least).
>
> If you figure it out, please let me know.
>
> Thanks!
> Alistair
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170518/571cff13/attachment-0001.html>