On Mon, Nov 23, 2015 at 4:57 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Eliot,
Is an assert vm the same as a vm compiled with debugging support?
VMMaker.oscog generates VM sources designed to be compiled in three different ways, Debug, Assert and Production. Debug is designed to enable asserts to check invariants and be compiled with no optimization for maximum debuggability. Assert is designed to enable asserts to check invariants and be compiled with limited optimization for faster assert checking. Production has asserts disabled (actually compiled-out) and be compiled with aggressive optimization, so it has limited debuggability (it should still contain debugging symbols).
So Assert and Debug are not quite the same and certainly if you're hunting for storage leaks an Assert VM will run much faster than a Debug VM. If you have a look at the Cog svn sources you'll find that the build scripts build all three kinds of VMs for all platforms.
Also can you point me to any documentation about the leak checker.
It's not well documented because it may change over time, but the -help flag on the VM should include this:
-leakcheck num check for leaks in the heap
and the meaning of num is a set of flags:
setCheckForLeaks: integerFlags " 0 = do nothing. 1 = check for leaks on fullGC (GCModeFull). 2 = check for leaks on scavenger (GCModeNewSpace). 4 = check for leaks on incremental (GCModeIncremental) 8 = check for leaks on become 16 = check for leaks on image segments" checkForLeaks := integerFlags
So once you have your assert VM try running your test case using
myvm -leakcheck 5 myimage.image
on the command line. You'll want to use a debugger to put breakpoints in the leak checker and you may need to learn about the VM's debug routines to try and figure out the cause of the leak once the leak checker finds it.
Cheers, Andrei
On Nov 24, 2015 1:45 AM, "Eliot Miranda" eliot.miranda@gmail.com wrote:
Hi Andrei,
On Mon, Nov 23, 2015 at 7:59 AM, Andrei Chis chisvasileandrei@gmail.com
wrote:
Hi,
With both the latest and stable vm I have an use case in which the vm
crashed in SmalltalkImage>>garbageCollect.
To set up an image that exhibits the failure , execute this with the
latest pharo version:
/pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'.
'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]."
./pharo Pharo.image config
http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore --install=3.2
Then attempting to run the following code triggers the failure:
./pharo Pharo.image eval --save "TestRunner open model
packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll"
Based on the trace below the failure happens when the
test GTInspectorExamplesTest calls 'Smalltalk>>garbageCollect' in the setUp method.
That call can be removed, however, in other runs the failure happens
in other methods calling Smalltalk>>garbageCollect.
Is it possible that this is a bug with the image (some broken object)
or is it a vm bug?
The way to test this is to build an assert VM and then use the leak
checker. The leak checker will allow you to narrow down the cause. If the leak checker shows no corruption then its definitely a GC bug. If there leak checker does show corruption before GC then one still has to find out what caused the heap corruption, but you can use the leak checker to narrow the search.
HTH Eliot
Cheers,
Andrei
andrei$ ./pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'.
'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]."
andrei$ ./pharo Pharo.image config
http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore --install=3.2
andrei$ ./pharo Pharo.image eval --save "TestRunner open model
packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll"
Segmentation fault Mon Nov 23 16:48:36 2015
28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 By: Esteban Lorenzano estebanlm@gmail.com Jenkins build #15016
C stack backtrace:
0 Pharo 0x0004cacf reportStackState +
159
Smalltalk stack dump:
0xbffbf1a0 M SmalltalkImage>garbageCollect 0x1fd49e30: a(n)
SmalltalkImage
0xbffbf1c0 I GTInspectorExamplesTest>setUp 0x2126bc80: a(n)
GTInspectorExamplesTest
0x2126cb90 is not a context
Most recent primitives
@
basicNew
@
@
@
@
@
@
@
@
@
basicNew
basicNew
basicNew
@
@
@
@
shallowCopy
new
new:
new:
basicNew
basicNew
new:
basicNew
new:
replaceFrom:to:with:startingAt:
new:
basicNew
new:
replaceFrom:to:with:startingAt:
new:
basicNew
@
new:
at:put:
at:put:
perform:with:
perform:with:
perform:
@
@
basicNew
@
@
@
@
@
@
basicNew
@
new:
at:put:
at:put:
perform:with:
perform:with:
perform:
@
@
basicNew
@
@
@
@
@
@
new
@
@
@
@
@
basicNew
@
@
new:
at:put:
@
@
basicNew
@
@
@
@
new:
at:put:
at:put:
at:put:
at:put:
new:
@
at:put:
@
at:put:
@
at:put:
@
at:put:
@
@
@
@
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
@
shallowCopy
shallowCopy
@
@
new:
at:put:
at:put:
at:put:
at:put:
new:
@
at:put:
@
at:put:
@
at:put:
@
at:put:
@
@
@
@
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
@
basicNew
@
@
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
@
basicNew
@
@
@
@
basicNew
@
@
perform:
basicNew
new:
basicNew
new:
basicNew
new:
shallowCopy
shallowCopy
primUTCMicrosecondsClock
//
basicNew
basicNew
new:
at:put:
at:put:
at:put:
at:put:
value
valueNoContextSwitch
basicNew
new:
basicNew
new:
new:
basicNew
new:
replaceFrom:to:with:startingAt:
primitiveGarbageCollect
**IncrementalGC**
**FullGC**
garbageCollectMost
**IncrementalGC**
basicNew
new:
someInstance
basicNew
new:
someInstance
basicNew
new:
someInstance
new:
basicNew
new:
replaceFrom:to:with:startingAt:
primitiveGarbageCollect
**IncrementalGC**
**FullGC**
garbageCollectMost
**IncrementalGC**
wait
shallowCopy
shallowCopy
signal
wait
shallowCopy
shallowCopy
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
signal
wait
shallowCopy
shallowCopy
at:put:
at:put:
signal
new:
basicNew
new:
replaceFrom:to:with:startingAt:
primitiveGarbageCollect
**IncrementalGC**
**FullGC**
(Segmentation fault)
./pharo: line 11: 5224 Abort trap: 6
"$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@"
-- _,,,^..^,,,_ best, Eliot
Hi,
I discovered a similar issue described in this issue https://pharo.fogbugz.com/f/cases/14165/ObsoleteTest-testFixObsoleteSharedPo.... Might be related.
Cheers, Max
On 24 Nov 2015, at 19:34, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Nov 23, 2015 at 4:57 PM, Andrei Chis <chisvasileandrei@gmail.com mailto:chisvasileandrei@gmail.com> wrote: Hi Eliot,
Is an assert vm the same as a vm compiled with debugging support?
VMMaker.oscog generates VM sources designed to be compiled in three different ways, Debug, Assert and Production. Debug is designed to enable asserts to check invariants and be compiled with no optimization for maximum debuggability. Assert is designed to enable asserts to check invariants and be compiled with limited optimization for faster assert checking. Production has asserts disabled (actually compiled-out) and be compiled with aggressive optimization, so it has limited debuggability (it should still contain debugging symbols).
So Assert and Debug are not quite the same and certainly if you're hunting for storage leaks an Assert VM will run much faster than a Debug VM. If you have a look at the Cog svn sources you'll find that the build scripts build all three kinds of VMs for all platforms.
Also can you point me to any documentation about the leak checker.
It's not well documented because it may change over time, but the -help flag on the VM should include this:
-leakcheck num check for leaks in the heap
and the meaning of num is a set of flags:
setCheckForLeaks: integerFlags " 0 = do nothing. 1 = check for leaks on fullGC (GCModeFull). 2 = check for leaks on scavenger (GCModeNewSpace). 4 = check for leaks on incremental (GCModeIncremental) 8 = check for leaks on become 16 = check for leaks on image segments" checkForLeaks := integerFlags
So once you have your assert VM try running your test case using
myvm -leakcheck 5 myimage.image
on the command line. You'll want to use a debugger to put breakpoints in the leak checker and you may need to learn about the VM's debug routines to try and figure out the cause of the leak once the leak checker finds it. Cheers, Andrei
On Nov 24, 2015 1:45 AM, "Eliot Miranda" <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com> wrote:
Hi Andrei,
On Mon, Nov 23, 2015 at 7:59 AM, Andrei Chis <chisvasileandrei@gmail.com mailto:chisvasileandrei@gmail.com> wrote:
Hi,
With both the latest and stable vm I have an use case in which the vm crashed in SmalltalkImage>>garbageCollect.
To set up an image that exhibits the failure , execute this with the latest pharo version:
/pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]."
./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore --install=3.2
Then attempting to run the following code triggers the failure:
./pharo Pharo.image eval --save "TestRunner open model packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll"
Based on the trace below the failure happens when the test GTInspectorExamplesTest calls 'Smalltalk>>garbageCollect' in the setUp method.
That call can be removed, however, in other runs the failure happens in other methods calling Smalltalk>>garbageCollect.
Is it possible that this is a bug with the image (some broken object) or is it a vm bug?
The way to test this is to build an assert VM and then use the leak checker. The leak checker will allow you to narrow down the cause. If the leak checker shows no corruption then its definitely a GC bug. If there leak checker does show corruption before GC then one still has to find out what caused the heap corruption, but you can use the leak checker to narrow the search.
HTH Eliot
Cheers,
Andrei
andrei$ ./pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]."
andrei$ ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore --install=3.2
andrei$ ./pharo Pharo.image eval --save "TestRunner open model packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll"
Segmentation fault Mon Nov 23 16:48:36 2015
https://github.com/pharo-project/pharo-vm.git https://github.com/pharo-project/pharo-vm.git Commit: 28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 By: Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> Jenkins build #15016
C stack backtrace:
0 Pharo 0x0004cacf reportStackState + 159
Smalltalk stack dump:
0xbffbf1a0 M SmalltalkImage>garbageCollect 0x1fd49e30: a(n) SmalltalkImage
0xbffbf1c0 I GTInspectorExamplesTest>setUp 0x2126bc80: a(n) GTInspectorExamplesTest
0x2126cb90 is not a context
Most recent primitives
@
basicNew
@
@
@
@
@
@
@
@
@
basicNew
basicNew
basicNew
@
@
@
@
shallowCopy
new
new:
new:
basicNew
basicNew
new:
basicNew
new:
replaceFrom:to:with:startingAt:
new:
basicNew
new:
replaceFrom:to:with:startingAt:
new:
basicNew
@
new:
at:put:
at:put:
perform:with:
perform:with:
perform:
@
@
basicNew
@
@
@
@
@
@
basicNew
@
new:
at:put:
at:put:
perform:with:
perform:with:
perform:
@
@
basicNew
@
@
@
@
@
@
new
@
@
@
@
@
basicNew
@
@
new:
at:put:
@
@
basicNew
@
@
@
@
new:
at:put:
at:put:
at:put:
at:put:
new:
@
at:put:
@
at:put:
@
at:put:
@
at:put:
@
@
@
@
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
@
shallowCopy
shallowCopy
@
@
new:
at:put:
at:put:
at:put:
at:put:
new:
@
at:put:
@
at:put:
@
at:put:
@
at:put:
@
@
@
@
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
@
basicNew
@
@
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
@
basicNew
@
@
@
@
basicNew
@
@
perform:
basicNew
new:
basicNew
new:
basicNew
new:
shallowCopy
shallowCopy
primUTCMicrosecondsClock
//
basicNew
basicNew
new:
at:put:
at:put:
at:put:
at:put:
value
valueNoContextSwitch
basicNew
new:
basicNew
new:
new:
basicNew
new:
replaceFrom:to:with:startingAt:
primitiveGarbageCollect
**IncrementalGC**
**FullGC**
garbageCollectMost
**IncrementalGC**
basicNew
new:
someInstance
basicNew
new:
someInstance
basicNew
new:
someInstance
new:
basicNew
new:
replaceFrom:to:with:startingAt:
primitiveGarbageCollect
**IncrementalGC**
**FullGC**
garbageCollectMost
**IncrementalGC**
wait
shallowCopy
shallowCopy
signal
wait
shallowCopy
shallowCopy
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
signal
wait
shallowCopy
shallowCopy
at:put:
at:put:
signal
new:
basicNew
new:
replaceFrom:to:with:startingAt:
primitiveGarbageCollect
**IncrementalGC**
**FullGC**
(Segmentation fault)
./pharo: line 11: 5224 Abort trap: 6 "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@"
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
Indeed it seems related. Unfortunately neither Andrei or me could find the reason. We did what Eliot suggested us with leaks but we found none. At least right now we have 2 different ways of reproducing the crash (if it is the same bug).
On Thu, Dec 3, 2015 at 7:50 AM, Max Leske maxleske@gmail.com wrote:
Hi,
I discovered a similar issue described in this issue https://pharo.fogbugz.com/f/cases/14165/ObsoleteTest-testFixObsoleteSharedPo.... Might be related.
Cheers, Max
On 24 Nov 2015, at 19:34, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Nov 23, 2015 at 4:57 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
Hi Eliot,
Is an assert vm the same as a vm compiled with debugging support?
VMMaker.oscog generates VM sources designed to be compiled in three different ways, Debug, Assert and Production. Debug is designed to enable asserts to check invariants and be compiled with no optimization for maximum debuggability. Assert is designed to enable asserts to check invariants and be compiled with limited optimization for faster assert checking. Production has asserts disabled (actually compiled-out) and be compiled with aggressive optimization, so it has limited debuggability (it should still contain debugging symbols).
So Assert and Debug are not quite the same and certainly if you're hunting for storage leaks an Assert VM will run much faster than a Debug VM. If you have a look at the Cog svn sources you'll find that the build scripts build all three kinds of VMs for all platforms.
Also can you point me to any documentation about the leak checker.
It's not well documented because it may change over time, but the -help flag on the VM should include this:
-leakcheck num check for leaks in the heap
and the meaning of num is a set of flags:
setCheckForLeaks: integerFlags " 0 = do nothing. 1 = check for leaks on fullGC (GCModeFull). 2 = check for leaks on scavenger (GCModeNewSpace). 4 = check for leaks on incremental (GCModeIncremental) 8 = check for leaks on become 16 = check for leaks on image segments" checkForLeaks := integerFlags
So once you have your assert VM try running your test case using
myvm -leakcheck 5 myimage.image
on the command line. You'll want to use a debugger to put breakpoints in the leak checker and you may need to learn about the VM's debug routines to try and figure out the cause of the leak once the leak checker finds it.
Cheers, Andrei
On Nov 24, 2015 1:45 AM, "Eliot Miranda" eliot.miranda@gmail.com wrote:
Hi Andrei,
On Mon, Nov 23, 2015 at 7:59 AM, Andrei Chis <
chisvasileandrei@gmail.com> wrote:
Hi,
With both the latest and stable vm I have an use case in which the vm
crashed in SmalltalkImage>>garbageCollect.
To set up an image that exhibits the failure , execute this with the
latest pharo version:
/pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'.
'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]."
./pharo Pharo.image config
http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore --install=3.2
Then attempting to run the following code triggers the failure:
./pharo Pharo.image eval --save "TestRunner open model
packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll"
Based on the trace below the failure happens when the
test GTInspectorExamplesTest calls 'Smalltalk>>garbageCollect' in the setUp method.
That call can be removed, however, in other runs the failure happens
in other methods calling Smalltalk>>garbageCollect.
Is it possible that this is a bug with the image (some broken object)
or is it a vm bug?
The way to test this is to build an assert VM and then use the leak
checker. The leak checker will allow you to narrow down the cause. If the leak checker shows no corruption then its definitely a GC bug. If there leak checker does show corruption before GC then one still has to find out what caused the heap corruption, but you can use the leak checker to narrow the search.
HTH Eliot
Cheers,
Andrei
andrei$ ./pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'.
'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer new smalltalkhubUser: spec second project: spec third; package: spec first; load ]."
andrei$ ./pharo Pharo.image config
http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main ConfigurationOfGToolkitCore --install=3.2
andrei$ ./pharo Pharo.image eval --save "TestRunner open model
packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: 'GTInspectorExamplesTest'; runAll"
Segmentation fault Mon Nov 23 16:48:36 2015
28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 By: Esteban Lorenzano estebanlm@gmail.com Jenkins build #15016
C stack backtrace:
0 Pharo 0x0004cacf reportStackState +
159
Smalltalk stack dump:
0xbffbf1a0 M SmalltalkImage>garbageCollect 0x1fd49e30: a(n)
SmalltalkImage
0xbffbf1c0 I GTInspectorExamplesTest>setUp 0x2126bc80: a(n)
GTInspectorExamplesTest
0x2126cb90 is not a context
Most recent primitives
@
basicNew
@
@
@
@
@
@
@
@
@
basicNew
basicNew
basicNew
@
@
@
@
shallowCopy
new
new:
new:
basicNew
basicNew
new:
basicNew
new:
replaceFrom:to:with:startingAt:
new:
basicNew
new:
replaceFrom:to:with:startingAt:
new:
basicNew
@
new:
at:put:
at:put:
perform:with:
perform:with:
perform:
@
@
basicNew
@
@
@
@
@
@
basicNew
@
new:
at:put:
at:put:
perform:with:
perform:with:
perform:
@
@
basicNew
@
@
@
@
@
@
new
@
@
@
@
@
basicNew
@
@
new:
at:put:
@
@
basicNew
@
@
@
@
new:
at:put:
at:put:
at:put:
at:put:
new:
@
at:put:
@
at:put:
@
at:put:
@
at:put:
@
@
@
@
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
@
shallowCopy
shallowCopy
@
@
new:
at:put:
at:put:
at:put:
at:put:
new:
@
at:put:
@
at:put:
@
at:put:
@
at:put:
@
@
@
@
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
@
basicNew
@
@
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
@
@
@
@
basicNew
@
@
@
@
basicNew
@
@
perform:
basicNew
new:
basicNew
new:
basicNew
new:
shallowCopy
shallowCopy
primUTCMicrosecondsClock
//
basicNew
basicNew
new:
at:put:
at:put:
at:put:
at:put:
value
valueNoContextSwitch
basicNew
new:
basicNew
new:
new:
basicNew
new:
replaceFrom:to:with:startingAt:
primitiveGarbageCollect
**IncrementalGC**
**FullGC**
garbageCollectMost
**IncrementalGC**
basicNew
new:
someInstance
basicNew
new:
someInstance
basicNew
new:
someInstance
new:
basicNew
new:
replaceFrom:to:with:startingAt:
primitiveGarbageCollect
**IncrementalGC**
**FullGC**
garbageCollectMost
**IncrementalGC**
wait
shallowCopy
shallowCopy
signal
wait
shallowCopy
shallowCopy
at:put:
at:put:
at:put:
at:put:
at:put:
at:put:
signal
wait
shallowCopy
shallowCopy
at:put:
at:put:
signal
new:
basicNew
new:
replaceFrom:to:with:startingAt:
primitiveGarbageCollect
**IncrementalGC**
**FullGC**
(Segmentation fault)
./pharo: line 11: 5224 Abort trap: 6
"$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@"
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org