- Pharo-dev - lists.pharo.org

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 17:03, Holger Freyther <holger(a)freyther.de> wrote: > > > > 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. The snippet below is my work-around. I think the proper fix is to get FT2Handle to invalidate handles a lot earlier (Gui->System startup?). Author useAuthor: 'Hacks' during: [ FreeTypeExternalMemory addInstVarNamed: 'session'. FreeTypeExternalMemory compile: 'validate (session == Smalltalk session and: [ self isValid ]) ifTrue: [ ^self ]. bytes ifNil: [ ^ self ]. session := Smalltalk session. self primCopyToExternalMemory: bytes. self isValid ifTrue: [ self class register: self ]' ]. Smalltalk snapshot: true andQuit: true.

March 25, 2018

Re: [Pharo-dev] Slot Questions

by Sean P. DeNigris

Sean P. DeNigris wrote > Object subclass: #MyClass > slots: { #var1 => MySlot adjustment: 10 } > classVariables: { } > category: '' > â¦ > but when I open a new browser on the class definition of MyClass, the > slots > are truncated to: > slots: { #var1 => MySlot } It turns out that the slot is still "working" e.g. #adjustment is still having its effect e.g. read: anObject ^ (super read: anObject) ifNotNil: [ :val | val + self adjustment ] It's just that the class template has lost information. Another issue: Changing the slots in the template from "{ #var1 => MySlot adjustment: 10 }" to "{ #var1 => MySlot adjustment: 100 }" has no effect unless I accept an intermediate "{ #var1 }" ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 24, 2018

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

by Javier PimÃ¡s

On Fri, Mar 23, 2018 at 11:17 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > 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/OpenSmallta >> lk/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. > > Thanks! I'll try to do something better instead: do it by myself asking questions if needed, it might take some time before I start though. Cheers, Pocho >> 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 > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 24, 2018

Re: [Pharo-dev] Slot Questions

by Sean P. DeNigris

Question #3: Shouldn't the following (from the paper): slots: { #staff => ManySlot opposite: #boss class: Clerk. } Be: slots: { #staff => (ManySlot opposite: #boss class: Clerk). } Also, what is that code actually doing? Is #opposite:class: a class-side method of ManySlot? If so, what does it return? Ah, I see now - #=>> does some magic to accept either a Slot class or instance. Question #4: Given: Object subclass: #MyClass slots: { #var1 => MySlot } classVariables: { } category: '' and MyClass >>#var1: anObject var1 := anObject MySlot>#write:to: doesn't seem to be sent when I `myClassInstance var1: 2`. I tried to insert a halt, 1 inspect, etc. I am able to intercept #read: on the other hand Question #5: I tried: Object subclass: #MyClass slots: { #var1 => MySlot adjustment: 10 } "with and without () around `MySlot adjustment: 10`" classVariables: { } category: '' where: InstanceVariableSlot subclass: #MySlot slots: { #adjustment } and: adjustment ^ adjustment ifNil: [ 0 ] but when I open a new browser on the class definition of MyClass, the slots are truncated to: slots: { #var1 => MySlot } ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 24, 2018

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