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." crash.dmp (55K) Download Attachment |
Hi Tudor, it seems you type too fast."bug InputMethodInstanceProcessEven - 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 <[hidden email]>:
|
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 $ Cheers, Doru > On May 25, 2017, at 4:44 PM, Nicolas Cellier <[hidden email]> 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 <[hidden email]>: > > 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." crash.dmp (11K) Download Attachment |
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>: >> >> 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." |
> On 28 May 2017, at 10:40, Tudor Girba <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>: >>> >>> 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." > > > > |
Here is the fix they did for Chromium: https://chromium.googlesource.com/chromium/src.git/+/da364879b2e82d42525cb8942c652c2403d43ffbBest, Karl On Sun, May 28, 2017 at 10:50 AM, Esteban Lorenzano <[hidden email]> wrote:
|
In reply to this post by Nicolas Cellier
Hi Nicolas,
is the crash in our event processing code or elsewhere? If elsewhere, where?
|
2017-05-28 18:44 GMT+02:00 Eliot Miranda <[hidden email]>:
Hi Eliot, the crash dump provided by Tudor shows: ...snip... 32 AppKit 0x9210cb20 -[NSView interpretKeyEvents:] + 192 33 Pharo 0x0013f55e -[sqSqueakOSXOpenGLView keyDown:] + 310 34 AppKit 0x928614bb -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 5876 35 AppKit 0x9285fa49 -[NSWindow(NSEventRouting) sendEvent:] + 547 36 AppKit 0x926ea6aa -[NSApplication(NSEvent) sendEvent:] + 3418 37 Pharo 0x00137dcb -[SqueakOSXApplication sendEvent:] + 163 38 Pharo 0x001399a4 -[sqSqueakOSXApplication(events) pumpRunLoopEventSendAndSignal:] + 115 39 Pharo 0x00139a42 -[sqSqueakOSXApplication(events) pumpRunLoop] + 76 40 Pharo 0x0014188a nativeIoProcessEvents + 208 41 Pharo 0x001418de ioProcessEvents + 35 42 Pharo 0x000d5470 checkForEventsMayContextSwitch + 880 43 Pharo 0x000d6cea ceCheckForInterrupts + 16 44 ??? 0x0b0ad09b 0x0 + 185258139 45 Pharo 0x000c31bc interpret + 647 46 Pharo 0x001446ad -[sqSqueakMainApplication runSqueak] + 476 47 Foundation 0x95ac4adb __NSFirePerformWithOrder + 419 48 CoreFoundation 0x942811fe __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30 49 CoreFoundation 0x94281157 __CFRunLoopDoObservers + 391 50 CoreFoundation 0x942614a2 __CFRunLoopRun + 1058 51 CoreFoundation 0x94260e1a CFRunLoopRunSpecific + 506 52 CoreFoundation 0x94260c0b CFRunLoopRunInMode + 123 ...
|
Obviously I have to spend some time today to look at this problem. Do need to know if people are typing just plan english ascii characters, or? On Sun, May 28, 2017 at 10:02 AM, Nicolas Cellier <[hidden email]> wrote:
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk =========================================================================== |
I guess is just plain english ascii chars. Esteban
|
At commit point d0e7bfa0f8d99b856d9ac563 NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) location:[theEvent locationInWindow] modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) timestamp:[theEvent timestamp] windowNumber:[theEvent windowNumber] context:nil characters:@"" charactersIgnoringModifiers:@" isARepeat:NO keyCode:[theEvent keyCode]]); in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent However I believe this is incorrect as the NSEvent class side method is by the old non-arc memory rules implicitly an autoreleased object, so doing the AUTORELEASEOBJ() might cause side effects. https://developer.apple.com/ + (NSEvent *)keyEventWithType:(NSEventTyp If Tobias can verify and submit a change we can see if that affects the behaviour we have been observing. Note that I"ve not been able to recreate the problem, but in eyeballing the code this leaps out as suspect. On Sun, May 28, 2017 at 12:34 PM, Esteban Lorenzano <[hidden email]> wrote:
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk =========================================================================== |
I'll have a look in the morning -t > On 28.05.2017, at 22:12, John McIntosh <[hidden email]> wrote: > > At commit point d0e7bfa0f8d99b856d9ac56372f7dacecdd63106 (5/5/17) Tobias added > > > NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) > location:[theEvent locationInWindow] > modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) > timestamp:[theEvent timestamp] > windowNumber:[theEvent windowNumber] > context:nil > characters:@"" > charactersIgnoringModifiers:@"" > isARepeat:NO > keyCode:[theEvent keyCode]]); > > in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent > > However I believe this is incorrect as the NSEvent class side method is by the old non-arc memory rules implicitly an autoreleased object, so doing the AUTORELEASEOBJ() might cause side effects. https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html > > + (NSEvent *)keyEventWithType:(NSEventType)type location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum context:(NSGraphicsContext *)unusedPassNil characters:(NSString *)keys charactersIgnoringModifiers:(NSString *)ukeys isARepeat:(BOOL)flag keyCode:(unsigned short)code; > > If Tobias can verify and submit a change we can see if that affects the behaviour we have been observing. Note that I"ve not been able to recreate the problem, but in eyeballing the code this leaps out as suspect. > > > On Sun, May 28, 2017 at 12:34 PM, Esteban Lorenzano <[hidden email]> wrote: > > >> On 28 May 2017, at 20:40, John McIntosh <[hidden email]> wrote: >> >> Obviously I have to spend some time today to look at this problem. Do need to know if people are typing just plan english ascii characters, or? > > I guess is just plain english ascii chars. > > Esteban > >> >> On Sun, May 28, 2017 at 10:02 AM, Nicolas Cellier <[hidden email]> wrote: >> >> >> >> 2017-05-28 18:44 GMT+02:00 Eliot Miranda <[hidden email]>: >> >> Hi Nicolas, >> >> On May 25, 2017, at 7:44 AM, Nicolas Cellier <[hidden email]> 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. >> >> is the crash in our event processing code or elsewhere? If elsewhere, where? >> >> >> Hi Eliot, >> the crash dump provided by Tudor shows: >> >> ...snip... >> 32 AppKit 0x9210cb20 -[NSView interpretKeyEvents:] + 192 >> 33 Pharo 0x0013f55e -[sqSqueakOSXOpenGLView keyDown:] + 310 >> 34 AppKit 0x928614bb -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 5876 >> 35 AppKit 0x9285fa49 -[NSWindow(NSEventRouting) sendEvent:] + 547 >> 36 AppKit 0x926ea6aa -[NSApplication(NSEvent) sendEvent:] + 3418 >> 37 Pharo 0x00137dcb -[SqueakOSXApplication sendEvent:] + 163 >> 38 Pharo 0x001399a4 -[sqSqueakOSXApplication(events) pumpRunLoopEventSendAndSignal:] + 115 >> 39 Pharo 0x00139a42 -[sqSqueakOSXApplication(events) pumpRunLoop] + 76 >> 40 Pharo 0x0014188a nativeIoProcessEvents + 208 >> 41 Pharo 0x001418de ioProcessEvents + 35 >> 42 Pharo 0x000d5470 checkForEventsMayContextSwitch + 880 >> 43 Pharo 0x000d6cea ceCheckForInterrupts + 16 >> 44 ??? 0x0b0ad09b 0x0 + 185258139 >> 45 Pharo 0x000c31bc interpret + 647 >> 46 Pharo 0x001446ad -[sqSqueakMainApplication runSqueak] + 476 >> 47 Foundation 0x95ac4adb __NSFirePerformWithOrder + 419 >> 48 CoreFoundation 0x942811fe __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30 >> 49 CoreFoundation 0x94281157 __CFRunLoopDoObservers + 391 >> 50 CoreFoundation 0x942614a2 __CFRunLoopRun + 1058 >> 51 CoreFoundation 0x94260e1a CFRunLoopRunSpecific + 506 >> 52 CoreFoundation 0x94260c0b CFRunLoopRunInMode + 123 >> ... >>> 2017-05-24 22:28 GMT+02:00 Tudor Girba <[hidden email]>: >>> >>> 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." >>> >>> >>> >>> >>> >> >> >> >> >> >> >> -- >> =========================================================================== >> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk >> =========================================================================== > > > > > > -- > =========================================================================== > John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk > =========================================================================== |
In reply to this post by EstebanLM
Hi, > On May 28, 2017, at 9:34 PM, Esteban Lorenzano <[hidden email]> wrote: > > >> On 28 May 2017, at 20:40, John McIntosh <[hidden email]> wrote: >> >> Obviously I have to spend some time today to look at this problem. Do need to know if people are typing just plan english ascii characters, or? > > I guess is just plain english ascii chars. > Indeed, in my case, it is just plain English. Doru > Esteban > >> >> On Sun, May 28, 2017 at 10:02 AM, Nicolas Cellier <[hidden email]> wrote: >> >> >> >> 2017-05-28 18:44 GMT+02:00 Eliot Miranda <[hidden email]>: >> >> Hi Nicolas, >> >> On May 25, 2017, at 7:44 AM, Nicolas Cellier <[hidden email]> 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. >> >> is the crash in our event processing code or elsewhere? If elsewhere, where? >> >> >> Hi Eliot, >> the crash dump provided by Tudor shows: >> >> ...snip... >> 32 AppKit 0x9210cb20 -[NSView interpretKeyEvents:] + 192 >> 33 Pharo 0x0013f55e -[sqSqueakOSXOpenGLView keyDown:] + 310 >> 34 AppKit 0x928614bb -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 5876 >> 35 AppKit 0x9285fa49 -[NSWindow(NSEventRouting) sendEvent:] + 547 >> 36 AppKit 0x926ea6aa -[NSApplication(NSEvent) sendEvent:] + 3418 >> 37 Pharo 0x00137dcb -[SqueakOSXApplication sendEvent:] + 163 >> 38 Pharo 0x001399a4 -[sqSqueakOSXApplication(events) pumpRunLoopEventSendAndSignal:] + 115 >> 39 Pharo 0x00139a42 -[sqSqueakOSXApplication(events) pumpRunLoop] + 76 >> 40 Pharo 0x0014188a nativeIoProcessEvents + 208 >> 41 Pharo 0x001418de ioProcessEvents + 35 >> 42 Pharo 0x000d5470 checkForEventsMayContextSwitch + 880 >> 43 Pharo 0x000d6cea ceCheckForInterrupts + 16 >> 44 ??? 0x0b0ad09b 0x0 + 185258139 >> 45 Pharo 0x000c31bc interpret + 647 >> 46 Pharo 0x001446ad -[sqSqueakMainApplication runSqueak] + 476 >> 47 Foundation 0x95ac4adb __NSFirePerformWithOrder + 419 >> 48 CoreFoundation 0x942811fe __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30 >> 49 CoreFoundation 0x94281157 __CFRunLoopDoObservers + 391 >> 50 CoreFoundation 0x942614a2 __CFRunLoopRun + 1058 >> 51 CoreFoundation 0x94260e1a CFRunLoopRunSpecific + 506 >> 52 CoreFoundation 0x94260c0b CFRunLoopRunInMode + 123 >> ... >>> 2017-05-24 22:28 GMT+02:00 Tudor Girba <[hidden email]>: >>> >>> 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." >>> >>> >>> >>> >>> >> >> >> >> >> >> >> -- >> =========================================================================== >> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk >> =========================================================================== > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one." |
In reply to this post by johnmci
Hi John, all > On 28.05.2017, at 22:12, John McIntosh <[hidden email]> wrote: > > At commit point d0e7bfa0f8d99b856d9ac56372f7dacecdd63106 (5/5/17) Tobias added > > > NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) > location:[theEvent locationInWindow] > modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) > timestamp:[theEvent timestamp] > windowNumber:[theEvent windowNumber] > context:nil > characters:@"" > charactersIgnoringModifiers:@"" > isARepeat:NO > keyCode:[theEvent keyCode]]); > > in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent That's correct. > > However I believe this is incorrect as the NSEvent class side method is by the old non-arc memory rules implicitly an autoreleased object, so doing the AUTORELEASEOBJ() might cause side effects. https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html > > + (NSEvent *)keyEventWithType:(NSEventType)type location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum context:(NSGraphicsContext *)unusedPassNil characters:(NSString *)keys charactersIgnoringModifiers:(NSString *)ukeys isARepeat:(BOOL)flag keyCode:(unsigned short)code; Well, I have not found a reference to how this relates to autorelease (the Apple docs are becoming increasingly useless these days :() I read this https://developer.apple.com/reference/appkit/nsevent/1533943-keyeventwithtype?language=objc and the header /System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h and although autorelase pops up somewhere in the file, it does not somewhere near the declaration. I read through the code an found quite a few AUTORELEASEOBJ() around object creation and (apparently wrongly) thought I would need that here. I now understand that I should only autorelease alloc/inited stuff. So you may be right here. Fixed in 0f07ffbed Best regards -Tobias > > If Tobias can verify and submit a change we can see if that affects the behaviour we have been observing. Note that I"ve not been able to recreate the problem, but in eyeballing the code this leaps out as suspect. > > > On Sun, May 28, 2017 at 12:34 PM, Esteban Lorenzano <[hidden email]> wrote: > > >> On 28 May 2017, at 20:40, John McIntosh <[hidden email]> wrote: >> >> Obviously I have to spend some time today to look at this problem. Do need to know if people are typing just plan english ascii characters, or? > > I guess is just plain english ascii chars. > > Esteban > >> >> On Sun, May 28, 2017 at 10:02 AM, Nicolas Cellier <[hidden email]> wrote: >> >> >> >> 2017-05-28 18:44 GMT+02:00 Eliot Miranda <[hidden email]>: >> >> Hi Nicolas, >> >> On May 25, 2017, at 7:44 AM, Nicolas Cellier <[hidden email]> 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. >> >> is the crash in our event processing code or elsewhere? If elsewhere, where? >> >> >> Hi Eliot, >> the crash dump provided by Tudor shows: >> >> ...snip... >> 32 AppKit 0x9210cb20 -[NSView interpretKeyEvents:] + 192 >> 33 Pharo 0x0013f55e -[sqSqueakOSXOpenGLView keyDown:] + 310 >> 34 AppKit 0x928614bb -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 5876 >> 35 AppKit 0x9285fa49 -[NSWindow(NSEventRouting) sendEvent:] + 547 >> 36 AppKit 0x926ea6aa -[NSApplication(NSEvent) sendEvent:] + 3418 >> 37 Pharo 0x00137dcb -[SqueakOSXApplication sendEvent:] + 163 >> 38 Pharo 0x001399a4 -[sqSqueakOSXApplication(events) pumpRunLoopEventSendAndSignal:] + 115 >> 39 Pharo 0x00139a42 -[sqSqueakOSXApplication(events) pumpRunLoop] + 76 >> 40 Pharo 0x0014188a nativeIoProcessEvents + 208 >> 41 Pharo 0x001418de ioProcessEvents + 35 >> 42 Pharo 0x000d5470 checkForEventsMayContextSwitch + 880 >> 43 Pharo 0x000d6cea ceCheckForInterrupts + 16 >> 44 ??? 0x0b0ad09b 0x0 + 185258139 >> 45 Pharo 0x000c31bc interpret + 647 >> 46 Pharo 0x001446ad -[sqSqueakMainApplication runSqueak] + 476 >> 47 Foundation 0x95ac4adb __NSFirePerformWithOrder + 419 >> 48 CoreFoundation 0x942811fe __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30 >> 49 CoreFoundation 0x94281157 __CFRunLoopDoObservers + 391 >> 50 CoreFoundation 0x942614a2 __CFRunLoopRun + 1058 >> 51 CoreFoundation 0x94260e1a CFRunLoopRunSpecific + 506 >> 52 CoreFoundation 0x94260c0b CFRunLoopRunInMode + 123 >> ... >>> 2017-05-24 22:28 GMT+02:00 Tudor Girba <[hidden email]>: >>> >>> 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." >>> >>> >>> >>> >>> >> >> >> >> >> >> >> -- >> =========================================================================== >> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk >> =========================================================================== > > > > > > -- > =========================================================================== > John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk > =========================================================================== |
In reply to this post by Tudor Girba-2
Hi Doru, > Le 28 mai 2017 à 10:40, Tudor Girba <[hidden email]> 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 |
Free forum by Nabble | Edit this page |