- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] InputEventFetcher update

by Henrik Johansen

Note that installEventSensorFramework: does a deinstall/install cycle of the old/new framework, so the explicit deinstall/install calls at the beginning are superfluous. IOW, for a bootstrap you only need InputEventSensor installEventSensorFramework Cheers, Henry > On 16 Nov 2015, at 4:43 , Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > ok, I got it. > The class InputEventSensor registers eventHandlers in InputEventFetcher. > The code to re-initilaize the EventFetcher is: > InputEventFetcher > deinstall; > install. > InputEventSensor installEventSensorFramework > > > Le 16 nov. 2015 Ã 16:37, Christophe Demarey a Ã©crit : > >> >> Le 16 nov. 2015 Ã 16:15, Guillermo Polito a Ã©crit : >> >>> Tricky question :) >>> >>> In theory, just doing #startUp should be enough. >> >> for the snapshot:andQuit:, yes. >> But I'm also taking information for the bootstrap. It is good to know how to initialize the system ;) >> >>> But! Digging a bit you see that this code depends on the ExternalSemaphoreTable which uses an array of semaphores in the special objects array. >>> >>> unprotectedExternalObjects >>> ^Smalltalk specialObjectsArray at: 39 >>> >>> So, before being able to work, the array at index 39 should be initialized. Which in theory can be done with >>> >>> ExternalSemaphoreTable>>clearExternalObjects >>> "Clear the array of objects that have been registered for use in non-Smalltalk code." >>> "Only lock additions, removals executing in parallel would have little effect on the resulting array" >>> >>> ProtectAdd critical: [ >>> self unprotectedExternalObjects: Array new]. >>> >> >> When I run >> InputEventFetcher >> shutDown; >> startUp >> It works as expected. >> >> It looks like the problem is there if you try to install a new instance of InputEventFetcher. >> I do not get how eventHandlers inst. var is set in this case. fetcherProcess inst. var is initialized through #installEventLoop and inputSemaphore through #StartUp. >> Maybe it is the problem. >

Nov. 16, 2015

Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Mariano Martinez Peck

Hi guys, I am debugging a Pharo VM crash I am having and I cannot figure out what it is exactly. I suspect it might be related to block closures compilation but I am not sure. I have a reproducible crash test under Pharo 4.0 and OSX. I built a VM in debug mode and I run it via gdb. This is the kind of info I am able to see: *Program received signal SIGSEGV, Segmentation fault.* *0x000ab66b in updatePointersInRangeFromto (memStart=924623948, memEnd=928201420) at /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:40444* *40444 && (((longAt(fieldOop)) & MarkBit) != 0)) {* *(gdb) call printAllStacks()* *Process 0x30e228c4 priority 40* *0xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction class* *0xbffb2e30 M BlockClosure(FaMemoryStoreSession)>register: 0x371d0968: a(n) BlockClosure* *0xbffb2e4c M INVALID RECEIVER>register: 0x371cfd54: a(n) bad class* *(callerContextOrNil == (nilObject())) || (isContext(callerContextOrNil)) 48626* *0x3721e1f0 is not a context* *0x371c34b4 is not a context* And another crash: *Program received signal SIGSEGV, Segmentation fault.* *0x000ab66b in updatePointersInRangeFromto (memStart=924677864, memEnd=928262300) at /Users/mariano/Pharo/git/pharo-vm/src/vm/gcc3x-cointerp.c:40444* *40444 && (((longAt(fieldOop)) & MarkBit) != 0)) {* *(gdb) call printAllStacks()* *Process 0x30e228c4 priority 40* *0xbffb2de0 M INVALID RECEIVER>initialize 0x3722b9a0: a(n) bad class* *0xbffb2df8 M FaAction class(Behavior)>new 0x20ebb104: a(n) FaAction class* *0xbffb2e10 M FaAction class>block: 0x20ebb104: a(n) FaAction class* *0xbffb2e30 M INVALID RECEIVER>register: 0x371ddee0: a(n) bad class* *0xbffb2e4c M INVALID RECEIVER>register: 0x371dd328 is in old space* *(callerContextOrNil == (nilObject())) || (isContext(callerContextOrNil)) 48626* *0x3722b750 is not a context* *[New Thread 0x1b43 of process 5886]* *[New Thread 0x1d2f of process 5886]* *[New Thread 0x1f07 of process 5886]* *[New Thread 0x1e07 of process 5886]* >From what I can see in *#printActivationNameFor: aMethod receiver: anObject isBlock: isBlock firstTemporary: maybeMessage* It looks like if the memory address is not an OOP, nor forwarding pointer nor... It also seems like the above stack I can get is not the real cause but a side effect that makes GC to crash (#updatePointersInRangeFromto) As said, I have a way to reproduce the crash, and I already have the VM compiled in debug and gdb running. I can also attach the full output of the gdb stack. BTW.... in the output of the gdb I see lots of printings like: *(numStack + ReceiverIndex) < (lengthOf(theContext)) 45421* *(ReceiverIndex + contextSize) < (lengthOfbaseHeaderformat(oop, header2, fmt)) 40416* Any pointer is appreciated. Thanks! -- Mariano http://marianopeck.wordpress.com

Nov. 16, 2015

Re: [Pharo-dev] InputEventFetcher update

by Christophe Demarey

ok, I got it. The class InputEventSensor registers eventHandlers in InputEventFetcher. The code to re-initilaize the EventFetcher is: InputEventFetcher deinstall; install. InputEventSensor installEventSensorFramework Le 16 nov. 2015 Ã 16:37, Christophe Demarey a Ã©crit : > > Le 16 nov. 2015 Ã 16:15, Guillermo Polito a Ã©crit : > >> Tricky question :) >> >> In theory, just doing #startUp should be enough. > > for the snapshot:andQuit:, yes. > But I'm also taking information for the bootstrap. It is good to know how to initialize the system ;) > >> But! Digging a bit you see that this code depends on the ExternalSemaphoreTable which uses an array of semaphores in the special objects array. >> >> unprotectedExternalObjects >> ^Smalltalk specialObjectsArray at: 39 >> >> So, before being able to work, the array at index 39 should be initialized. Which in theory can be done with >> >> ExternalSemaphoreTable>>clearExternalObjects >> "Clear the array of objects that have been registered for use in non-Smalltalk code." >> "Only lock additions, removals executing in parallel would have little effect on the resulting array" >> >> ProtectAdd critical: [ >> self unprotectedExternalObjects: Array new]. >> > > When I run > InputEventFetcher > shutDown; > startUp > It works as expected. > > It looks like the problem is there if you try to install a new instance of InputEventFetcher. > I do not get how eventHandlers inst. var is set in this case. fetcherProcess inst. var is initialized through #installEventLoop and inputSemaphore through #StartUp. > Maybe it is the problem.

Nov. 16, 2015

Re: [Pharo-dev] InputEventFetcher update

by Guillermo Polito

You mean how it is filled? Check InputEventSensor>>installEventSensorFramework: fetcherClass Itâs ugly but I think itâs thereâ¦ newSensor registerIn: InputEventFetcher default. UserInterruptHandler new registerIn: InputEventFetcher default. > On 16 nov 2015, at 4:37 p.m., Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > > Le 16 nov. 2015 Ã 16:15, Guillermo Polito a Ã©crit : > >> Tricky question :) >> >> In theory, just doing #startUp should be enough. > > for the snapshot:andQuit:, yes. > But I'm also taking information for the bootstrap. It is good to know how to initialize the system ;) > >> But! Digging a bit you see that this code depends on the ExternalSemaphoreTable which uses an array of semaphores in the special objects array. >> >> unprotectedExternalObjects >> ^Smalltalk specialObjectsArray at: 39 >> >> So, before being able to work, the array at index 39 should be initialized. Which in theory can be done with >> >> ExternalSemaphoreTable>>clearExternalObjects >> "Clear the array of objects that have been registered for use in non-Smalltalk code." >> "Only lock additions, removals executing in parallel would have little effect on the resulting array" >> >> ProtectAdd critical: [ >> self unprotectedExternalObjects: Array new]. >> > > When I run > InputEventFetcher > shutDown; > startUp > It works as expected. > > It looks like the problem is there if you try to install a new instance of InputEventFetcher. > I do not get how eventHandlers inst. var is set in this case. fetcherProcess inst. var is initialized through #installEventLoop and inputSemaphore through #StartUp. > Maybe it is the problem.

Nov. 16, 2015

Re: [Pharo-dev] InputEventFetcher update

by Christophe Demarey

Le 16 nov. 2015 Ã 16:15, Guillermo Polito a Ã©crit : > Tricky question :) > > In theory, just doing #startUp should be enough. for the snapshot:andQuit:, yes. But I'm also taking information for the bootstrap. It is good to know how to initialize the system ;) > But! Digging a bit you see that this code depends on the ExternalSemaphoreTable which uses an array of semaphores in the special objects array. > > unprotectedExternalObjects > ^Smalltalk specialObjectsArray at: 39 > > So, before being able to work, the array at index 39 should be initialized. Which in theory can be done with > > ExternalSemaphoreTable>>clearExternalObjects > "Clear the array of objects that have been registered for use in non-Smalltalk code." > "Only lock additions, removals executing in parallel would have little effect on the resulting array" > > ProtectAdd critical: [ > self unprotectedExternalObjects: Array new]. > When I run InputEventFetcher shutDown; startUp It works as expected. It looks like the problem is there if you try to install a new instance of InputEventFetcher. I do not get how eventHandlers inst. var is set in this case. fetcherProcess inst. var is initialized through #installEventLoop and inputSemaphore through #StartUp. Maybe it is the problem.

Nov. 16, 2015

Re: [Pharo-dev] InputEventFetcher update

by Guillermo Polito

Tricky question :) In theory, just doing #startUp should be enough. But! Digging a bit you see that this code depends on the ExternalSemaphoreTable which uses an array of semaphores in the special objects array. unprotectedExternalObjects ^Smalltalk specialObjectsArray at: 39 So, before being able to work, the array at index 39 should be initialized. Which in theory can be done with ExternalSemaphoreTable>>clearExternalObjects "Clear the array of objects that have been registered for use in non-Smalltalk code." "Only lock additions, removals executing in parallel would have little effect on the resulting array" ProtectAdd critical: [ self unprotectedExternalObjects: Array new]. Tell me if that works, Guille > On 16 nov 2015, at 4:00 p.m., Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Hi, > > I'm working on the new startup/shutdown mechanism and I came to discover InputEventFetcher. > > What are the instruction to properly initialize / re-initialize the InputEventFetcher ? > I tried > InputEventFetcher > deinstall; > install > and > InputEventFetcher > shutDown; > deinstall; > install; > startUp > > but both end to an image not responding to mouse / keyboard events. > > > Thanks for any help, > Christophe

Nov. 16, 2015

InputEventFetcher update

by Christophe Demarey

Hi, I'm working on the new startup/shutdown mechanism and I came to discover InputEventFetcher. What are the instruction to properly initialize / re-initialize the InputEventFetcher ? I tried InputEventFetcher deinstall; install and InputEventFetcher shutDown; deinstall; install; startUp but both end to an image not responding to mouse / keyboard events. Thanks for any help, Christophe

Nov. 16, 2015

Re: [Pharo-dev] Help me to understand where I screwed up QAâ¦

by Yuriy Tymchuk

Maybe my VM is rusty :) We need to put pharo launcher on Appstore, so it will ask for updates automatically. Thanks. Uko > On 16 Nov 2015, at 15:48, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I can not reproduce it here (with a recent VM). > > Marcus > >> On 16 Nov 2015, at 11:40, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Yuriy, >> >> this looks like an old VM bug. Are you sure you're using the most up-to-date VM? >> >> _,,,^..^,,,_ (phone) >> >>> On Nov 16, 2015, at 6:02 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Hi everyone, >>> >>> this is a weird issue that wasnât there when I was developing the feature. >>> >>> If inspector plugin is enabled in prefs and you inspect a method (e.g. Object>>#asString) you get âMessageNotUnderstood: SmallInteger>>notEmptyâ on â(critics := self critics) notEmptyâ. If you inspect critics temporary itâs a Set, if you restart in debugger and step over it works well, but for some reason initially notEmpty is sent to some int. Any idea what is the issue? >>> >>> Cheers, >>> Uko >> > >

Nov. 16, 2015

Re: [Pharo-dev] last opened window does not go away

by Henrik Nergaard

The RubFindReplaceDialogWindow is made and held by RubFindReplaceService ivar dialog. There is also the ivar textAreaHolder which holds the active text area. When setting this variable from #textArea: an announcement is created for the textArea to the RubFindReplaceService, this should probably be a weak one. I think the main issue is that the textArea instance variable is not cleared from RubFindReplaceService when it is deleted. There is also announcements linked to RubFindReplaceService made by: RubAbstractTextArea>>#plugFindReplace. I guess these announcements should be weak. Hope this helps, Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Andrei Chis Sent: Monday, November 16, 2015 3:23 PM To: Discusses Development of Pharo <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] last opened window does not go away Hi, In the latest Pharo image there is a rogue instance of GLMSystemWindow. If I do in the console the following code I get one instance: /pharo Pharo.image eval "GLMSystemWindow allInstances" an Array(a GLMSystemWindow(58720256)) There are actually two windows, but one is RubFindReplaceDialogWindow and it should have no link with the glamour window. ./pharo Pharo.image eval "SystemWindow allSubInstances" an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a GLMSystemWindow(58720256)) If I create another window that contains a morph that can take the focus then the glamour window disappears and the new window stays: ./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: nil) openInWindow close. Smalltalk garbageCollect. SystemWindow allSubInstances" an OrderedCollection(a SystemWindow(234094592) an EditorFindReplaceDialogWindow(130547712)) Any idea if the find-replace service from rubric/textmorph holds one somehow to the last opened window or if there is another global cache that does it? Cheers, Andrei

Nov. 16, 2015

Re: [Pharo-dev] Help me to understand where I screwed up QAâ¦

by Marcus Denker

I can not reproduce it here (with a recent VM). Marcus > On 16 Nov 2015, at 11:40, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Yuriy, > > this looks like an old VM bug. Are you sure you're using the most up-to-date VM? > > _,,,^..^,,,_ (phone) > >> On Nov 16, 2015, at 6:02 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hi everyone, >> >> this is a weird issue that wasnât there when I was developing the feature. >> >> If inspector plugin is enabled in prefs and you inspect a method (e.g. Object>>#asString) you get âMessageNotUnderstood: SmallInteger>>notEmptyâ on â(critics := self critics) notEmptyâ. If you inspect critics temporary itâs a Set, if you restart in debugger and step over it works well, but for some reason initially notEmpty is sent to some int. Any idea what is the issue? >> >> Cheers, >> Uko >

Nov. 16, 2015