- Pharo-dev - lists.pharo.org

DebugSession: no exception raised when stepping out of the execution?

by tdupriez＠ens-paris-saclay.fr

Hi, I'm working with DebugSession to see if I can implement something that would step into an execution until a given expression evaluates to a different value than the value it had at the beginning to quickly localise the precise point where an invariant is broken. But it appears that if the expression always evaluate to the same value, then the VM freezes. I simplified my program to just stepInto a debugSession indefinitely, and it makes the VM freeze, while I would rather expect an exception to be raised (something like "ReachedEndOfExecution"). Here is my example code. Beware, running it will freeze the VM. | program process context debugSession | program := [1+2]. process := program newProcess. context := process suspendedContext. debugSession := process newDebugSessionNamed: 'StepIntoForever' startedAt: context. [ true ] whileTrue: [ debugSession stepInto ]. Is there a way to have an exception be raised when a stepInto message is sent to a debugSession whose execution is finished, instead of just freezing the VM? Thomas

May 29, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Christophe Demarey

Hi Doru, > Le 28 mai 2017 Ã 10:40, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > > Hi, > > I just had the issue again while typing code. > > I actually cannot work. Is it really only me, or is it that others just got used to living with this and not report the issue? I have exactly the same problem. It happens at least once a day for me. It is very annoying. It always happens when typing, and I would I say when I press many keys within a very small delay. Here is a crash dump I experienced (OS X 10.11.4): Segmentation fault Fri May 19 11:28:42 2017 VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ C stack backtrace & registers: eax 0x7a653640 ebx 0x7c27b010 ecx 0x97f8ab12 edx 0xe0000000 edi 0x97f6e93f esi 0x97f6e93f ebp 0xbff35558 esp 0xbff35318 eip 0x97f6ecaf 0 libobjc.A.dylib 0x97f6ecaf objc_msgSend + 31 1 Pharo 0x00118233 reportStackState + 819 2 Pharo 0x00118597 sigsegv + 129 3 libsystem_platform.dylib 0x9346d79b _sigtramp + 43 4 ??? 0xffffffff 0x0 + 4294967295 5 CoreFoundation 0x9a1e969f _CFAutoreleasePoolPop + 47 6 HIToolbox 0x94cdb2c1 IMKInputSessionProcessEventRefWithCompletionHandler + 142 7 HIToolbox 0x94cda4ac InputMethodInstanceProcessEventRef_WithCompletionHandler + 115 8 HIToolbox 0x94cc37f9 __TSMEventToInputMethod_WithCompletionHandler_block_invoke + 122 9 HIToolbox 0x94cc89be __TrySendLockEvent_BeforeEventToInputMethod_WithContinuationHandler_block_invoke + 33 10 HIToolbox 0x94cc8a87 __SendTSMDocumentLockEvent_WithCompletionHandler_block_invoke + 120 11 HIToolbox 0x94a7512f __SendTSMEvent_WithCompletionHandler_block_invoke + 73 12 HIToolbox 0x94a7841d __SendEventToEventTargetWithCompletionHandler_block_invoke + 25 13 HIToolbox 0x94a783fd ___ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec_block_invoke + 127 14 AppKit 0x98539bb2 ___NSTSMEventHandler_block_invoke + 25 15 AppKit 0x98532e83 -[NSTextInputContext handleTSMEvent:completionHandler:] + 1253 16 AppKit 0x98532942 _NSTSMEventHandler + 302 17 HIToolbox 0x94a7c2ff _Z22_InvokeEventHandlerUPPP25OpaqueEventHandlerCallRefP14OpaqueEventRefPvPFlS0_S2_S3_E + 36 18 HIToolbox 0x94a247b0 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1832 19 HIToolbox 0x94a239c4 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 402 20 HIToolbox 0x94a2382a SendEventToEventTargetWithOptions + 40 21 HIToolbox 0x94a74d9a SendTSMEvent_WithCompletionHandler + 435 22 HIToolbox 0x94cc3736 TrySendLockEvent_BeforeEventToInputMethod_WithContinuationHandler + 409 23 HIToolbox 0x94cc351b TSMEventToInputMethod_WithCompletionHandler + 152 24 HIToolbox 0x94a72d96 TSMProcessRawKeyEventWithOptionsAndCompletionHandler + 4060 25 AppKit 0x98d1bb7b __61-[NSTextInputContext _handleEvent:options:completionHandler:]_block_invoke999 + 147 26 AppKit 0x98531778 -[NSTextInputContext tryTSMProcessRawKeyEvent:dispatchCondition:setupForDispatch:furtherCondition:dispatchWork:continuation:] + 129 27 AppKit 0x985313d3 -[NSTextInputContext _handleEvent:options:completionHandler:] + 1715 28 AppKit 0x98530cff -[NSTextInputContext handleEvent:] + 128 29 AppKit 0x98530bfe -[NSView interpretKeyEvents:] + 205 30 Pharo 0x0011455e -[sqSqueakOSXOpenGLView keyDown:] + 310 31 AppKit 0x9853015e -[NSWindow _handleKeyDownEvent:] + 569 32 AppKit 0x98c05c22 -[NSWindow _reallySendEvent:isDelayedEvent:] + 2303 33 AppKit 0x9859c96f -[NSWindow sendEvent:] + 567 34 AppKit 0x98517cdd -[NSApplication sendEvent:] + 2919 35 Pharo 0x0010cdcb -[SqueakOSXApplication sendEvent:] + 163 36 Pharo 0x0010e9a4 -[sqSqueakOSXApplication(events) pumpRunLoopEventSendAndSignal:] + 115 37 Pharo 0x0010ea42 -[sqSqueakOSXApplication(events) pumpRunLoop] + 76 38 Pharo 0x0011688a nativeIoProcessEvents + 208 39 Pharo 0x001168de ioProcessEvents + 35 40 Pharo 0x000aa470 checkForEventsMayContextSwitch + 880 41 Pharo 0x000abcea ceCheckForInterrupts + 16 42 ??? 0x0483e09b 0x0 + 75751579 43 Pharo 0x000981bc interpret + 647 44 Pharo 0x001196ad -[sqSqueakMainApplication runSqueak] + 476 45 Foundation 0x931b65b9 __NSFirePerformWithOrder + 416 46 CoreFoundation 0x9a24e90e __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30 47 CoreFoundation 0x9a24e86e __CFRunLoopDoObservers + 398 48 CoreFoundation 0x9a22bf92 __CFRunLoopRun + 946 49 CoreFoundation 0x9a22b976 CFRunLoopRunSpecific + 390 50 CoreFoundation 0x9a22b7db CFRunLoopRunInMode + 123 51 HIToolbox 0x94a482f1 RunCurrentEventLoopInMode + 267 52 HIToolbox 0x94a47fc5 ReceiveNextEventCommon + 201 53 HIToolbox 0x94a47eec _BlockUntilNextEventMatchingListInModeWithFilter + 99 54 AppKit 0x9837844e _DPSNextEvent + 1053 55 AppKit 0x983779c7 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1057 56 AppKit 0x9837759e -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 121 57 AppKit 0x9836acb3 -[NSApplication run] + 1063 58 AppKit 0x983315a9 NSApplicationMain + 1630 59 libdyld.dylib 0x954466ad start + 1 Smalltalk stack dump: 0xbff3b910 M ProcessorScheduler class>idleProcess 0x5058868: a(n) ProcessorScheduler class 0xbff3b930 I [] in ProcessorScheduler class>startUp 0x5058868: a(n) ProcessorScheduler class 0xbff3b950 I [] in BlockClosure>newProcess 0x81e08c0: a(n) BlockClosure Most recent primitives < >= + < primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock >= signal >= signal + primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue millisecondClockValue signal primUTCMicrosecondsClock + >= + < primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue yield wait millisecondClockValue signal primUTCMicrosecondsClock + < >= + < primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock >= signal >= signal + primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue millisecondClockValue signal primUTCMicrosecondsClock + >= + < primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue yield wait millisecondClockValue signal primUTCMicrosecondsClock + < >= + < primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock >= signal >= signal + primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue millisecondClockValue signal primUTCMicrosecondsClock + >= + < primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue yield wait millisecondClockValue signal primUTCMicrosecondsClock + < >= + < primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: stack page bytes 4096 available headroom 2788 minimum unused headroom 2296

May 29, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Stephane Ducasse

I got it from time to time (but may be once a week) but I was in the Bloc image and it crashed in other ways. I'm on sierra with latest vm and image. On Sun, May 28, 2017 at 8:27 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 28/05/2017 Ã 10:50, Esteban Lorenzano a Ã©crit : > > > > > > yes, but I never had it (and I use mac and I type fairly fast too). > > > > Same, never had it and I type fast. > > > Esteban > > > > > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

May 28, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Cyril Ferlicot D.

Le 28/05/2017 Ã 10:50, Esteban Lorenzano a Ã©crit : > > > yes, but I never had it (and I use mac and I type fairly fast too). > Same, never had it and I type fast. > Esteban > > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

May 28, 2017

Re: [Vm-dev] multiple crashes on macOS Sierra

by Milan Vavra

> I am actually running under a VM I built because that one is not > mysteriously crashing and as I have an assert and debug version, I hope > to find the reason why this happens. If you have mysterious crashes in a release build that stop when you switch to a debug build, the compiler optimization options could be the problem. Best Regards, Milan Vavra -- View this message in context: http://forum.world.st/Re-Vm-dev-multiple-crashes-on-macOS-Sierra-tp4948481p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 28, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by phil＠highoctane.be

I am using a fork of the official thing and also build on appveyor, so, the stack is the same. Phil On Sun, May 28, 2017 at 4:41 PM, Milan Vavra via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Milan Vavra <vavra_milan(a)yahoo.com> > To: pharo-dev(a)lists.pharo.org > Cc: > Bcc: > Date: Sun, 28 May 2017 07:41:36 -0700 (PDT) > Subject: Re: [Vm-dev] multiple crashes on macOS Sierra > > I hope to find the reason why this happens. > > Good luck and, of course, if the problem goes away by using a custom > built debug build -- there's more fun in store trying to find out > if/what goes wrong with the optimizations used in the release build. > > Turning off optimizations with -O0 could be a first step to verify if > release build C compiler optimizations are to blame. > > Because the C compiler does optimize things and sometimes optimizes > things away that it should not. > > > Best Regards, > > Milan Vavra > > > > -- > View this message in context: http://forum.world.st/Re-Vm- > dev-multiple-crashes-on-macOS-Sierra-tp4948481p4948486.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > >

May 28, 2017

Re: [Vm-dev] multiple crashes on macOS Sierra

by Milan Vavra

> I hope to find the reason why this happens. Good luck and, of course, if the problem goes away by using a custom built debug build -- there's more fun in store trying to find out if/what goes wrong with the optimizations used in the release build. Turning off optimizations with -O0 could be a first step to verify if release build C compiler optimizations are to blame. Because the C compiler does optimize things and sometimes optimizes things away that it should not. Best Regards, Milan Vavra -- View this message in context: http://forum.world.st/Re-Vm-dev-multiple-crashes-on-macOS-Sierra-tp4948481p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 28, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by philippe.back＠highoctane.be

I got that too (windows). And that's also one reason why I made this thing. https://github.com/Pharophile/HOImageSaver I am actually running under a VM I built because that one is not mysteriously crashing and as I have an assert and debug version, I hope to find the reason why this happens. Yes it sucks the joy out. Phil Le 28 mai 2017 10:41, "Tudor Girba" <tudor(a)tudorgirba.com> a Ã©crit : > Hi, > > I just had the issue again while typing code. > > I actually cannot work. Is it really only me, or is it that others just > got used to living with this and not report the issue? > > I would consider this a blocker. Do you agree? > > Cheers, > Doru > > > > On May 26, 2017, at 8:10 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi Nicolas, > > > > Thanks. > > > > You might be right. It just happened again while typing. > > > > I am using: > > - Pharo image: 60497 > > - VM: > > CoInterpreter VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 > May 2 2017 > > StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid: > 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 > > VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > > > > > <crash.dmp> > > > > Cheers, > > Doru > > > > > >> On May 25, 2017, at 4:44 PM, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > >> > >> Hi Tudor, > >> it seems you type too fast. > >> More seriously, if I google some of the apple methods in the stack like > for example > >> "bug InputMethodInstanceProcessEventRef_WithCompletionHandler" > >> I see quite some many hits indicating that: > >> - we are not alone > >> - either there are some bug on mac os > >> - or it's complex to use the frameworks right... > >> > >> Debugging this kind of low level problem is going to be tough... > >> Probably some advanced objective-C knowledge is required. > >> > >> 2017-05-24 22:28 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> > >> Hi, > >> > >> Today I experienced multiple crashes on macOS Sierra. > >> > >> These happened during regular programming, mostly while typing code. I > attached here the crash dump(s). I believe I heard Phil having the same > issue with the stable Pharo VM. > >> > >> Does anyone else has the same issue? > >> > >> The VM is: > >> CoInterpreter VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 > May 2 2017 > >> StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid: > 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 > >> VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > >> > >> The Pharo update number is: 60482 > >> > >> Cheers, > >> Doru > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "From an abstract enough point of view, any two things are similar." > >> > >> > >> > >> > >> > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "If you interrupt the barber while he is cutting your hair, > > you will end up with a messy haircut." > > > > -- > www.tudorgirba.com > www.feenk.com > > "Being happy is a matter of choice." > > > > > >

May 28, 2017

Re: [Pharo-dev] basicNew usage pattern

by Sven Van Caekenberghe

> On 28 May 2017, at 10:39, Ben Coman <btc(a)openinworld.com> wrote: > > On Sat, May 27, 2017 at 5:41 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >> On Saturday 27 May 2017 01:41 PM, Ben Coman wrote: >>> >>> A question arose in Discord regarding #basicNew, to which I felt like >>> the proper answer should be >>> that #basicNew is used only** from the class-side when making custom >>> initializers. >>> (**excepting special meta-handling like by Behaviour) >> >> >> AFAIK, #basicNew is a low-level essential method which should *never* be >> overridden by application methods, while #new offers a stable facade over >> #basicNew for applications. >> >> Essentially, #basic* methods are calls to primitives in VM which reify basic >> objects of the object model like float, symbols etc. They are coupled >> closely with interpreter and object memory structures and functions. >> Application classes do not concern themselves with size and layout of such >> objects and use the facade methods like #new. >> >> It is like the difference between a system call and runtime C library >> function. A C function like malloc maintains a stable interface to the app >> while its makes different system calls on different OS implementations. >> >> HTH .. Subbu >> > > Thanks Subbu. That is a useful insight for me, but is about the > implementation. > My query was more about senders of basicNew, so is still open if you > have an opinion there, or anyone else. > cheers -ben Normally #basicNew is an implementation detail. It is however often used to prevent #initialize from happening (#new being #basicNew followed by #initialize). If that is the case, then it is probably a design error. Sven

May 28, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Esteban Lorenzano

> On 28 May 2017, at 10:40, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > I just had the issue again while typing code. > > I actually cannot work. Is it really only me, or is it that others just got used to living with this and not report the issue? > > I would consider this a blocker. Do you agree? yes, but I never had it (and I use mac and I type fairly fast too). Esteban > > Cheers, > Doru > > >> On May 26, 2017, at 8:10 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi Nicolas, >> >> Thanks. >> >> You might be right. It just happened again while typing. >> >> I am using: >> - Pharo image: 60497 >> - VM: >> CoInterpreter VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 >> VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> >> <crash.dmp> >> >> Cheers, >> Doru >> >> >>> On May 25, 2017, at 4:44 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> Hi Tudor, >>> it seems you type too fast. >>> More seriously, if I google some of the apple methods in the stack like for example >>> "bug InputMethodInstanceProcessEventRef_WithCompletionHandler" >>> I see quite some many hits indicating that: >>> - we are not alone >>> - either there are some bug on mac os >>> - or it's complex to use the frameworks right... >>> >>> Debugging this kind of low level problem is going to be tough... >>> Probably some advanced objective-C knowledge is required. >>> >>> 2017-05-24 22:28 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> >>> Hi, >>> >>> Today I experienced multiple crashes on macOS Sierra. >>> >>> These happened during regular programming, mostly while typing code. I attached here the crash dump(s). I believe I heard Phil having the same issue with the stable Pharo VM. >>> >>> Does anyone else has the same issue? >>> >>> The VM is: >>> CoInterpreter VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 >>> VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>> >>> The Pharo update number is: 60482 >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "From an abstract enough point of view, any two things are similar." >>> >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." >> > > -- > www.tudorgirba.com > www.feenk.com > > "Being happy is a matter of choice." > > > >

May 28, 2017