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

Sun May 21 13:01:47 UTC 2017

On Sun, May 21, 2017 at 7:42 PM, Max Leske <maxleske at gmail.com> wrote:

>
> Hi Eliot,
>
> On 19 May 2017, at 16:45, Max Leske <maxleske at gmail.com> wrote:
>
>
> On 18 May 2017, at 20:52, vm-dev-request at lists.squeakfoundation.org wrote:
>
> 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?
>
>
> 4.6: worked
> 4.7: worked
> 4.8: worked
> 4.9: didn't work
>
>
> Diff between config log of 4.8 and 4.9:
>
> < Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.4-1'
> --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
> --program-suffix=-4.8 --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib
> --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
> --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
> --enable-plugin --with-system-zlib --disable-browser-plugin
> --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre
> --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386
> --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
> --enable-objc-gc --enable-targets=all --enable-multiarch
> --with-arch-32=i586 --with-multilib-list=m32,m64,mx32 --with-tune=generic
> --enable-checking=release --build=i586-linux-gnu --host=i586-linux-gnu
> --target=i586-linux-gnu
> ---
> > Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
> --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
> --program-suffix=-4.9 --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib
> --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
> --enable-libstdcxx-time=yes --enable-gnu-unique-object
> --disable-vtable-verify --enable-plugin --with-system-zlib
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386/jre
> --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386
> --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
> --enable-objc-gc --enable-targets=all --enable-multiarch
> --with-arch-32=i586 --with-multilib-list=m32,m64,mx32 --enable-multilib
> --with-tune=generic --enable-checking=release --build=i586-linux-gnu
> --host=i586-linux-gnu --target=i586-linux-gnu
>
> There are only three major differences here:
> --disable-libmudflap
> --disable-vtable-verify
> --enable-multilib
>

Just because I like pretty colours...
https://www.diffchecker.com/anD5GKht

>
> Below I've attached the log for building with 4.9 with
> '-fsanitize=undefined' as proposed by Holger Freyther.
>
> The builds were performed in two separate chroot jails so they did not
> influence each other. The system is a Debian Jessie, 64 bits.
>

Side question - I'm curious how you go about doing a chroot build.  In
another thread you could you post some more info on this?

cheers -ben

> Let me know if you need anything else.
>
> Cheers,
> Max
>
>
>
>
> Also, what are
> the compilation flags (full gcc invocation example) for the case(s) that
> work and the case(s) that don't?
>
>
> I'll send those as soon as I have them (hopefully tonight).
>
>
> 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> <
> 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/20170521/85f2c4ac/attachment-0001.html>