Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient?
Process: Pharo [64892] Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: 5.0.201708271955 (5.0.201708271955) Code Type: X86-64 (Native) Parent Process: ??? [64888] Responsible: Pharo [64892] User ID: 501
Date/Time: 2018-03-19 20:27:03.906 +0100 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE
Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154
Time Awake Since Boot: 28000 seconds Time Since Wake: 6500 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x12b67c0b0: VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV --> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1
Application Specific Information: abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 5 ??? 000000000000000000 0 + 0 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific + 483 18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 20 com.apple.HIToolbox 0x00007fff2b872914 _BlockUntilNextEventMatchingListInModeWithFilter + 64 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run] + 764 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain + 804
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Hi Damien,
On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet damien.pollet@gmail.com wrote:
Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient?
Don't care. Anywhere it can be downloaded from. Also, try running with -leakcheck 15, preferably in an assert VM and see if that gets you additional information.
Process: Pharo [64892] Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: 5.0.201708271955 (5.0.201708271955) Code Type: X86-64 (Native) Parent Process: ??? [64888] Responsible: Pharo [64892] User ID: 501
Date/Time: 2018-03-19 20:27:03.906 +0100 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE
Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154
Time Awake Since Boot: 28000 seconds Time Since Wake: 6500 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x12b67c0b0: VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV --> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1
Application Specific Information: abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 5 ??? 000000000000000000 0 + 0 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific
- 483
18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 20 com.apple.HIToolbox 0x00007fff2b872914 _ BlockUntilNextEventMatchingListInModeWithFilter + 64 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
- 3044
23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run]
- 764
24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain + 804
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Here are the files (image and various outputs). Running with --leakcheck does mention a few object leaks (see output.txt); I'm not sure where to get or how to build an assert VM. I also realized the VM I had was from this summer (the one that comes with a 70 image with zeroconf). The output files I include were produced by the VM at get.pharo.org/64/vmLatest70
https://www.dropbox.com/s/y8yqjuzd9nsvy1u/clap-broken.tar.gz?dl=0
On 20 March 2018 at 18:17, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Damien,
On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet damien.pollet@gmail.com wrote:
Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient?
Don't care. Anywhere it can be downloaded from. Also, try running with -leakcheck 15, preferably in an assert VM and see if that gets you additional information.
Process: Pharo [64892] Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: 5.0.201708271955 (5.0.201708271955) Code Type: X86-64 (Native) Parent Process: ??? [64888] Responsible: Pharo [64892] User ID: 501
Date/Time: 2018-03-19 20:27:03.906 +0100 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE
Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154
Time Awake Since Boot: 28000 seconds Time Since Wake: 6500 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x12b67c0b0: VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV --> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1
Application Specific Information: abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 5 ??? 000000000000000000 0 + 0 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific + 483 18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 20 com.apple.HIToolbox 0x00007fff2b872914 _BlockUntilNextEventMatchingListInModeWithFilter + 64 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
- 3044
23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run] + 764 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain + 804
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
-- _,,,^..^,,,_ best, Eliot
Hi Damien,
On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet damien.pollet@gmail.com wrote:
Here are the files (image and various outputs). Running with --leakcheck does mention a few object leaks (see output.txt);
Indeed the image is corrupt at start-up. See below.
I'm not sure where to get or how to build an assert VM.
When you build a phar. VM under build.macos64x64/pharo.cog.spur using the mvm script (mvm -A) you produce an assert VM in PharoAssert.app.
I also realized the VM I had was from this summer (the one that comes with a 70 image with zeroconf). The output files I include were produced by the VM at get.pharo.org/64/vmLatest70
https://www.dropbox.com/s/y8yqjuzd9nsvy1u/clap-broken.tar.gz?dl=0
On 20 March 2018 at 18:17, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Damien,
On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet damien.pollet@gmail.com wrote:
Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient?
Don't care. Anywhere it can be downloaded from. Also, try running with -leakcheck 15, preferably in an assert VM and see if that gets you additional information.
Process: Pharo [64892] Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: 5.0.201708271955 (5.0.201708271955)
Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320:
Spur: Fix a bad bug in SpurPlnningCompactor. unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime.
Pharo urgently needs to upgrade the VM to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost.
Code Type: X86-64 (Native)
Parent Process: ??? [64888] Responsible: Pharo [64892] User ID: 501
Date/Time: 2018-03-19 20:27:03.906 +0100 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE
Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154
Time Awake Since Boot: 28000 seconds Time Since Wake: 6500 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x12b67c0b0: VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV --> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1
Application Specific Information: abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 5 ??? 000000000000000000 0 + 0 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific + 483 18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 20 com.apple.HIToolbox 0x00007fff2b872914 _BlockUntilNextEventMatchingListInModeWithFilter + 64 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
- 3044
23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run] + 764 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain
- 804
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
-- _,,,^..^,,,_ best, Eliot
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Hi Damien,
On Fri, Mar 23, 2018 at 1:52 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Damien,
On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet damien.pollet@gmail.com wrote:
Here are the files (image and various outputs). Running with --leakcheck does mention a few object leaks (see output.txt);
Indeed the image is corrupt at start-up. See below.
I'm not sure where to get or how to build an assert VM.
When you build a phar. VM under build.macos64x64/pharo.cog.spur using the mvm script (mvm -A) you produce an assert VM in PharoAssert.app.
Note that if you build an Assert VM you will be able to manually patch the image in lldb so that you can rescue it. It looks like this:
$ *lldb PharoAssert.app/Contents/MacOS/Pharo*
(lldb) target create "/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo" Current executable set to '/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64). (lldb) settings set -- target.run-args "clap_broken.d9e5daa.image" (lldb) *b warning* Breakpoint 1: 3 locations. (lldb) *run --leakcheck 31 clap_broken.d9e5daa.image* Process 31569 launched: '/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64) object leak in *0x10f919658* @ 0 = 0x122216538 object leak in *0x10fbb3448* @ 0 = 0x122216760 object leak in *0x10fbb3480* @ 0 = 0x1222166a8 object leak in *0x10ff384f0* @ 0 = 0x122d480b0 object leak in *0x10ff38518* @ 0 = 0x122d480b0 object leak in *0x10ff385d0* @ 0 = 0x122d480b0 Process 31569 stopped * thread #1: tid = 0x5b6d56, 0x0000000100001a83 Pharo`warning(s="checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100001a83 Pharo`warning(s="checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44 41 sqInt warnpid, erroronwarn; 42 void 43 warning(char *s) { /* Print an error message but don't necessarily exit. */ -> 44 if (erroronwarn) error(s); 45 if (warnpid) 46 printf("\n%s pid %ld\n", s, (long)warnpid); 47 else (lldb) *call storePointerUncheckedofObjectwithValue(0,0x10f919658,nilObj)* (sqInt) $0 = 4478138592 (lldb) *call storePointerUncheckedofObjectwithValue(0,0x10fbb3448,nilObj)* (sqInt) $1 = 4478138592 (lldb) *call storePointerUncheckedofObjectwithValue(0,0x10fbb3480,nilObj)* (sqInt) $2 = 4478138592 (lldb) *call storePointerUncheckedofObjectwithValue(0,0x10ff384f0,nilObj)* (sqInt) $3 = 4478138592 (lldb) *call storePointerUncheckedofObjectwithValue(0,0x10ff38518,nilObj)* (sqInt) $4 = 4478138592 (lldb) *call storePointerUncheckedofObjectwithValue(0,0x10ff385d0,nilObj)* (sqInt) $5 = 4478138592 (lldb) *expr checkForLeaks = 0* (sqInt) $0 = 0 (lldb) *c*
and then save the image.
I also realized the VM I had was from this summer (the one that comes with a 70 image with zeroconf). The output files I include were produced by the VM at get.pharo.org/64/vmLatest70
https://www.dropbox.com/s/y8yqjuzd9nsvy1u/clap-broken.tar.gz?dl=0
On 20 March 2018 at 18:17, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Damien,
On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet damien.pollet@gmail.com wrote:
Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient?
Don't care. Anywhere it can be downloaded from. Also, try running with -leakcheck 15, preferably in an assert VM and see if that gets you additional information.
Process: Pharo [64892] Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: 5.0.201708271955 (5.0.201708271955)
Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320:
Spur: Fix a bad bug in SpurPlnningCompactor. unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime.
Pharo urgently needs to upgrade the VM to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost.
Code Type: X86-64 (Native)
Parent Process: ??? [64888] Responsible: Pharo [64892] User ID: 501
Date/Time: 2018-03-19 20:27:03.906 +0100 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE
Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154
Time Awake Since Boot: 28000 seconds Time Since Wake: 6500 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x12b67c0b0: VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV --> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1
Application Specific Information: abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 5 ??? 000000000000000000 0 + 0 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific + 483 18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 20 com.apple.HIToolbox 0x00007fff2b872914 _BlockUntilNextEventMatchingListInModeWithFilter + 64 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
- 3044
23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run] + 764 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain
- 804
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
-- _,,,^..^,,,_ best, Eliot
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
-- _,,,^..^,,,_ best, Eliot
Hi,
I seem to be getting more of these errors recently. I'm on Mac Mojave 10.14.5, Pharo-7.0.3 64 bit, with the current stable vm (Mac OS X built on Jan 5 2019 19:11:02 ).
Running the leak checker returns some leaks:
(lldb) run --leakcheck 31 broken.image Process 3327 launched: '/Users/andrei/Documents/Pharo/images/pharo-vm/PharoAssert.app/Contents/MacOS/Pharo' (x86_64) leak in free chunk 0x17221e8b8 @ 0 = 0x17521e888 is unmapped leak in free chunk 0x17421e890 @ 0 = 0x17a21e830 is unmapped leak in free chunk 0x17521e888 @ 0 = 0x18021e7d8 is unmapped leak in free chunk 0x17a21e830 @ 0 = 0x187d3e278 is unmapped Process 3327 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100001230 Pharo`warning Pharo`warning: -> 0x100001230 <+0>: pushq %rbp 0x100001231 <+1>: movq %rsp, %rbp 0x100001234 <+4>: pushq %rbx 0x100001235 <+5>: pushq %rax Target 0: (Pharo) stopped.
The when using `storePointerUncheckedofObjectwithValue` I seem to get an error:
(lldb) call storePointerUncheckedofObjectwithValue(0,0x17221e8b8,nilObj) error: warning: got name from symbols: nilObj error: 'storePointerUncheckedofObjectwithValue' has unknown return type; cast the call to its declared return type
Is this a problem with the way I compiled the assert vm? And is there a way to explore how the leaked objects get created?
Cheers, Andrei
On Fri, Mar 23, 2018 at 11:02 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Damien,
On Fri, Mar 23, 2018 at 1:52 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Damien,
On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet damien.pollet@gmail.com wrote:
Here are the files (image and various outputs). Running with --leakcheck does mention a few object leaks (see output.txt);
Indeed the image is corrupt at start-up. See below.
I'm not sure where to get or how to build an assert VM.
When you build a phar. VM under build.macos64x64/pharo.cog.spur using the mvm script (mvm -A) you produce an assert VM in PharoAssert.app.
Note that if you build an Assert VM you will be able to manually patch the image in lldb so that you can rescue it. It looks like this:
$ lldb PharoAssert.app/Contents/MacOS/Pharo
(lldb) target create "/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo" Current executable set to '/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64). (lldb) settings set -- target.run-args "clap_broken.d9e5daa.image" (lldb) b warning Breakpoint 1: 3 locations. (lldb) run --leakcheck 31 clap_broken.d9e5daa.image Process 31569 launched: '/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64) object leak in 0x10f919658 @ 0 = 0x122216538 object leak in 0x10fbb3448 @ 0 = 0x122216760 object leak in 0x10fbb3480 @ 0 = 0x1222166a8 object leak in 0x10ff384f0 @ 0 = 0x122d480b0 object leak in 0x10ff38518 @ 0 = 0x122d480b0 object leak in 0x10ff385d0 @ 0 = 0x122d480b0 Process 31569 stopped
- thread #1: tid = 0x5b6d56, 0x0000000100001a83 Pharo`warning(s="checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100001a83 Pharo`warning(s="checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44 41 sqInt warnpid, erroronwarn; 42 void 43 warning(char *s) { /* Print an error message but don't necessarily exit. */
-> 44 if (erroronwarn) error(s); 45 if (warnpid) 46 printf("\n%s pid %ld\n", s, (long)warnpid); 47 else (lldb) call storePointerUncheckedofObjectwithValue(0,0x10f919658,nilObj) (sqInt) $0 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10fbb3448,nilObj) (sqInt) $1 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10fbb3480,nilObj) (sqInt) $2 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10ff384f0,nilObj) (sqInt) $3 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10ff38518,nilObj) (sqInt) $4 = 4478138592 (lldb) call storePointerUncheckedofObjectwithValue(0,0x10ff385d0,nilObj) (sqInt) $5 = 4478138592 (lldb) expr checkForLeaks = 0 (sqInt) $0 = 0 (lldb) c
and then save the image.
I also realized the VM I had was from this summer (the one that comes with a 70 image with zeroconf). The output files I include were produced by the VM at get.pharo.org/64/vmLatest70
https://www.dropbox.com/s/y8yqjuzd9nsvy1u/clap-broken.tar.gz?dl=0
On 20 March 2018 at 18:17, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Damien,
On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet damien.pollet@gmail.com wrote:
Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient?
Don't care. Anywhere it can be downloaded from. Also, try running with -leakcheck 15, preferably in an assert VM and see if that gets you additional information.
Process: Pharo [64892] Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: 5.0.201708271955 (5.0.201708271955)
Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320:
Spur: Fix a bad bug in SpurPlnningCompactor. unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime.
Pharo urgently needs to upgrade the VM to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost.
Code Type: X86-64 (Native) Parent Process: ??? [64888] Responsible: Pharo [64892] User ID: 501
Date/Time: 2018-03-19 20:27:03.906 +0100 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE
Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154
Time Awake Since Boot: 28000 seconds Time Since Wake: 6500 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x12b67c0b0: VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV --> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1
Application Specific Information: abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 5 ??? 000000000000000000 0 + 0 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific + 483 18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 20 com.apple.HIToolbox 0x00007fff2b872914 _BlockUntilNextEventMatchingListInModeWithFilter + 64 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run] + 764 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain + 804
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
-- _,,,^..^,,,_ best, Eliot
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
On 23 March 2018 at 21:52, Eliot Miranda eliot.miranda@gmail.com wrote:
Pharo urgently needs to upgrade the VM
I couldn't agree more, and I know Esteban wants to release a new VM. I did quite a bit of testing on a VM from 15 March that I thought would make a good candidate before realising that the Mac VMs aren't available.
to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost.
Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are triggered either by the automated test suite or the bootstrap process.
The blocks I can see at the moment are:
- Multiple builds have failed with an internal compiler error on the sista builds. -- The earliest occurrence I could find was commit 1f0a7da, but it may have been earlier. - Even if the Mac builds show success in travis, they aren't making it on to files.pharo.org. -- I haven't ever worked with this code.
Not directly related, but: - Bintray hasn't been updated since 8 March 2018.
I think it could also be useful for files.pharo.org to have release candidate links available, which would help people to focus testing on a particular VM. They would need to be manually maintained, but I think the benefits would be worthwhile.
Cheers, Alistair
Hi,
On 31 Mar 2018, at 11:45, Alistair Grant akgrant0710@gmail.com wrote:
On 23 March 2018 at 21:52, Eliot Miranda eliot.miranda@gmail.com wrote:
Pharo urgently needs to upgrade the VM
I couldn't agree more, and I know Esteban wants to release a new VM. I did quite a bit of testing on a VM from 15 March that I thought would make a good candidate before realising that the Mac VMs aren't available.
I will try to promote then the one of 15 march. We’ll see next week. but then, this is part of my observation: We cannot know which VMs are stable, and that’s because the *process* to make them stable is very “human dependent”: We consider a version stable when it builds on CI and Eliot says is stable. But since Eliot does not use Pharo (not a critic, a reality), that may be not true for Pharo. And that’s actually what happens, Pharo crashes. I tried to avoid a bit this problem with our fork and nightly builds that runs the pharo tests (to knew about problems as early as possible). But to be honest I didn’t have the time (and the will) to work on it recently, then pharo fork is in practice stalled. I will revive that eventually… but just when I find the time and the spirit to do it.
to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost.
Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are triggered either by the automated test suite or the bootstrap process.
The blocks I can see at the moment are:
- Multiple builds have failed with an internal compiler error on the
sista builds. -- The earliest occurrence I could find was commit 1f0a7da, but it may have been earlier.
- Even if the Mac builds show success in travis, they aren't making it
on to files.pharo.org.
latest VM copied into files.pharo.org http://files.pharo.org/ is 16/03. we need to see what’s happening there.
-- I haven't ever worked with this code.
Not directly related, but:
- Bintray hasn't been updated since 8 March 2018.
I think it could also be useful for files.pharo.org to have release candidate links available, which would help people to focus testing on a particular VM. They would need to be manually maintained, but I think the benefits would be worthwhile.
all VMs are available to test. just… not available *directly* to general users. now… I could have a 70rc link in vm subdir. But since I cannot know which VM is RC I find it pointless at this moment.
cheers, Esteban
Cheers, Alistair
On Sat, Mar 31, 2018 at 02:42:33PM +0200, Esteban Lorenzano wrote:
Hi,
On 31 Mar 2018, at 11:45, Alistair Grant <akgrant0710@gmail.com> wrote: On 23 March 2018 at 21:52, Eliot Miranda <eliot.miranda@gmail.com> wrote: Pharo urgently needs to upgrade the VM I couldn't agree more, and I know Esteban wants to release a new VM. I did quite a bit of testing on a VM from 15 March that I thought would make a good candidate before realising that the Mac VMs aren't available.I will try to promote then the one of 15 march. We?ll see next week.
There were a few builds on the 15th, the VMs I tested were:
http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-2018... http://files.pharo.org/vm/pharo-spur32/linux/pharo-linux-i386threaded-201803...
but then, this is part of my observation: We cannot know which VMs are stable, and that?s because the *process* to make them stable is very ?human dependent?: We consider a version stable when it builds on CI and Eliot says is stable. But since Eliot does not use Pharo (not a critic, a reality), that may be not true for Pharo. And that?s actually what happens, Pharo crashes. I tried to avoid a bit this problem with our fork and nightly builds that runs the pharo tests (to knew about problems as early as possible). But to be honest I didn?t have the time (and the will) to work on it recently, then pharo fork is in practice stalled. I will revive that eventually? but just when I find the time and the spirit to do it.
to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost. Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are triggered either by the automated test suite or the bootstrap process. The blocks I can see at the moment are: - Multiple builds have failed with an internal compiler error on the sista builds. -- The earliest occurrence I could find was commit 1f0a7da, but it may have been earlier. - Even if the Mac builds show success in travis, they aren't making it on to files.pharo.org.latest VM copied into files.pharo.org is 16/03. we need to see what?s happening there.
-- I haven't ever worked with this code. Not directly related, but: - Bintray hasn't been updated since 8 March 2018. I think it could also be useful for files.pharo.org to have release candidate links available, which would help people to focus testing on a particular VM. They would need to be manually maintained, but I think the benefits would be worthwhile.all VMs are available to test. just? not available *directly* to general users. now? I could have a 70rc link in vm subdir. But since I cannot know which VM is RC I find it pointless at this moment.
I didn't mean that we would always be looking to release a new version, but there have been multiple occassions in the past when you've asked people to try a particular VM to see if it solves a problem. In those instances, marking it as RC would make it simpler for others to contribute to the testing and give you more confidence to promote it to stable.
Actually, if the link existed all the time, but most of the time it was the same as the stable version, I'd probably just use it as my download link, which would mean that I'm testing the RC whenever it comes out, and stay with it while it is stable and there isn't a new RC.
Cheers, Alistair
vm-dev@lists.squeakfoundation.org
-
Alistair Grant -
Andrei Chis -
Damien Pollet -
Eliot Miranda -
Esteban Lorenzano