[Vm-dev] Segfaulting cog vm on FreeBSD

Ben Coman btc at openinworld.com
Mon Jul 18 03:23:30 UTC 2016

On Mon, Jul 18, 2016 at 4:22 AM, Petr Fischer <petr.fischer at me.com> wrote:
> Hello! Moving discussion about %subj% from pharo-dev list.
> My problem on FreeBSD:
> There is a linux compatibility layer on FreeBSD (even 64bits on 11-CURRENT), so there is no theoretical problem running pharo linux vms.
> But: complete linux libraries comming from centos 6.7, where is glibc older than 2.15 - so, no luck with actual default pharo vm from pharo.org.
> So I compiled my own pharo-vm on CentOS 6.7 with old glibc, everything is OK on Linux CentOS box, but on the FreeBSD side, vm is segfaulting (my own compiled "stack" vm is more stable, but segfaulting too).
> I compiled from pharo-vm git:
> https://github.com/pharo-project/pharo-vm
> I am building "PharoVMSpur32Builder buildUnix32"
> (there is some old "PharoVMBuilder buildFreeBSD", but probably unmaintained).

btw, why do you think its old and unmaintained? The file [1] has a commit
comment "Add a working FreeBSD 10.0-RELEASE/11-CURRENT config"
which seems to match your environment.

> Why I can't compile directly on the FreeBSD without Linux compatibility layer? Because there is a step, when I need to Load VMMaker into functional stable image.

One commit of the Pharo FreeBSD pull request [4] says "Generate
relocatable buildsystem - This way I can generate it on my laptop and
move the source to a remote system, that seems set by
"EXECUTABLE_OUTPUT_PATH".  Have you tried that path to copy sources
generated on Linux over to FreeBSD to build there?

One thing I notice from [4] is that it seems it disables the X11
display (Could someone else comment on the effect of that change?). So
perhaps you could test the generated VM using a headless script, and
then work on restoring the X11 display into the build.

Pharo generates the sources locally each time you build the VM.
Squeak keeps the generated sources under version control, which you
can get from [2]
and then...
$ cd opensmalltalk-vm/build.linux32x86/squeak.stack.spur/build.debug
$ ./mvm
Squeak has a few less 3rd-party lib dependencies, so you may have
better luck if you can copy Pharo FreeBSD changes [4] to the Squeak VM
build.  Significantly, I notice at [1] that the Pharo FreeBSD VM
builds with -O1 optimisation
while I the standard platforms build with -O2 optimisation.  So
probably you should at least change that.
Read [3] on how to force those CFLAGS using `configure` on your platform.

Eliot, For supporting a standard Squeak FreeBSD build, would those
changes from [4]>[Files Changed] be able to be integrated under the
build.linux32x86 folder, or would a new build.freebsd (or build.bsd)
folder be better?  Would you have any particular requirements to
create such a build folder?

[1] https://github.com/pharo-project/pharo-vm/blob/master/mc/CMakeVMMaker.package/CogFreeBSDConfig.class/instance/setExtraTargetProperties..st
[2] https://github.com/OpenSmalltalk/opensmalltalk-vm
[3] https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.linux32x86/HowToBuild
[4] https://github.com/pharo-project/pharo-vm/pull/59

cheers -ben

P.S. Bumped into an interesting comparison of optimsation levels for
one application...

> - when I use my compiled vm, of course, segfaulting while loading VMMaker... Therefore I am going via Linux comp. layer. Native port of vm for FreeBSD will be the next step.

> Ok, ok, next steps... I compiled my own "debug vm" (cog, spur, again on CentOS 6.7) and here is some outputs from my gdb session (I am definitely not Core C hacker):
> Crashing code snippet - function is "scavengeReferentsOf" and crashing line is 110:
> http://pastebin.com/yK7YJig2
> Backtrace:
> http://pastebin.com/jMgzE9G0
> printAllStacks:
> http://pastebin.com/VP1nwrsC
> Now I am at end with my knowledge (vm internals) - but I can add some printf/log outputs into generated C files, recompile and retest.
> Any ideas? Thanks very much. pf

More information about the Vm-dev mailing list