March 2018 - Pharo-dev - lists.pharo.org

Slot Questions

by Sean P. DeNigris

Stateful traits inspired me to reread the flexible object layout paper and I came up with a few questions about slots: - What is the plan for tool support? For example, it seems that to make slots discoverable like any other class or message, "References to it" should include class definitions, which should be the primary slot client. - Why does IndexedSlot have a #name slot? I thought the index and name were "either or" for instVars. Thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 24, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Eliot Miranda

Hi Holger, > On Mar 24, 2018, at 10:03 AM, Holger Freyther <holger(a)freyther.de> wrote: > > > >> On 24. Mar 2018, at 16:42, Holger Freyther <holger(a)freyther.de> wrote: >> >> >> >> 1.) FT2Handle class>>#startUp: isn't called. Which means FreeTypeFace>>#beNull has not been called yet! >> > > > >> I think implementing: >> >> FreeTypeExternalMemory class >> #bytes: aByteArray >> ^(aByteArray copy) >> pin; >> yourself >> >> could solve most of it? (We can argue about the copy...) > > It doesn't because most of FT2Plugin expects the "handle" it invented. But if we look at it... > > FreeTypeFace>validate > SmalltalkImage>session > SessionManager class>default > SessionManager>currentSession > SmalltalkImage>session > FreeTypeFace>create > FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: > FreeTypeExternalMemory>validate > FreeTypeExternalMemory(FT2Handle)>isValid > > FreeTypeFace>>#validate already does: > > (session == Smalltalk session > ... > > > And this is why FreeTypeFace>>#create is being called and that will call validate on the FreeTypeExternalMemory instance... > > > FreeTypeExternalMemory>validate just checks if the handle isValid but remember 1st from my previous mail. We have not _yet_ cleared the FT2Handle SubInstances.. So the memory is all good. > > > So back to the ideas. > > a.) Make sure FT2Handler class>>#startUp runs a lot earlier > b.) Find out which UI thing uses freetype earlier (but FreeType can be used in non GUI apps. E.g. to draw text to an image...) > c.) Keep the session in FreeTypeExternalMemory as well and use it in >>#validate.. (not relying on the startUp order) > d.) Re-write FreeType with Alien and just use the Plugin to conveniently link/load to freetype.. I wonder if there is sense in trying to come up with a general memory handle object that includes a session identifier, so that attempts to free stake memory always fail. > holger

March 24, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Holger Freyther

> On 24. Mar 2018, at 16:42, Holger Freyther <holger(a)freyther.de> wrote: > > > > 1.) FT2Handle class>>#startUp: isn't called. Which means FreeTypeFace>>#beNull has not been called yet! > > I think implementing: > > FreeTypeExternalMemory class >> #bytes: aByteArray > ^(aByteArray copy) > pin; > yourself > > could solve most of it? (We can argue about the copy...) It doesn't because most of FT2Plugin expects the "handle" it invented. But if we look at it... FreeTypeFace>validate SmalltalkImage>session SessionManager class>default SessionManager>currentSession SmalltalkImage>session FreeTypeFace>create FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: FreeTypeExternalMemory>validate FreeTypeExternalMemory(FT2Handle)>isValid FreeTypeFace>>#validate already does: (session == Smalltalk session ... And this is why FreeTypeFace>>#create is being called and that will call validate on the FreeTypeExternalMemory instance... FreeTypeExternalMemory>validate just checks if the handle isValid but remember 1st from my previous mail. We have not _yet_ cleared the FT2Handle SubInstances.. So the memory is all good. So back to the ideas. a.) Make sure FT2Handler class>>#startUp runs a lot earlier b.) Find out which UI thing uses freetype earlier (but FreeType can be used in non GUI apps. E.g. to draw text to an image...) c.) Keep the session in FreeTypeExternalMemory as well and use it in >>#validate.. (not relying on the startUp order) d.) Re-write FreeType with Alien and just use the Plugin to conveniently link/load to freetype.. holger

March 24, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Holger Freyther

> On 21. Oct 2017, at 20:30, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hey! > Thanks thomas we should find the problem. > my CI started to suffer from this too (and I have one where it is broken and now one where I can reproduce it). I started the macOS VM with --trace[1] and have the attached the trace. What is note-worthy: 1.) FT2Handle class>>#startUp: isn't called. Which means FreeTypeFace>>#beNull has not been called yet! (GlobalIdentifier, Delay, DelaySpinScheduler, ProcessorScheduler seem to have went through >>#startUp:) 2.) No one calls >>#fileContentsExternalMemory: 3.) We touch old memory and crash! FreeTypeGlyphRenderer class>current FreeTypeSubPixelAntiAliasedGlyphRenderer>subGlyphOf:colorValue:mono:subpixelPosition:font: FreeTypeSubPixelAntiAliasedGlyphRenderer>renderStretchedGlyph:depth:subpixelPosition:font: ... FreeTypeFont>face FreeTypeFace>validate SmalltalkImage>session SessionManager class>default SessionManager>currentSession SmalltalkImage>session FreeTypeFace>create FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: I don't know what the actions should be? * Don't touch anything with fonts in the start-up path? * Run FT2Handle class >> #startUp earlier? * Pass the ByteArray to FreeTypeFace and let it pin it to memory? I think FreeTypeExternalMemory could go away with Spur? * Reset FreeTypeFace instVar fileContentsExternalMemory in >>#beNull? * Throw away all FreeTypeFace when we have a new Session? I think implementing: FreeTypeExternalMemory class >> #bytes: aByteArray ^(aByteArray copy) pin; yourself could solve most of it? (We can argue about the copy...) holger [1] Well it is broken as VMOPTIONOBJ adds the "-" to the front but all code that is using numbers do not handle the extra digit in sqSqueakOSXApplication.m. Maybe somebody beats me with a PR for it. ;)

March 24, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Esteban Lorenzano

hi, > On 24 Mar 2018, at 09:50, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 23/03/2018 Ã 21:52, Eliot Miranda a Ã©crit : >> Hi Damien, >> >> Indeed the image is corrupt at start-up. See below. >> >> >> 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. >> > > Hi Eliot, > > I think that there is a lot of people who would like to get a newer > stable vm for Pharo 6.1 and 7. The problem is that it is hard to know > which VM are stable enough to be promoted as stable. > > Some weeks ago Esteban tried to promote a VM as stable and he had to > revert it the same day because a regression occurred in the VM. > > If you're able to tell us which vms are stable in those present at > http://files.pharo.org/vm/pharo-spur32/ and > http://files.pharo.org/vm/pharo-spur64/ it would be a great help. > > Even better would be for the pharo community to have a way to know which > vms are stable or not without having to ask you. there is no âstableâ branch in Cog, and thatâs a problem. âreleasedâ versions (the version you can find as stable) are not working for Pharo :( I tried to promote versions from end feb and that crashed. next week I will try again, maybe now they are stable enoughâ¦ one thing is true: the versions that we consider stable (from oct/17) present problems that are already solved on latest. Esteban > > Have a nice day. > >> >> -- >> _,,,^..^,,,_ >> best, Eliot > -- > Cyril Ferlicot > https://ferlicot.fr >

March 24, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Cyril Ferlicot D.

Le 23/03/2018 Ã 21:52, Eliot Miranda a Ã©critÂ : > Hi Damien, > > Indeed the image is corrupt at start-up.Â See below. > Â > > 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. > Â Hi Eliot, I think that there is a lot of people who would like to get a newer stable vm for Pharo 6.1 and 7. The problem is that it is hard to know which VM are stable enough to be promoted as stable. Some weeks ago Esteban tried to promote a VM as stable and he had to revert it the same day because a regression occurred in the VM. If you're able to tell us which vms are stable in those present at http://files.pharo.org/vm/pharo-spur32/ and http://files.pharo.org/vm/pharo-spur64/ it would be a great help. Even better would be for the pharo community to have a way to know which vms are stable or not without having to ask you. Have a nice day. > > -- > _,,,^..^,,,_ > best,Â Eliot -- Cyril Ferlicot https://ferlicot.fr

March 24, 2018

Re: [Pharo-dev] pharo64+load code=broken image

by Eliot Miranda

On Fri, Mar 23, 2018 at 7:54 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > Hi Eliot, the crash.dmp shows what I put in the first mail, gdb shows some > more info: > > #0 __GI___libc_free (mem=0x7f15fc1d15d0) at malloc.c:2965 > #1 0x00000000004c745b in primitiveFFIFree () at /home/travis/build/ > OpenSmalltalk/opensmalltalk-vm/src/plugins/SqueakFFIPrims/ > X64SysVFFIPlugin.c:6352 > #2 0x0000000000457f64 in primitiveExternalCall () at /home/travis/build/ > OpenSmalltalk/opensmalltalk-vm/spur64src/vm/gcc3x-cointerp.c:75751 > #3 0x00000000004595cb in interpretMethodFromMachineCode () at > /home/travis/build/OpenSmalltalk/opensmalltalk-vm/spur64src/vm/gcc3x- > cointerp.c:18524 > #4 0x000000000045bc69 in ceSendsupertonumArgs (selector=<optimized out>, > superNormalBar=0, rcvr=<optimized out>, numArgs=0) > at /home/travis/build/OpenSmalltalk/opensmalltalk- > vm/spur64src/vm/gcc3x-cointerp.c:16602 > #5 0x00000000009000bb in ?? () > #6 0x00007fffffffdbc0 in ?? () > #7 0x000000000045ce56 in interpret () at /home/travis/build/ > OpenSmalltalk/opensmalltalk-vm/spur64src/vm/gcc3x-cointerp.c:2731 > #8 0x00000000009ccf7f in ?? () > #9 0x00000000045e39c8 in ?? () > #10 0x00000000045e39c8 in ?? () > ... > > As it is just loading, I think that it is trying to free some memory that > was allocated before the image was saved. Looks like there is an external > address that should have been niled but for some reason wasn't. > I can take a look at the image in the simulator and/or debugger and see if any stale pointers exist. Put the image and changes somewhere where I can download them. > > On Fri, Mar 23, 2018 at 11:43 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Javier, >> >> what does the crash.dmp file say? Or what does a gdb stacktrace say? >> >> _,,,^..^,,,_ (phone) >> >> On Mar 23, 2018, at 7:18 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> >> wrote: >> >> no luck with this one :( >> >> On Fri, Mar 23, 2018 at 4:48 AM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >> >>> Hi Javier, >>> >>> On 23 March 2018 at 04:54, Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>> wrote: >>> > Hi folks, I take a fresh Pharo6.1 (spur64), load a git repository and >>> save >>> > the image. When reopening I get a segmentation fault. OS is ubuntu >>> 17.04/64 >>> > bits. I just cannot make it work, tried with all the vms I could >>> (vmI61, >>> > vmT61, vmLatest70, vmTLatest70). I suspect it is related to using git >>> but >>> > I'm not even sure. >>> > >>> > Below I put the involved code, crash dump at the end (seems to be the >>> same >>> > with any vm). btw, the vmILatest70 script does not seem to work (curl >>> > https://get.pharo.org/64/vmILatest70 | bash). >>> > >>> > Any ideas? >>> >>> I'm using the following VM on Ubuntu 16.04 without any issues: >>> >>> http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86 >>> _64threaded-201803160215-43a2f5c.zip >>> >>> >>> HTH, >>> Alistair >>> >>> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > -- _,,,^..^,,,_ best, Eliot

March 24, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Eliot Miranda

Hi Damien, On Fri, Mar 23, 2018 at 1:52 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Damien, > > On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet <damien.pollet(a)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(a)gmail.com> wrote: >> >>> >>> Hi Damien, >>> >>> On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet <damien.pollet(a)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

March 23, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Eliot Miranda

Hi Damien, On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet <damien.pollet(a)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(a)gmail.com> wrote: > >> >> Hi Damien, >> >> On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet <damien.pollet(a)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

March 23, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Ben Coman

On 23 March 2018 at 11:31, Ben Coman <btc(a)openinworld.com> wrote: > > > On 23 March 2018 at 05:14, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > >> Hi, >> >> I just saw students and they still have some problem on windows with the >> launcher. >> >> First, the launcher has to be run in admin mode. >> >> Then, the image download starts but there is an error when uncompressing. >> Here is the stack. >> >> Any idea on how to fix that ? >> > > Now I notice... > the Linux PharoLauncher download is a ZIP file > and the Mac PharoLauncher download is a ZIP file > so... can we make the Windows PharoLauncher download a ZIP file? > > Doing that, at least as an interim measure, would *immediately* make > PharoLauncher > usable to students on locked-down Windows machines in University student > labs. > I'd expect this will improve the success with this experiment > to use PharoLauncher as the main user entry point. > > The problem with using an "Installer" for the Windows PharoLauncher is the > large amount > of testing required to work *reliably* with *all* the "different ways > people work" > under several different versions of Windows introduced different layers of > user security intricacies. > Lets move forward in small steps. A ZIP download/extract is simple, and > consistent with other platforms. > > In the meantime while waiting for that to happen, you can... > > 1. Download/extract http://files.pharo.org/platform/Pharo6.1-win.zip > > 2. Rename Pharo6.1 folder to PharoLauncher > Rename Pharo6.1.* files to PharoLauncher1.1.* > > 3. Metacello new > smalltalkhubUser: 'Pharo' > project: 'PharoLauncher'; > configuration: 'PharoLauncher'; > load. > PhLDeploymentScript doAll. > PharoLauncher open. > Smalltalk snapshot: true andQuit: true. > > 4. Zip up the parent folder, test on another machine and provide a link to > your students. > > cheers -ben > > > P.S. I was going to suggest also renaming Pharo.exe to > PharoLauncher.exe > but with an empty Documents\Pharo\vms > I get... "Error: Cannot detect Pharo executable in > C:\Temp\MyPharoLauncher\PharoLauncher" > in PhLVirtualMachine>>initializeOn: "File @ C:\Temp\MyPharoLauncher\PharoL > auncher" > since "executables := aFolder allChildrenMatching: self class > executableName." > is empty since "self class executableName" ==> "Pharo.exe" > > It would be nice for that to not be hard coded. I tried digging further > but ran out of time. > I am curious it mattered since using "Pharo.exe" the Launcher went on to > download a VM anyway. > > > P.S.2. > I believe the best path forward for system-wide PharoLauncher installed > under "C:\Program Files" > would be to install there only... > * the VM > * PharoLauncher.ZIP > * a tiny non-Pharo wrapper program as the shortcut linked from AllUsers > > Start Menu > PharoLauncher > that extracts PharoLauncher.ZIP to the user's data area and then starts > that user specific PharoLauncher. > > Then regardless whether: > * they individually download/extract PharoLauncher.ZIP > * the system-wide-wrapper extracts PharoLauncher.ZIP > its a similar experience for users which should aid reliability by > reducing the number of "different " use cases. > Coincidentally I have returned to Windows for a short while so thought I should put my money where my mouth is and have a stab at this. After a few hours trying with NSIS, I went searching for an alternative and Advanced Installer looked like a good chance. https://www.advancedinstaller.com/feats-list.html The important part of (free) Basic Features is "Windows 10/8/7/Vista and UAC installs" Also further down are some CI options. After just the "Simple Installation" tutorial and experimenting a few hours I ironed out a potential solution uploaded for testing to http://www.mediafire.com/file/3g579bmzqspt8e1/BCPharoLauncher.msi with the full build tree at http://www.mediafire.com/file/5ijiww848lbkk7m/PharoLauncher%20Advanced%20In… Links should be live for 30 days. I've directly attached the much smaller installer-configuration file "PharoLauncher.aip". PharoLauncher was built with some minor changes from above... 1. Download/extracted http://files.pharo.org/platform/Pharo6.1-win.zip 2. Renamed Pharo6.1 folder to BCPharoLauncher Renamed Pharo6.1.* files to PharoLauncher1.1.* 3. Metacello new smalltalkhubUser: 'Pharo' project: 'PharoLauncher'; configuration: 'PharoLauncher'; load. PharoLauncher hardResetPersistanceState: true. PhLDeploymentScript doAll. PhLDeploymentScript closeWindowsAndOpenLauncher. Smalltalk snapshot: true andQuit: true. 4. Moved the image & changes files into a subfolder "PerUserFiles" 5. Built BCPharoLauncher.msi I prefixed my initials to distinguish it from the current official PharoLauncher installer. Hopefully this can be adopted as the official installer and they can be dropped off. Key features: a. Provides a choice to install for "Everybody" (i.e. C:\Program Files (x86)\Pharo\BCPharoLauncher\) or "Only for me" (i.e. C:\Users\Ben\AppData\Local\Programs\Pharo\BCPharoLauncher\) per attached screen snapshot. b. Start the install as a Standard User and it escalates only as needed. c. The Desktop and Start Menu shortcuts run the following script... // File: PharoLauncher.js // Author: Ben Coman 2018.03.24 // Purpose: Facilitate each user to run a personal copy of PharoLauncher.image in their own data area. // Locations basename = "\\PharoLauncher1.1"; WshShell = WScript.CreateObject("WScript.Shell"); fso = WScript.CreateObject("Scripting.FileSystemObject"); systemFolder = fso.GetAbsolutePathName("."); vmFilename = systemFolder + "\\Pharo.exe" systemBasename = systemFolder + "\\PerUserFiles" + basename; userFolder = WshShell.ExpandEnvironmentStrings("%LOCALAPPDATA%\\Pharo"); userFolder2 = userFolder + "\\PharoLauncher"; userBasename = userFolder2 + basename; // Ensure user data folder exists for PharoLauncher if( ! fso.FolderExists(userFolder)) { fso.CreateFolder(userFolder); fso.CreateFolder(userFolder2) } // If either image or changes files missing from user folder, copy from system folder. if( ! fso.FileExists(userBasename + ".image") || ! fso.FileExists(userBasename + ".changes")) { //WScript.Echo("Setting up user environment"); fso.CopyFile(systemBasename + ".image", userBasename + ".image", true); fso.CopyFile(systemBasename + ".changes", userBasename + ".changes", true); } // Start personal copy of PharoLauncher WshShell.Exec(vmFilename + " " + userBasename + ".image") cheers -ben

March 23, 2018