Re: [Pharo-dev] [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0
On 07.11.2013, at 00:27, vm-dev-request@lists.squeakfoundation.org wrote:
Date: Wed, 6 Nov 2013 19:23:47 -0200 From: Mariano Martinez Peck <marianopeck@gmail.com> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org> Message-ID: <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ@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
Thanks
On Wed, Nov 6, 2013 at 6:04 PM, Max Leske <maxleske@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
On 07.11.2013, at 08:20, Max Leske <maxleske@gmail.com> wrote:
On 07.11.2013, at 00:27, vm-dev-request@lists.squeakfoundation.org wrote:
Date: Wed, 6 Nov 2013 19:23:47 -0200 From: Mariano Martinez Peck <marianopeck@gmail.com> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org> Message-ID: <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ@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@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
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@gmail.com> wrote:
On 07.11.2013, at 08:20, Max Leske <maxleske@gmail.com> wrote:
On 07.11.2013, at 00:27, vm-dev-request@lists.squeakfoundation.org wrote:
Date: Wed, 6 Nov 2013 19:23:47 -0200 From: Mariano Martinez Peck <marianopeck@gmail.com> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org> Message-ID: <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ@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@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
I was able to isolate the image where the SegFault problem appears first: 30435. Hereâs the update method: update30435 "self new update30435" self withUpdateLog: '11729 Sync Opa from repo: #timesRepeat optimization enabled https://pharo.fogbugz.com/f/cases/11729 11720 DateModel: Add #displayBlock: https://pharo.fogbugz.com/f/cases/11720 11727 remove unused ivar scrollBarOnLeft in ScrollPane https://pharo.fogbugz.com/f/cases/11727'. 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: @Marcus Iâve put you into CC because I hope that you know more about #timesRepeat: Cheers, Max On 25.11.2013, at 08:26, Max Leske <maxleske@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@gmail.com> wrote:
On 07.11.2013, at 08:20, Max Leske <maxleske@gmail.com> wrote:
On 07.11.2013, at 00:27, vm-dev-request@lists.squeakfoundation.org wrote:
Date: Wed, 6 Nov 2013 19:23:47 -0200 From: Mariano Martinez Peck <marianopeck@gmail.com> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org> Message-ID: <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ@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@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
Hello, In this version I added #timesRepeat: as a special selector to be inlined by the compiler (as #to:do:, #ifTrue:, ...). There was already another side effect of this addition of timesRepeat: as a special selector for XStreams. I guess we should remove it. Try to edit the default Opal options in: OpalCompiler>>#defaultOptions instead of: + optionInlineTimesRepeat put: - optionInlineTimesRepeat Then execute: OpalCompiler recompileAll. (If you run your code with a DoIt you do not need to recompileAll, but just in case ...) And see if you bug comes from the timesRepeat:. Now the bytecode for "3 timesRepeat: [ Smalltalk garbageCollect ]" is correct. But there may be some side effect in the VM I am not thinking of. 29 <20> pushConstant: 3 30 <68> popIntoTemp: 0 31 <10> pushTemp: 0 32 <76> pushConstant: 1 33 <69> popIntoTemp: 1 34 <11> pushTemp: 1 35 <10> pushTemp: 0 36 <B4> send: <= 37 <AC 09> jumpFalse: 48 39 <41> pushLit: Smalltalk 40 <D2> send: garbageCollect 41 <87> pop 42 <11> pushTemp: 1 43 <76> pushConstant: 1 44 <B0> send: + 45 <69> popIntoTemp: 1 46 <A3 F2> jumpTo: 34 48 <7C> returnTop 2013/11/25 Max Leske <maxleske@gmail.com>
I was able to isolate the image where the SegFault problem appears first: 30435. Hereâs the update method:
update30435 "self new update30435" self withUpdateLog: '11729 Sync Opa from repo: #timesRepeat optimization enabled https://pharo.fogbugz.com/f/cases/11729 11720 DateModel: Add #displayBlock: https://pharo.fogbugz.com/f/cases/11720 11727 remove unused ivar scrollBarOnLeft in ScrollPane https://pharo.fogbugz.com/f/cases/11727'. 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:
@Marcus Iâve put you into CC because I hope that you know more about #timesRepeat:
Cheers, Max
On 25.11.2013, at 08:26, Max Leske <maxleske@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@gmail.com> wrote:
On 07.11.2013, at 08:20, Max Leske <maxleske@gmail.com> wrote:
On 07.11.2013, at 00:27, vm-dev-request@lists.squeakfoundation.org wrote:
Date: Wed, 6 Nov 2013 19:23:47 -0200 From: Mariano Martinez Peck <marianopeck@gmail.com> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org> Message-ID: <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ@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@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
Thanks Clément, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like thereâs another (Opal related?) problem (with the exact same symptomsâ¦). Iâve tried disabling all options, just to see what happens: all builds fail with SegFaults⦠Iâll keep playing around, maybe Iâll find a configuration that works. Cheers, Max On 25.11.2013, at 13:13, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
In this version I added #timesRepeat: as a special selector to be inlined by the compiler (as #to:do:, #ifTrue:, ...). There was already another side effect of this addition of timesRepeat: as a special selector for XStreams. I guess we should remove it.
Try to edit the default Opal options in: OpalCompiler>>#defaultOptions
instead of: + optionInlineTimesRepeat put: - optionInlineTimesRepeat
Then execute: OpalCompiler recompileAll. (If you run your code with a DoIt you do not need to recompileAll, but just in case ...)
And see if you bug comes from the timesRepeat:.
Now the bytecode for "3 timesRepeat: [ Smalltalk garbageCollect ]" is correct. But there may be some side effect in the VM I am not thinking of.
29 <20> pushConstant: 3 30 <68> popIntoTemp: 0 31 <10> pushTemp: 0 32 <76> pushConstant: 1 33 <69> popIntoTemp: 1 34 <11> pushTemp: 1 35 <10> pushTemp: 0 36 <B4> send: <= 37 <AC 09> jumpFalse: 48 39 <41> pushLit: Smalltalk 40 <D2> send: garbageCollect 41 <87> pop 42 <11> pushTemp: 1 43 <76> pushConstant: 1 44 <B0> send: + 45 <69> popIntoTemp: 1 46 <A3 F2> jumpTo: 34 48 <7C> returnTop
2013/11/25 Max Leske <maxleske@gmail.com> I was able to isolate the image where the SegFault problem appears first: 30435. Hereâs the update method:
update30435 "self new update30435" self withUpdateLog: '11729 Sync Opa from repo: #timesRepeat optimization enabled https://pharo.fogbugz.com/f/cases/11729
11720 DateModel: Add #displayBlock: https://pharo.fogbugz.com/f/cases/11720
11727 remove unused ivar scrollBarOnLeft in ScrollPane https://pharo.fogbugz.com/f/cases/11727'. 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:
@Marcus Iâve put you into CC because I hope that you know more about #timesRepeat:
Cheers, Max
On 25.11.2013, at 08:26, Max Leske <maxleske@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@gmail.com> wrote:
On 07.11.2013, at 08:20, Max Leske <maxleske@gmail.com> wrote:
On 07.11.2013, at 00:27, vm-dev-request@lists.squeakfoundation.org wrote:
Date: Wed, 6 Nov 2013 19:23:47 -0200 From: Mariano Martinez Peck <marianopeck@gmail.com> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org> Message-ID: <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ@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@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
On 25 Nov 2013, at 16:26, Max Leske <maxleske@gmail.com> wrote:
Thanks Clément, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like thereâs another (Opal related?) problem (with the exact same symptomsâ¦).
Iâve tried disabling all options, just to see what happens: all builds fail with SegFaultsâ¦
You can not compile without optimisations. There are places in the image that would not work with e.g. whileTrue: optimisation disabled as it would e.g. add an interrupt point where none is now And other things, like performance, or e.g. the loop that goes over all objects, if that creates objects while running you have a problem⦠Marcus
Yeah you cannot compile without inlining specific messages. You can disable inlining of #timesRepeat: at image level because we added it for fun to see if it was easy to do in Opal. Now all other optimizations were in the old compiler and are mandatories. However, you can now in Opal disable these optimized messages in a restricted area (such as a class and its subclasses). To me, it is kind of a bug that we cannot disable those optimizations, we should be able to do it (so 1 day in the very very far future we could have the JIT inlining these control structure allowing us to implement all these inlined messages in all classes). But one thing is that some methods such as #whileTrue are not implemented in a way they really work (they have not stop condition, so if the compiler does not inline it, it gives you an infinite loop). Another thing is the interrupt point problem as Marcus said. I don't think your other bug is related Opal optimization, only #timesRepeat: is new and therefore can be faulty (and in this case, the bytecode is correct, so I guess it is faulty because it removes an interrupt point). 2013/11/25 Marcus Denker <marcus.denker@inria.fr>
On 25 Nov 2013, at 16:26, Max Leske <maxleske@gmail.com> wrote:
Thanks Clément, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like thereâs another (Opal related?) problem (with the exact same symptomsâ¦).
Iâve tried disabling all options, just to see what happens: all builds fail with SegFaultsâ¦
You can not compile without optimisations. There are places in the image that would not work with e.g. whileTrue: optimisation disabled as it would e.g. add an interrupt point where none is now And other things, like performance, or e.g. the loop that goes over all objects, if that creates objects while running you have a problemâ¦
Marcus
On 25 Nov 2013, at 17:56, Clément Bera <bera.clement@gmail.com> wrote:
Yeah you cannot compile without inlining specific messages. You can disable inlining of #timesRepeat: at image level because we added it for fun to see if it was easy to do in Opal. Now all other optimizations were in the old compiler and are mandatories. However, you can now in Opal disable these optimized messages in a restricted area (such as a class and its subclasses).
To me, it is kind of a bug that we cannot disable those optimizations, we should be able to do it (so 1 day in the very very far future we could have the JIT inlining these control structure allowing us to implement all these inlined messages in all classes). But one thing is that some methods such as #whileTrue are not implemented in a way they really work (they have not stop condition, so if the compiler does not inline it, it gives you an infinite loop). Another thing is the interrupt point problem as Marcus said.
I don't think your other bug is related Opal optimization, only #timesRepeat: is new and therefore can be faulty (and in this case, the bytecode is correct, so I guess it is faulty because it removes an interrupt point).
It is a bit scary that there is no explicit, crystal clear list of those interrupt critical points, especially if skipping them can lead to VM crashes.
2013/11/25 Marcus Denker <marcus.denker@inria.fr>
On 25 Nov 2013, at 16:26, Max Leske <maxleske@gmail.com> wrote:
Thanks Clément, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like thereâs another (Opal related?) problem (with the exact same symptomsâ¦).
Iâve tried disabling all options, just to see what happens: all builds fail with SegFaultsâ¦
You can not compile without optimisations. There are places in the image that would not work with e.g. whileTrue: optimisation disabled as it would e.g. add an interrupt point where none is now And other things, like performance, or e.g. the loop that goes over all objects, if that creates objects while running you have a problemâ¦
Marcus
On Mon, Nov 25, 2013 at 9:37 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 25 Nov 2013, at 17:56, Clément Bera <bera.clement@gmail.com> wrote:
Yeah you cannot compile without inlining specific messages. You can disable inlining of #timesRepeat: at image level because we added it for fun to see if it was easy to do in Opal. Now all other optimizations were in the old compiler and are mandatories. However, you can now in Opal disable these optimized messages in a restricted area (such as a class and its subclasses).
To me, it is kind of a bug that we cannot disable those optimizations, we should be able to do it (so 1 day in the very very far future we could have the JIT inlining these control structure allowing us to implement all these inlined messages in all classes). But one thing is that some methods such as #whileTrue are not implemented in a way they really work (they have not stop condition, so if the compiler does not inline it, it gives you an infinite loop). Another thing is the interrupt point problem as Marcus said.
I don't think your other bug is related Opal optimization, only #timesRepeat: is new and therefore can be faulty (and in this case, the bytecode is correct, so I guess it is faulty because it removes an interrupt point).
It is a bit scary that there is no explicit, crystal clear list of those interrupt critical points, especially if skipping them can lead to VM crashes.
Before we raise the alarm the first thing is to identify the cause of the VM crash. It could still be a VM bug. First track down the bug. Don't try and find work-arounds. Try and find the cause. Only then can one develop a correct fix. Anything else buries the true cause under hacks, a process that is truly scary ;-)
2013/11/25 Marcus Denker <marcus.denker@inria.fr>
On 25 Nov 2013, at 16:26, Max Leske <maxleske@gmail.com> wrote:
Thanks Clément, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like thereâs another (Opal related?) problem (with the exact same symptomsâ¦).
Iâve tried disabling all options, just to see what happens: all builds fail with SegFaultsâ¦
You can not compile without optimisations. There are places in the image that would not work with e.g. whileTrue: optimisation disabled as it would e.g. add an interrupt point where none is now And other things, like performance, or e.g. the loop that goes over all objects, if that creates objects while running you have a problemâ¦
Marcus
-- best, Eliot
Thanks for the explanation. I suspected something like that (interestingly when I tried disabling all options on my Mac it worked fineâ¦). Iâll dig some more and let you know. On 25.11.2013, at 18:42, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Mon, Nov 25, 2013 at 9:37 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 25 Nov 2013, at 17:56, Clément Bera <bera.clement@gmail.com> wrote:
Yeah you cannot compile without inlining specific messages. You can disable inlining of #timesRepeat: at image level because we added it for fun to see if it was easy to do in Opal. Now all other optimizations were in the old compiler and are mandatories. However, you can now in Opal disable these optimized messages in a restricted area (such as a class and its subclasses).
To me, it is kind of a bug that we cannot disable those optimizations, we should be able to do it (so 1 day in the very very far future we could have the JIT inlining these control structure allowing us to implement all these inlined messages in all classes). But one thing is that some methods such as #whileTrue are not implemented in a way they really work (they have not stop condition, so if the compiler does not inline it, it gives you an infinite loop). Another thing is the interrupt point problem as Marcus said.
I don't think your other bug is related Opal optimization, only #timesRepeat: is new and therefore can be faulty (and in this case, the bytecode is correct, so I guess it is faulty because it removes an interrupt point).
It is a bit scary that there is no explicit, crystal clear list of those interrupt critical points, especially if skipping them can lead to VM crashes.
Before we raise the alarm the first thing is to identify the cause of the VM crash. It could still be a VM bug. First track down the bug. Don't try and find work-arounds. Try and find the cause. Only then can one develop a correct fix. Anything else buries the true cause under hacks, a process that is truly scary ;-)
2013/11/25 Marcus Denker <marcus.denker@inria.fr>
On 25 Nov 2013, at 16:26, Max Leske <maxleske@gmail.com> wrote:
Thanks Clément, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like thereâs another (Opal related?) problem (with the exact same symptomsâ¦).
Iâve tried disabling all options, just to see what happens: all builds fail with SegFaultsâ¦
You can not compile without optimisations. There are places in the image that would not work with e.g. whileTrue: optimisation disabled as it would e.g. add an interrupt point where none is now And other things, like performance, or e.g. the loop that goes over all objects, if that creates objects while running you have a problemâ¦
Marcus
-- best, Eliot
2013/11/26 Max Leske <maxleske@gmail.com>
Thanks for the explanation. I suspected something like that (interestingly when I tried disabling all options on my Mac it worked fineâ¦).
This is because you didn't execute: 'OpalCompiler recompileAll'.
Iâll dig some more and let you know.
We should dig into the '3 timesRepeat: [ Smalltalk garbageCollect ]', because this may be a bug somewhere. Now we shouldn't dig into having a system running without condition and loops inlined by the compiler, because this is too much work (for example as Marcus said loops on all objects should not create an object (even a context) ...). If we really want that we will invest time. But right now it is not a priority.
On 25.11.2013, at 18:42, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Mon, Nov 25, 2013 at 9:37 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 25 Nov 2013, at 17:56, Clément Bera <bera.clement@gmail.com> wrote:
Yeah you cannot compile without inlining specific messages. You can disable inlining of #timesRepeat: at image level because we added it for fun to see if it was easy to do in Opal. Now all other optimizations were in the old compiler and are mandatories. However, you can now in Opal disable these optimized messages in a restricted area (such as a class and its subclasses).
To me, it is kind of a bug that we cannot disable those optimizations, we should be able to do it (so 1 day in the very very far future we could have the JIT inlining these control structure allowing us to implement all these inlined messages in all classes). But one thing is that some methods such as #whileTrue are not implemented in a way they really work (they have not stop condition, so if the compiler does not inline it, it gives you an infinite loop). Another thing is the interrupt point problem as Marcus said.
I don't think your other bug is related Opal optimization, only #timesRepeat: is new and therefore can be faulty (and in this case, the bytecode is correct, so I guess it is faulty because it removes an interrupt point).
It is a bit scary that there is no explicit, crystal clear list of those interrupt critical points, especially if skipping them can lead to VM crashes.
Before we raise the alarm the first thing is to identify the cause of the VM crash. It could still be a VM bug. First track down the bug. Don't try and find work-arounds. Try and find the cause. Only then can one develop a correct fix. Anything else buries the true cause under hacks, a process that is truly scary ;-)
2013/11/25 Marcus Denker <marcus.denker@inria.fr>
On 25 Nov 2013, at 16:26, Max Leske <maxleske@gmail.com> wrote:
Thanks Clément, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like thereâs another (Opal related?) problem (with the exact same symptomsâ¦).
Iâve tried disabling all options, just to see what happens: all builds fail with SegFaultsâ¦
You can not compile without optimisations. There are places in the image that would not work with e.g. whileTrue: optimisation disabled as it would e.g. add an interrupt point where none is now And other things, like performance, or e.g. the loop that goes over all objects, if that creates objects while running you have a problemâ¦
Marcus
-- best, Eliot
On 26 Nov 2013, at 15:56, Clément Bera <bera.clement@gmail.com> wrote:
2013/11/26 Max Leske <maxleske@gmail.com> Thanks for the explanation. I suspected something like that (interestingly when I tried disabling all options on my Mac it worked fineâ¦).
This is because you didn't execute: 'OpalCompiler recompileAll'.
Iâll dig some more and let you know.
We should dig into the '3 timesRepeat: [ Smalltalk garbageCollect ]', because this may be a bug somewhere. Now we shouldn't dig into having a system running without condition and loops inlined by the compiler, because this is too much work (for example as Marcus said loops on all objects should not create an object (even a context) ...). If we really want that we will invest time. But right now it is not a priority.
You need to see that the system *never* ran without optimising ifTrue: &co, so getting that to work is a real project in itself⦠and it will be *extremely* slow, of course. And it does not even help for the problem, because Fuel ran fine in the past. They two things are just not related at all. Marcus
thanks clement. Max this is a nice catch. Stef On Nov 25, 2013, at 1:13 PM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
In this version I added #timesRepeat: as a special selector to be inlined by the compiler (as #to:do:, #ifTrue:, ...). There was already another side effect of this addition of timesRepeat: as a special selector for XStreams. I guess we should remove it.
Try to edit the default Opal options in: OpalCompiler>>#defaultOptions
instead of: + optionInlineTimesRepeat put: - optionInlineTimesRepeat
Then execute: OpalCompiler recompileAll. (If you run your code with a DoIt you do not need to recompileAll, but just in case ...)
And see if you bug comes from the timesRepeat:.
Now the bytecode for "3 timesRepeat: [ Smalltalk garbageCollect ]" is correct. But there may be some side effect in the VM I am not thinking of.
29 <20> pushConstant: 3 30 <68> popIntoTemp: 0 31 <10> pushTemp: 0 32 <76> pushConstant: 1 33 <69> popIntoTemp: 1 34 <11> pushTemp: 1 35 <10> pushTemp: 0 36 <B4> send: <= 37 <AC 09> jumpFalse: 48 39 <41> pushLit: Smalltalk 40 <D2> send: garbageCollect 41 <87> pop 42 <11> pushTemp: 1 43 <76> pushConstant: 1 44 <B0> send: + 45 <69> popIntoTemp: 1 46 <A3 F2> jumpTo: 34 48 <7C> returnTop
2013/11/25 Max Leske <maxleske@gmail.com> I was able to isolate the image where the SegFault problem appears first: 30435. Hereâs the update method:
update30435 "self new update30435" self withUpdateLog: '11729 Sync Opa from repo: #timesRepeat optimization enabled https://pharo.fogbugz.com/f/cases/11729
11720 DateModel: Add #displayBlock: https://pharo.fogbugz.com/f/cases/11720
11727 remove unused ivar scrollBarOnLeft in ScrollPane https://pharo.fogbugz.com/f/cases/11727'. 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:
@Marcus Iâve put you into CC because I hope that you know more about #timesRepeat:
Cheers, Max
On 25.11.2013, at 08:26, Max Leske <maxleske@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@gmail.com> wrote:
On 07.11.2013, at 08:20, Max Leske <maxleske@gmail.com> wrote:
On 07.11.2013, at 00:27, vm-dev-request@lists.squeakfoundation.org wrote:
Date: Wed, 6 Nov 2013 19:23:47 -0200 From: Mariano Martinez Peck <marianopeck@gmail.com> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org> Message-ID: <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ@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@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
Nice catch Max!!! On Mon, Nov 25, 2013 at 7:58 AM, Max Leske <maxleske@gmail.com> wrote:
I was able to isolate the image where the SegFault problem appears first: 30435. Hereâs the update method:
update30435 "self new update30435" self withUpdateLog: '11729 Sync Opa from repo: #timesRepeat optimization enabled https://pharo.fogbugz.com/f/cases/11729 11720 DateModel: Add #displayBlock: https://pharo.fogbugz.com/f/cases/11720 11727 remove unused ivar scrollBarOnLeft in ScrollPane https://pharo.fogbugz.com/f/cases/11727'. 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:
@Marcus Iâve put you into CC because I hope that you know more about #timesRepeat:
Cheers, Max
On 25.11.2013, at 08:26, Max Leske <maxleske@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@gmail.com> wrote:
On 07.11.2013, at 08:20, Max Leske <maxleske@gmail.com> wrote:
On 07.11.2013, at 00:27, vm-dev-request@lists.squeakfoundation.org wrote:
Date: Wed, 6 Nov 2013 19:23:47 -0200 From: Mariano Martinez Peck <marianopeck@gmail.com> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 To: Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org> Message-ID: <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ@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@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
-- Mariano http://marianopeck.wordpress.com
participants (7)
-
Clément Bera -
Eliot Miranda -
Marcus Denker -
Mariano Martinez Peck -
Max Leske -
Stéphane Ducasse -
Sven Van Caekenberghe