[Vm-dev] Segfaulting cog vm on FreeBSD

[Petr Fischer]

Crashing on the same line as before: http://pastebin.com/yK7YJig2 line 110.

Backtrace:
http://pastebin.com/r5bgn6f4

printAllStacks() - this is different than before, no UUID generator in stacktrace, crashed somewhere in Fuel serializer
http://pastebin.com/VDJnFtFp

Now what? How to debug this? Add some printf outputs to Core C sources?


>  
> Look for the method that calls #primitiveMakeUUID. Probably that will be
> UUID>>primMakeUUID. Then comment out this line:
> 
> 	"<primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'>"
> 
> The will prevent calls to the plugin, effectively disabling it.
> 
> When you are done testing, revert your #primMakeUUID method back to the
> way it was before.
> 
> Dave
> 
> 
> >
> > OK - how to  "temporarily remove UUIDPlugin"? Thanks, pf
> >
> >
> >>
> >> That's all fine. What I was trying to hint that maybe the UUID plugin is
> >> broken (it is definitely not generating UUIDs, since the fallback code
> >> is executed) and it messes up the object memory, which results in a
> >> crash in the GC. That's why I asked if it crashes with the plugin
> >> removed.
> >>
> >> Levente
> >>
> >> On Mon, 18 Jul 2016, Petr Fischer wrote:
> >>
> >> >
> >> > I am generating/instantiating thousand of objects (my simple data
> >> classes), and then persisting this medium sized object graph with Fuel
> >> to file.
> >> > While I am preparing object graph, UUID generator is used for
> >> generating random IDs and is called thousands times.
> >> > Final crash is in "scavengeReferentsOf" (via gdb) - probably Garbage
> >> Collector.
> >> >
> >> > pf
> >> >
> >> >>
> >> >> The image was generating an UUID when the crash happened. But
> >> primMakeUUID
> >> >> seem to had failed and the crash happened in the fallback code.
> >> >> Does the VM crash if you temporarily remove UUIDPlugin?
> >> >>
> >> >> Levente
> >> >>
> >> >> On Sun, 17 Jul 2016, Petr Fischer 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).
> >> >>>
> >> >>> 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 - 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
> >> >>>
> >> >
> >
> 
>