<div dir="ltr">Max, did you try with Eliot VMs besides the pharo ones?<div><br></div><div>Thanks</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 6, 2013 at 6:04 PM, Max Leske <span dir="ltr">&lt;<a href="mailto:maxleske@gmail.com" target="_blank">maxleske@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>Hi<br>
<br>
We’ve been encountering frequent SegFaults when running the Fuel tests on the Pharo CI (<a href="https://ci.inria.fr/pharo-contribution/job/Fuel/" target="_blank">https://ci.inria.fr/pharo-contribution/job/Fuel/</a>). 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).<br>

<br>
The CI uses the stable VM: <a href="http://files.pharo.org/vm/pharo/linux/stable.zip" target="_blank">http://files.pharo.org/vm/pharo/linux/stable.zip</a><br>
I use a newer version from October on my machine: <a href="http://files.pharo.org/vm/pharo/mac/273.zip" target="_blank">http://files.pharo.org/vm/pharo/mac/273.zip</a><br>
<br>
I’ve attached all the dumps of the crashes I was able to produce on my machine, together with Apple’s crash logs.<br>
<br>
I’ve been able to deduce the following:<br>
- garbage collection seems to be a trigger for the SegFault. When one of the methods FLMethodContextSerialization&gt;&gt;testFuelShouldIgnoreFuel and FLMethodContextSerialization&gt;&gt;testMethodContextWithNilPc contain the line “3 timesRepeat: [Smalltalk garbageCollect]” the SegFault appears nearly always (on CI). When I remove the line the builds run through.<br>

- Not all methods with the garbage collect line trigger a SegFault (I could only identify those two)<br>
- the garbage collect line itself suffices as a trigger in the mentioned methods.<br>
- The number of tests (amount of used memory?) seems to influence the appearence of the SegFault (e.g. loading &quot;DevelopmentGroup&quot; seems to trigger it more often than loading “Benchmarks”)<br>
- the SegFault always appears after the tests with the garbage collect line have been run, never before<br>
- the VM can’t write the crash.dmp every time<br>
<br>
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 (<a href="http://files.pharo.org/image/30/30549.zip" target="_blank">http://files.pharo.org/image/30/30549.zip</a>) and then evaluating the following in a workspace:<br>

<br>
Gofer it<br>
        smalltalkhubUser: &#39;Pharo&#39; project:  &#39;Fuel&#39;;<br>
        package: &#39;ConfigurationOfFuel&#39;;<br>
        load.<br>
<br>
((Smalltalk at: #ConfigurationOfFuel) project version: #bleedingEdge) load: &#39;DevelopmentGroup&#39;.<br>
<br>
HDTestReport<br>
        runClasses: (TestCase allSubclasses select: [ :class | class name beginsWith: &#39;FL&#39;])<br>
        named: ‘foo&#39;<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks for reading :)<br>
Max<br>
<br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
</div>