November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

by Mariano Martinez Peck

On Mon, Nov 16, 2015 at 2:48 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Nov 16, 2015 at 1:07 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> Hi Mariano, if you know the method that may cause this crash can you check >> if it works if you recompile this method with the old compiler, >> maybe this issue is responsible - wrong stack frame size : >> 13854 >> <https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-li…> >> frameSize calculated wrongly for #lineSegmentsDo: >> >> > Hi Nicolai, > > Thanks for the pointer. I tried with your fix and I still get the same > results (even after recompiling). > However...if I swap back to old Compiler rather than OpalCompiler and I > recompile everything, then I do not have anymore the crash. > So it's definitively something related to Opal compilation, and probably, > related to closures compilation. > I will see if I find other opal issues opened in 4.0. > > Thanks! > > >> >> >> 2015-11-16 17:00 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> >>> 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 >>> >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Nov. 16, 2015

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

by Eliot Miranda

On Mon, Nov 16, 2015 at 6:54 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Maybe my VM is rusty :) > If you invoke it on the command line with the -version flag it'll tell you what version it is and when i was compiled. Would you mind checking? > > 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 > >> > > > > > > > -- _,,,^..^,,,_ best, Eliot

Nov. 16, 2015

Re: [Pharo-dev] ubuntu ppa not up-to-date

by Markus Fritsche

Hi Peter, hello list, I am going to update it today. Kind regards, Markus Am 15.11.2015 um 20:43 schrieb Peter UhnÃ¡k: > Hi, > > on slack with @latsabben we found out that pharo-launcher ppa is not > up-to-date > > latest ubuntu relase is Wily (Oct 22), but in the ppa there's only > trusty from June, which is two releases ago. > > I don't think that this is good for newcomers. > > And if you encounter a problem with installation, change your package > distribution > ( System Settings -> System -> Software & Updates -> Other Software > -->> then edit the distrubution; this could perhaps be mentioned also > in the install instructions ) > > Peter

Nov. 16, 2015

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