Hi Eliot,

On 19 May 2017, at 16:45, Max Leske <[hidden email]> wrote:

On 18 May 2017, at 20:52, [hidden email] wrote:

Hi Max,

On Thu, May 18, 2017 at 4:32 AM, Max Leske <[hidden email]> 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, [hidden email] wrote:

On 18 May 2017, at 00:50, [hidden email] wrote:

Hi Max, Hi Alistair,

On Wed, May 17, 2017 at 1:06 AM, Alistair Grant <[hidden email] <
[hidden email] <[hidden email]>>>
wrote:


On Tue, May 16, 2017 at 04:59:24PM +0200, Alistair Grant wrote:

Hi Max,

On 16 May 2017 15:40, "Max Leske" <[hidden email] <mailto:
[hidden email] <[hidden email]>>> wrote:

 Hi Alistair,

     On 16 May 2017, at 15:32, vm-dev-request@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