[Pharo-dev] [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0

Max Leske maxleske at gmail.com
Mon Nov 25 05:58:32 EST 2013

I was able to isolate the image where the SegFault problem appears first: 30435. Here’s the update method:

	"self new update30435"
	self withUpdateLog: '11729 Sync Opa from repo: #timesRepeat optimization enabled
11720 DateModel: Add #displayBlock:
11727 remove unused ivar scrollBarOnLeft in ScrollPane
	self loadTogether: self script114 merge: false.
	(SystemNavigation new allCallsOn: #timesRepeat:) do: [ :each | each method recompile ].
	self flushCaches.

What I noticed is that 11729 is about #timesRepeat: and the code I used to trigger the SegFaults is “3 timesRepeat: [ Smalltalk garbageCollect ]”. So the problem might actually lie in #timesRepeat: rather than in #garbageCollect:

I’ve put you into CC because I hope that you know more about #timesRepeat:


On 25.11.2013, at 08:26, Max Leske <maxleske at gmail.com> wrote:

> Interesting development: no SegFaults (while using exactly the same code) when using an older Pharo image (version 30321 instead of latest).
> This obviously suggests that the problem lies with the image and not necessarily the vm.
> Max
> On 10.11.2013, at 20:10, Max Leske <maxleske at gmail.com> wrote:
>> On 07.11.2013, at 08:20, Max Leske <maxleske at gmail.com> wrote:
>>> On 07.11.2013, at 00:27, vm-dev-request at lists.squeakfoundation.org wrote:
>>>> Date: Wed, 6 Nov 2013 19:23:47 -0200
>>>> From: Mariano Martinez Peck <marianopeck at gmail.com>
>>>> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0
>>>> To: Squeak Virtual Machine Development Discussion
>>>> 	<vm-dev at lists.squeakfoundation.org>
>>>> Message-ID:
>>>> 	<CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ at mail.gmail.com>
>>>> Content-Type: text/plain; charset="windows-1252"
>>>> Max, did you try with Eliot VMs besides the pharo ones?
>>> No, I haven’t. I can try (though only on my machine), but if I can’t reproduce the SegFault that doesn’t mean much unfortunately. It took me 10 to 20 tries with the PharoVM too…
>>> I’ll try anyway and let you know what I find.
>>> Max
>> I just gave CogVM and NBCog a shot. Unfortunately I can’t use the images because they’ve been built with PharoVM and hang after load. At least on the Pharo CI there are no jobs that create Cog / NBCog images.
>> So no luck with different VMs.
>> Max
>>>> Thanks
>>>> On Wed, Nov 6, 2013 at 6:04 PM, Max Leske <maxleske at gmail.com> wrote:
>>>>> Hi
>>>>> We’ve been encountering frequent SegFaults when running the Fuel tests on
>>>>> the Pharo CI (https://ci.inria.fr/pharo-contribution/job/Fuel/). Since
>>>>> today I’ve also been able to reproduce the SegFaults on my MacBook Pro (OS
>>>>> X 10.9) too. We have not been able to determine the cause of the SegFault
>>>>> but we can produce SegFaults often, although not reliable (more reliable on
>>>>> the CI).
>>>>> The CI uses the stable VM:
>>>>> http://files.pharo.org/vm/pharo/linux/stable.zip
>>>>> I use a newer version from October on my machine:
>>>>> http://files.pharo.org/vm/pharo/mac/273.zip
>>>>> I’ve attached all the dumps of the crashes I was able to produce on my
>>>>> machine, together with Apple’s crash logs.
>>>>> I’ve been able to deduce the following:
>>>>> - garbage collection seems to be a trigger for the SegFault. When one of
>>>>> the methods FLMethodContextSerialization>>testFuelShouldIgnoreFuel and
>>>>> FLMethodContextSerialization>>testMethodContextWithNilPc contain the line
>>>>> “3 timesRepeat: [Smalltalk garbageCollect]” the SegFault appears nearly
>>>>> always (on CI). When I remove the line the builds run through.
>>>>> - Not all methods with the garbage collect line trigger a SegFault (I
>>>>> could only identify those two)
>>>>> - the garbage collect line itself suffices as a trigger in the mentioned
>>>>> methods.
>>>>> - The number of tests (amount of used memory?) seems to influence the
>>>>> appearence of the SegFault (e.g. loading "DevelopmentGroup" seems to
>>>>> trigger it more often than loading “Benchmarks”)
>>>>> - the SegFault always appears after the tests with the garbage collect
>>>>> line have been run, never before
>>>>> - the VM can’t write the crash.dmp every time
>>>>> Since the SegFaults are so random I cannot give you an image to reproduce
>>>>> the problem. I’ve had the best results using a fresh 3.0 image (
>>>>> http://files.pharo.org/image/30/30549.zip) and then evaluating the
>>>>> following in a workspace:
>>>>> Gofer it
>>>>>        smalltalkhubUser: 'Pharo' project:  'Fuel';
>>>>>        package: 'ConfigurationOfFuel';
>>>>>        load.
>>>>> ((Smalltalk at: #ConfigurationOfFuel) project version: #bleedingEdge)
>>>>> load: 'DevelopmentGroup'.
>>>>> HDTestReport
>>>>>        runClasses: (TestCase allSubclasses select: [ :class | class name
>>>>> beginsWith: 'FL'])
>>>>>        named: ‘foo'
>>>>> If it doesn’t work, try using the TestRunner manually. Select the default
>>>>> Fuel tests (alphabetically at F) and the additional Fuel tests (at the
>>>>> bottom of the list) and run them.
>>>>> If anybody has any clue about what could be going on I’d really appreciate
>>>>> any input. I’ll happily provide more information if I can.
>>>>> Thanks for reading :)
>>>>> Max
>>>> -- 
>>>> Mariano
>>>> http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131125/253050b3/attachment-0002.html>

More information about the Pharo-dev mailing list