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

Sun May 21 11:42:16 UTC 2017

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 <mailto: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 <mailto: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

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.

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 <mailto:vm-dev-request at lists.squeakfoundation.org> wrote:
>>> 
>>> On 18 May 2017, at 00:50, vm-dev-request at lists.squeakfoundation.org <mailto: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> <
>>> mailto:akgrant0710 at gmail.com <mailto:akgrant0710 at gmail.com> <akgrant0710 at gmail.com <mailto: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> <mailto:
>>> maxleske at gmail.com <mailto:maxleske at gmail.com> <maxleske at gmail.com <mailto:maxleske at gmail.com>>>> wrote:
>>> 
>>>  Hi Alistair,
>>> 
>>>      On 16 May 2017, at 15:32, vm-dev-request at lists.
>>> 
>>> squeakfoundation.org <http://squeakfoundation.org/> <http://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> <http://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/> <http://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> <
>>> 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/84c11904/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: application/octet-stream
Size: 112155 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170521/84c11904/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170521/84c11904/attachment-0003.html>