Mac 10.7.5, COG 2693
When updating a fresh Squeak4.4-12327 Release to latest trunk, I get the following: Ken G. Brown ================================ 4 March 2013 10:45:55.288 am VM: Mac OS - Smalltalk Image: Squeak4.4 [latest update: #12327] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /myStuff/mySmalltalkStuff/Sqkb/<Sqkb4.x/Sqkb4.5Trunk Trusted Dir /foobar/tooBar/forSqueak/bogus/ Untrusted Dir /Users/kbrownht/Library/Preferences/Croquet/Internet/Untrusted SmallInteger(Object)>>doesNotUnderstand: #context Receiver: 976860964 Arguments and temporary variables: aMessage: context exception: MessageNotUnderstood: SmallInteger>>context resumeValue: nil Receiver's instance variables: 976860964 [] in Parser>>parse:cue:noPattern:ifFail: Receiver: a Parser Arguments and temporary variables: <<error during printing> Receiver's instance variables: source: a ReadStream 'installWebClient Installer ss project: ''WebClient'';...etc... mark: 20 hereChar: Character space aheadChar: $s token: 'Installer' tokenType: #word currentComment: nil buffer: a WriteStream 'Installer' typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... here: 'installWebClient' hereType: #word hereMark: 1 hereEnd: 16 prevMark: 1 prevEnd: nil encoder: {an EncoderForV3PlusClosures} parseNode: nil failBlock: [closure] in Parser>>parse:cue:noPattern:ifFail: requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: tempsMark: nil doitFlag: nil properties: false queriedUnusedTemporaries: nil cue: a CompilationCue BlockClosure>>on:do: Receiver: [closure] in Parser>>parse:cue:noPattern:ifFail: Arguments and temporary variables: exception: ReparseAfterSourceEditing handlerAction: [closure] in Parser>>parse:cue:noPattern:ifFail: handlerActive: true Receiver's instance variables: outerContext: Parser>>parse:cue:noPattern:ifFail: startpc: 196 numArgs: 0 Parser>>parse:cue:noPattern:ifFail: Receiver: a Parser Arguments and temporary variables: <<error during printing> Receiver's instance variables: source: a ReadStream 'installWebClient Installer ss project: ''WebClient'';...etc... mark: 20 hereChar: Character space aheadChar: $s token: 'Installer' tokenType: #word currentComment: nil buffer: a WriteStream 'Installer' typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... here: 'installWebClient' hereType: #word hereMark: 1 hereEnd: 16 prevMark: 1 prevEnd: nil encoder: {an EncoderForV3PlusClosures} parseNode: nil failBlock: [closure] in Parser>>parse:cue:noPattern:ifFail: requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: tempsMark: nil doitFlag: nil properties: false queriedUnusedTemporaries: nil cue: a CompilationCue Compiler>>translate:noPattern:ifFail: Receiver: a Compiler Arguments and temporary variables: aStream: a ReadStream 'installWebClient Installer ss project: ''WebClient''...etc... noPattern: false failBlock: [closure] in MethodAddition>>createCompiledMethod Receiver's instance variables: sourceStream: a ReadStream 'installWebClient Installer ss project: ''WebCli...etc... requestor: nil class: SMClient class category: #private context: nil parser: a Parser cue: a CompilationCue Compiler>>compile:in:classified:notifying:ifFail: Receiver: a Compiler Arguments and temporary variables: textOrStream: 'installWebClient Installer ss project: ''WebClient''; inst...etc... aClass: SMClient class aCategory: #private aRequestor: nil failBlock: [closure] in MethodAddition>>createCompiledMethod Receiver's instance variables: sourceStream: a ReadStream 'installWebClient Installer ss project: ''WebCli...etc... requestor: nil class: SMClient class category: #private context: nil parser: a Parser cue: a CompilationCue Metaclass(Behavior)>>compile:classified:notifying:trailer:ifFail: Receiver: SMClient class Arguments and temporary variables: code: 'installWebClient Installer ss project: ''WebClient''; install: ''W...etc... category: #private requestor: nil bytes: a CompiledMethodTrailer failBlock: [closure] in MethodAddition>>createCompiledMethod methodNode: nil Receiver's instance variables: superclass: Object class methodDict: a MethodDictionary(#assureWebClient->(SMClient class>>#assureWebCli...etc... format: 152 instanceVariables: nil organization: ('private' assureWebClient installWebClient) thisClass: SMClient MethodAddition>>createCompiledMethod Receiver: a MethodAddition Arguments and temporary variables: Receiver's instance variables: text: 'installWebClient Installer ss project: ''WebClient''; install: ''W...etc... category: #private changeStamp: 'fbs 2/25/2013 21:26' requestor: nil logSource: true myClass: SMClient class methodAndNode: nil selector: nil compiledMethod: nil priorMethodOrNil: nil [] in [] in [] in [] in MCPackageLoader>>basicLoad Receiver: a MCPackageLoader Arguments and temporary variables: <<error during printing> Receiver's instance variables: requirements: #() unloadableDefinitions: a SortedCollection() obsoletions: a Dictionary(a MCMethodDefinition(SMClient class>>installWebClient...etc... additions: an OrderedCollection(a MCOrganizationDefinition(#(#SMLoader)) a MCMe...etc... removals: an OrderedCollection() errorDefinitions: an OrderedCollection() provisions: a Set(#SMDefaultInstaller #FormTest #ClassListBrowser #HSVColorSele...etc... methodAdditions: an OrderedCollection(a MethodAddition) preamble: '========== SMLoader-fbs.78 ========== When installing WebClient, use...etc... [] in [] in OrderedCollection(Collection)>>do:displayingProgress:every: Receiver: an OrderedCollection(a MethodAddition) Arguments and temporary variables: <<error during printing> Receiver's instance variables: array: {a MethodAddition . nil . nil . nil . nil . nil . nil . nil . nil . nil}...etc... firstIndex: 1 lastIndex: 1 |
Ken, if you use Cog 2678, do you see the same problem?
frank On 4 March 2013 18:35, Ken G. Brown <[hidden email]> wrote: > Mac 10.7.5, COG 2693 > When updating a fresh Squeak4.4-12327 Release to latest trunk, I get the following: > Ken G. Brown > ================================ > 4 March 2013 10:45:55.288 am > > VM: Mac OS - Smalltalk > Image: Squeak4.4 [latest update: #12327] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir /myStuff/mySmalltalkStuff/Sqkb/<Sqkb4.x/Sqkb4.5Trunk > Trusted Dir /foobar/tooBar/forSqueak/bogus/ > Untrusted Dir /Users/kbrownht/Library/Preferences/Croquet/Internet/Untrusted > > SmallInteger(Object)>>doesNotUnderstand: #context > Receiver: 976860964 > Arguments and temporary variables: > aMessage: context > exception: MessageNotUnderstood: SmallInteger>>context > resumeValue: nil > Receiver's instance variables: > 976860964 > > [] in Parser>>parse:cue:noPattern:ifFail: > Receiver: a Parser > Arguments and temporary variables: > <<error during printing> > Receiver's instance variables: > source: a ReadStream 'installWebClient > Installer ss > project: ''WebClient'';...etc... > mark: 20 > hereChar: Character space > aheadChar: $s > token: 'Installer' > tokenType: #word > currentComment: nil > buffer: a WriteStream 'Installer' > typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... > here: 'installWebClient' > hereType: #word > hereMark: 1 > hereEnd: 16 > prevMark: 1 > prevEnd: nil > encoder: {an EncoderForV3PlusClosures} > parseNode: nil > failBlock: [closure] in Parser>>parse:cue:noPattern:ifFail: > requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: > tempsMark: nil > doitFlag: nil > properties: false > queriedUnusedTemporaries: nil > cue: a CompilationCue > > BlockClosure>>on:do: > Receiver: [closure] in Parser>>parse:cue:noPattern:ifFail: > Arguments and temporary variables: > exception: ReparseAfterSourceEditing > handlerAction: [closure] in Parser>>parse:cue:noPattern:ifFail: > handlerActive: true > Receiver's instance variables: > outerContext: Parser>>parse:cue:noPattern:ifFail: > startpc: 196 > numArgs: 0 > > Parser>>parse:cue:noPattern:ifFail: > Receiver: a Parser > Arguments and temporary variables: > <<error during printing> > Receiver's instance variables: > source: a ReadStream 'installWebClient > Installer ss > project: ''WebClient'';...etc... > mark: 20 > hereChar: Character space > aheadChar: $s > token: 'Installer' > tokenType: #word > currentComment: nil > buffer: a WriteStream 'Installer' > typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... > here: 'installWebClient' > hereType: #word > hereMark: 1 > hereEnd: 16 > prevMark: 1 > prevEnd: nil > encoder: {an EncoderForV3PlusClosures} > parseNode: nil > failBlock: [closure] in Parser>>parse:cue:noPattern:ifFail: > requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: > tempsMark: nil > doitFlag: nil > properties: false > queriedUnusedTemporaries: nil > cue: a CompilationCue > > Compiler>>translate:noPattern:ifFail: > Receiver: a Compiler > Arguments and temporary variables: > aStream: a ReadStream 'installWebClient > Installer ss > project: ''WebClient''...etc... > noPattern: false > failBlock: [closure] in MethodAddition>>createCompiledMethod > Receiver's instance variables: > sourceStream: a ReadStream 'installWebClient > Installer ss > project: ''WebCli...etc... > requestor: nil > class: SMClient class > category: #private > context: nil > parser: a Parser > cue: a CompilationCue > > Compiler>>compile:in:classified:notifying:ifFail: > Receiver: a Compiler > Arguments and temporary variables: > textOrStream: 'installWebClient > Installer ss > project: ''WebClient''; > inst...etc... > aClass: SMClient class > aCategory: #private > aRequestor: nil > failBlock: [closure] in MethodAddition>>createCompiledMethod > Receiver's instance variables: > sourceStream: a ReadStream 'installWebClient > Installer ss > project: ''WebCli...etc... > requestor: nil > class: SMClient class > category: #private > context: nil > parser: a Parser > cue: a CompilationCue > > Metaclass(Behavior)>>compile:classified:notifying:trailer:ifFail: > Receiver: SMClient class > Arguments and temporary variables: > code: 'installWebClient > Installer ss > project: ''WebClient''; > install: ''W...etc... > category: #private > requestor: nil > bytes: a CompiledMethodTrailer > failBlock: [closure] in MethodAddition>>createCompiledMethod > methodNode: nil > Receiver's instance variables: > superclass: Object class > methodDict: a MethodDictionary(#assureWebClient->(SMClient class>>#assureWebCli...etc... > format: 152 > instanceVariables: nil > organization: ('private' assureWebClient installWebClient) > > thisClass: SMClient > > MethodAddition>>createCompiledMethod > Receiver: a MethodAddition > Arguments and temporary variables: > > Receiver's instance variables: > text: 'installWebClient > Installer ss > project: ''WebClient''; > install: ''W...etc... > category: #private > changeStamp: 'fbs 2/25/2013 21:26' > requestor: nil > logSource: true > myClass: SMClient class > methodAndNode: nil > selector: nil > compiledMethod: nil > priorMethodOrNil: nil > > [] in [] in [] in [] in MCPackageLoader>>basicLoad > Receiver: a MCPackageLoader > Arguments and temporary variables: > <<error during printing> > Receiver's instance variables: > requirements: #() > unloadableDefinitions: a SortedCollection() > obsoletions: a Dictionary(a MCMethodDefinition(SMClient class>>installWebClient...etc... > additions: an OrderedCollection(a MCOrganizationDefinition(#(#SMLoader)) a MCMe...etc... > removals: an OrderedCollection() > errorDefinitions: an OrderedCollection() > provisions: a Set(#SMDefaultInstaller #FormTest #ClassListBrowser #HSVColorSele...etc... > methodAdditions: an OrderedCollection(a MethodAddition) > preamble: '========== SMLoader-fbs.78 ========== > When installing WebClient, use...etc... > > [] in [] in OrderedCollection(Collection)>>do:displayingProgress:every: > Receiver: an OrderedCollection(a MethodAddition) > Arguments and temporary variables: > <<error during printing> > Receiver's instance variables: > array: {a MethodAddition . nil . nil . nil . nil . nil . nil . nil . nil . nil}...etc... > firstIndex: 1 > lastIndex: 1 > > |
With COG 2678, pretty well the same. First attempt it timed out during the same update-nice-223, then trying again from what had already been loaded, got the following during the same update, during compiling SMLoader-fbs-78 as before:
From: [hidden email] To: [hidden email] Subject: [BUG]SmallInteger(Object)>>doesNotUnderstand: #context here insert explanation of what you were doing, suspect changes you've made and so forth. 4 March 2013 6:24:59.37 pm VM: Mac OS - Smalltalk Image: Squeak4.4 [latest update: #12327] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /myStuff/mySmalltalkStuff/Sqkb/<Sqkb4.x/Sqkb4.5Trunk Trusted Dir /foobar/tooBar/forSqueak/bogus/ Untrusted Dir /Users/kbrownht/Library/Preferences/Croquet/Internet/Untrusted SmallInteger(Object)>>doesNotUnderstand: #context Receiver: 976860964 Arguments and temporary variables: aMessage: context exception: MessageNotUnderstood: SmallInteger>>context resumeValue: nil Receiver's instance variables: 976860964 [] in Parser>>parse:cue:noPattern:ifFail: Receiver: a Parser Arguments and temporary variables: <<error during printing> Receiver's instance variables: source: a ReadStream 'installWebClient Installer ss project: ''WebClient'';...etc... mark: 20 hereChar: Character space aheadChar: $s token: 'Installer' tokenType: #word currentComment: nil buffer: a WriteStream 'Installer' typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... here: 'installWebClient' hereType: #word hereMark: 1 hereEnd: 16 prevMark: 1 prevEnd: nil encoder: {an EncoderForV3PlusClosures} parseNode: nil failBlock: nil requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: tempsMark: 0 doitFlag: nil properties: false queriedUnusedTemporaries: nil cue: nil BlockClosure>>on:do: Receiver: [closure] in Parser>>parse:cue:noPattern:ifFail: Arguments and temporary variables: exception: ReparseAfterSourceEditing handlerAction: [closure] in Parser>>parse:cue:noPattern:ifFail: handlerActive: true Receiver's instance variables: outerContext: Parser>>parse:cue:noPattern:ifFail: startpc: 196 numArgs: 0 Parser>>parse:cue:noPattern:ifFail: Receiver: a Parser Arguments and temporary variables: <<error during printing> Receiver's instance variables: source: a ReadStream 'installWebClient Installer ss project: ''WebClient'';...etc... mark: 20 hereChar: Character space aheadChar: $s token: 'Installer' tokenType: #word currentComment: nil buffer: a WriteStream 'Installer' typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... here: 'installWebClient' hereType: #word hereMark: 1 hereEnd: 16 prevMark: 1 prevEnd: nil encoder: {an EncoderForV3PlusClosures} parseNode: nil failBlock: nil requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: tempsMark: 0 doitFlag: nil properties: false queriedUnusedTemporaries: nil cue: nil Compiler>>translate:noPattern:ifFail: Receiver: a Compiler Arguments and temporary variables: aStream: a ReadStream 'installWebClient Installer ss project: ''WebClient''...etc... noPattern: false failBlock: [closure] in MethodAddition>>createCompiledMethod Receiver's instance variables: sourceStream: a ReadStream 'installWebClient Installer ss project: ''WebCli...etc... requestor: nil class: SMClient class category: #private context: nil parser: a Parser cue: a CompilationCue Compiler>>compile:in:classified:notifying:ifFail: Receiver: a Compiler Arguments and temporary variables: textOrStream: 'installWebClient Installer ss project: ''WebClient''; inst...etc... aClass: SMClient class aCategory: #private aRequestor: nil failBlock: [closure] in MethodAddition>>createCompiledMethod Receiver's instance variables: sourceStream: a ReadStream 'installWebClient Installer ss project: ''WebCli...etc... requestor: nil class: SMClient class category: #private context: nil parser: a Parser cue: a CompilationCue Metaclass(Behavior)>>compile:classified:notifying:trailer:ifFail: Receiver: SMClient class Arguments and temporary variables: code: 'installWebClient Installer ss project: ''WebClient''; install: ''W...etc... category: #private requestor: nil bytes: a CompiledMethodTrailer failBlock: [closure] in MethodAddition>>createCompiledMethod methodNode: nil Receiver's instance variables: superclass: Object class methodDict: a MethodDictionary(#assureWebClient->(SMClient class>>#assureWebCli...etc... format: 152 instanceVariables: nil organization: ('private' assureWebClient installWebClient) thisClass: SMClient MethodAddition>>createCompiledMethod Receiver: a MethodAddition Arguments and temporary variables: Receiver's instance variables: text: 'installWebClient Installer ss project: ''WebClient''; install: ''W...etc... category: #private changeStamp: 'fbs 2/25/2013 21:26' requestor: nil logSource: true myClass: SMClient class methodAndNode: nil selector: nil compiledMethod: nil priorMethodOrNil: nil On 2013-03-04, at 3:05 PM, Frank Shearar wrote: > Ken, if you use Cog 2678, do you see the same problem? > > frank > > On 4 March 2013 18:35, Ken G. Brown <[hidden email]> wrote: >> Mac 10.7.5, COG 2693 >> When updating a fresh Squeak4.4-12327 Release to latest trunk, I get the following: >> Ken G. Brown >> ================================ >> 4 March 2013 10:45:55.288 am >> >> VM: Mac OS - Smalltalk >> Image: Squeak4.4 [latest update: #12327] >> >> SecurityManager state: >> Restricted: false >> FileAccess: true >> SocketAccess: true >> Working Dir /myStuff/mySmalltalkStuff/Sqkb/<Sqkb4.x/Sqkb4.5Trunk >> Trusted Dir /foobar/tooBar/forSqueak/bogus/ >> Untrusted Dir /Users/kbrownht/Library/Preferences/Croquet/Internet/Untrusted >> >> SmallInteger(Object)>>doesNotUnderstand: #context >> Receiver: 976860964 >> Arguments and temporary variables: >> aMessage: context >> exception: MessageNotUnderstood: SmallInteger>>context >> resumeValue: nil >> Receiver's instance variables: >> 976860964 >> <snip> |
In reply to this post by Frank Shearar-3
Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to 12332, updating to Trunk fails at first attempt in the same place, then by abandoning and trying the update again, it apparently completes to 12511.
Ken G. Brown > With COG 2678, pretty well the same. First attempt it timed out during the same update-nice-223, then trying again from what had already been loaded, got the following during the same update, during compiling SMLoader-fbs-78 as before: > > From: [hidden email] > To: [hidden email] > Subject: [BUG]SmallInteger(Object)>>doesNotUnderstand: #context > > here insert explanation of what you were doing, suspect changes you've made and so forth. > > 4 March 2013 6:24:59.37 pm > > VM: Mac OS - Smalltalk > Image: Squeak4.4 [latest update: #12327] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir /myStuff/mySmalltalkStuff/Sqkb/<Sqkb4.x/Sqkb4.5Trunk > Trusted Dir /foobar/tooBar/forSqueak/bogus/ > Untrusted Dir /Users/kbrownht/Library/Preferences/Croquet/Internet/Untrusted > > SmallInteger(Object)>>doesNotUnderstand: #context > Receiver: 976860964 > Arguments and temporary variables: > aMessage: context > exception: MessageNotUnderstood: SmallInteger>>context > resumeValue: nil > Receiver's instance variables: > 976860964 > > [] in Parser>>parse:cue:noPattern:ifFail: > Receiver: a Parser > Arguments and temporary variables: > <<error during printing> > Receiver's instance variables: > source: a ReadStream 'installWebClient > Installer ss > project: ''WebClient'';...etc... > mark: 20 > hereChar: Character space > aheadChar: $s > token: 'Installer' > tokenType: #word > currentComment: nil > buffer: a WriteStream 'Installer' > typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... > here: 'installWebClient' > hereType: #word > hereMark: 1 > hereEnd: 16 > prevMark: 1 > prevEnd: nil > encoder: {an EncoderForV3PlusClosures} > parseNode: nil > failBlock: nil > requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: > tempsMark: 0 > doitFlag: nil > properties: false > queriedUnusedTemporaries: nil > cue: nil > > BlockClosure>>on:do: > Receiver: [closure] in Parser>>parse:cue:noPattern:ifFail: > Arguments and temporary variables: > exception: ReparseAfterSourceEditing > handlerAction: [closure] in Parser>>parse:cue:noPattern:ifFail: > handlerActive: true > Receiver's instance variables: > outerContext: Parser>>parse:cue:noPattern:ifFail: > startpc: 196 > numArgs: 0 > > Parser>>parse:cue:noPattern:ifFail: > Receiver: a Parser > Arguments and temporary variables: > <<error during printing> > Receiver's instance variables: > source: a ReadStream 'installWebClient > Installer ss > project: ''WebClient'';...etc... > mark: 20 > hereChar: Character space > aheadChar: $s > token: 'Installer' > tokenType: #word > currentComment: nil > buffer: a WriteStream 'Installer' > typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... > here: 'installWebClient' > hereType: #word > hereMark: 1 > hereEnd: 16 > prevMark: 1 > prevEnd: nil > encoder: {an EncoderForV3PlusClosures} > parseNode: nil > failBlock: nil > requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: > tempsMark: 0 > doitFlag: nil > properties: false > queriedUnusedTemporaries: nil > cue: nil > > Compiler>>translate:noPattern:ifFail: > Receiver: a Compiler > Arguments and temporary variables: > aStream: a ReadStream 'installWebClient > Installer ss > project: ''WebClient''...etc... > noPattern: false > failBlock: [closure] in MethodAddition>>createCompiledMethod > Receiver's instance variables: > sourceStream: a ReadStream 'installWebClient > Installer ss > project: ''WebCli...etc... > requestor: nil > class: SMClient class > category: #private > context: nil > parser: a Parser > cue: a CompilationCue > > Compiler>>compile:in:classified:notifying:ifFail: > Receiver: a Compiler > Arguments and temporary variables: > textOrStream: 'installWebClient > Installer ss > project: ''WebClient''; > inst...etc... > aClass: SMClient class > aCategory: #private > aRequestor: nil > failBlock: [closure] in MethodAddition>>createCompiledMethod > Receiver's instance variables: > sourceStream: a ReadStream 'installWebClient > Installer ss > project: ''WebCli...etc... > requestor: nil > class: SMClient class > category: #private > context: nil > parser: a Parser > cue: a CompilationCue > > Metaclass(Behavior)>>compile:classified:notifying:trailer:ifFail: > Receiver: SMClient class > Arguments and temporary variables: > code: 'installWebClient > Installer ss > project: ''WebClient''; > install: ''W...etc... > category: #private > requestor: nil > bytes: a CompiledMethodTrailer > failBlock: [closure] in MethodAddition>>createCompiledMethod > methodNode: nil > Receiver's instance variables: > superclass: Object class > methodDict: a MethodDictionary(#assureWebClient->(SMClient class>>#assureWebCli...etc... > format: 152 > instanceVariables: nil > organization: ('private' assureWebClient installWebClient) > > thisClass: SMClient > > MethodAddition>>createCompiledMethod > Receiver: a MethodAddition > Arguments and temporary variables: > > Receiver's instance variables: > text: 'installWebClient > Installer ss > project: ''WebClient''; > install: ''W...etc... > category: #private > changeStamp: 'fbs 2/25/2013 21:26' > requestor: nil > logSource: true > myClass: SMClient class > methodAndNode: nil > selector: nil > compiledMethod: nil > priorMethodOrNil: nil > > On 2013-03-04, at 3:05 PM, Frank Shearar wrote: > >> Ken, if you use Cog 2678, do you see the same problem? >> >> frank >> >> On 4 March 2013 18:35, Ken G. Brown <[hidden email]> wrote: >>> Mac 10.7.5, COG 2693 >>> When updating a fresh Squeak4.4-12327 Release to latest trunk, I get the following: >>> Ken G. Brown >>> ================================ >>> 4 March 2013 10:45:55.288 am >>> >>> VM: Mac OS - Smalltalk >>> Image: Squeak4.4 [latest update: #12327] >>> >>> SecurityManager state: >>> Restricted: false >>> FileAccess: true >>> SocketAccess: true >>> Working Dir /myStuff/mySmalltalkStuff/Sqkb/<Sqkb4.x/Sqkb4.5Trunk >>> Trusted Dir /foobar/tooBar/forSqueak/bogus/ >>> Untrusted Dir /Users/kbrownht/Library/Preferences/Croquet/Internet/Untrusted >>> >>> SmallInteger(Object)>>doesNotUnderstand: #context >>> Receiver: 976860964 >>> Arguments and temporary variables: >>> aMessage: context >>> exception: MessageNotUnderstood: SmallInteger>>context >>> resumeValue: nil >>> Receiver's instance variables: >>> 976860964 >>> <snip> > |
I can't help wondering if this is because of Nicolas' fun with the Parser?
frank On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: > Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to 12332, updating to Trunk fails at first attempt in the same place, then by abandoning and trying the update again, it apparently completes to 12511. > > Ken G. Brown > >> With COG 2678, pretty well the same. First attempt it timed out during the same update-nice-223, then trying again from what had already been loaded, got the following during the same update, during compiling SMLoader-fbs-78 as before: >> >> From: [hidden email] >> To: [hidden email] >> Subject: [BUG]SmallInteger(Object)>>doesNotUnderstand: #context >> >> here insert explanation of what you were doing, suspect changes you've made and so forth. >> >> 4 March 2013 6:24:59.37 pm >> >> VM: Mac OS - Smalltalk >> Image: Squeak4.4 [latest update: #12327] >> >> SecurityManager state: >> Restricted: false >> FileAccess: true >> SocketAccess: true >> Working Dir /myStuff/mySmalltalkStuff/Sqkb/<Sqkb4.x/Sqkb4.5Trunk >> Trusted Dir /foobar/tooBar/forSqueak/bogus/ >> Untrusted Dir /Users/kbrownht/Library/Preferences/Croquet/Internet/Untrusted >> >> SmallInteger(Object)>>doesNotUnderstand: #context >> Receiver: 976860964 >> Arguments and temporary variables: >> aMessage: context >> exception: MessageNotUnderstood: SmallInteger>>context >> resumeValue: nil >> Receiver's instance variables: >> 976860964 >> >> [] in Parser>>parse:cue:noPattern:ifFail: >> Receiver: a Parser >> Arguments and temporary variables: >> <<error during printing> >> Receiver's instance variables: >> source: a ReadStream 'installWebClient >> Installer ss >> project: ''WebClient'';...etc... >> mark: 20 >> hereChar: Character space >> aheadChar: $s >> token: 'Installer' >> tokenType: #word >> currentComment: nil >> buffer: a WriteStream 'Installer' >> typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... >> here: 'installWebClient' >> hereType: #word >> hereMark: 1 >> hereEnd: 16 >> prevMark: 1 >> prevEnd: nil >> encoder: {an EncoderForV3PlusClosures} >> parseNode: nil >> failBlock: nil >> requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: >> tempsMark: 0 >> doitFlag: nil >> properties: false >> queriedUnusedTemporaries: nil >> cue: nil >> >> BlockClosure>>on:do: >> Receiver: [closure] in Parser>>parse:cue:noPattern:ifFail: >> Arguments and temporary variables: >> exception: ReparseAfterSourceEditing >> handlerAction: [closure] in Parser>>parse:cue:noPattern:ifFail: >> handlerActive: true >> Receiver's instance variables: >> outerContext: Parser>>parse:cue:noPattern:ifFail: >> startpc: 196 >> numArgs: 0 >> >> Parser>>parse:cue:noPattern:ifFail: >> Receiver: a Parser >> Arguments and temporary variables: >> <<error during printing> >> Receiver's instance variables: >> source: a ReadStream 'installWebClient >> Installer ss >> project: ''WebClient'';...etc... >> mark: 20 >> hereChar: Character space >> aheadChar: $s >> token: 'Installer' >> tokenType: #word >> currentComment: nil >> buffer: a WriteStream 'Installer' >> typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... >> here: 'installWebClient' >> hereType: #word >> hereMark: 1 >> hereEnd: 16 >> prevMark: 1 >> prevEnd: nil >> encoder: {an EncoderForV3PlusClosures} >> parseNode: nil >> failBlock: nil >> requestorOffset: [closure] in Compiler>>translate:noPattern:ifFail: >> tempsMark: 0 >> doitFlag: nil >> properties: false >> queriedUnusedTemporaries: nil >> cue: nil >> >> Compiler>>translate:noPattern:ifFail: >> Receiver: a Compiler >> Arguments and temporary variables: >> aStream: a ReadStream 'installWebClient >> Installer ss >> project: ''WebClient''...etc... >> noPattern: false >> failBlock: [closure] in MethodAddition>>createCompiledMethod >> Receiver's instance variables: >> sourceStream: a ReadStream 'installWebClient >> Installer ss >> project: ''WebCli...etc... >> requestor: nil >> class: SMClient class >> category: #private >> context: nil >> parser: a Parser >> cue: a CompilationCue >> >> Compiler>>compile:in:classified:notifying:ifFail: >> Receiver: a Compiler >> Arguments and temporary variables: >> textOrStream: 'installWebClient >> Installer ss >> project: ''WebClient''; >> inst...etc... >> aClass: SMClient class >> aCategory: #private >> aRequestor: nil >> failBlock: [closure] in MethodAddition>>createCompiledMethod >> Receiver's instance variables: >> sourceStream: a ReadStream 'installWebClient >> Installer ss >> project: ''WebCli...etc... >> requestor: nil >> class: SMClient class >> category: #private >> context: nil >> parser: a Parser >> cue: a CompilationCue >> >> Metaclass(Behavior)>>compile:classified:notifying:trailer:ifFail: >> Receiver: SMClient class >> Arguments and temporary variables: >> code: 'installWebClient >> Installer ss >> project: ''WebClient''; >> install: ''W...etc... >> category: #private >> requestor: nil >> bytes: a CompiledMethodTrailer >> failBlock: [closure] in MethodAddition>>createCompiledMethod >> methodNode: nil >> Receiver's instance variables: >> superclass: Object class >> methodDict: a MethodDictionary(#assureWebClient->(SMClient class>>#assureWebCli...etc... >> format: 152 >> instanceVariables: nil >> organization: ('private' assureWebClient installWebClient) >> >> thisClass: SMClient >> >> MethodAddition>>createCompiledMethod >> Receiver: a MethodAddition >> Arguments and temporary variables: >> >> Receiver's instance variables: >> text: 'installWebClient >> Installer ss >> project: ''WebClient''; >> install: ''W...etc... >> category: #private >> changeStamp: 'fbs 2/25/2013 21:26' >> requestor: nil >> logSource: true >> myClass: SMClient class >> methodAndNode: nil >> selector: nil >> compiledMethod: nil >> priorMethodOrNil: nil >> >> On 2013-03-04, at 3:05 PM, Frank Shearar wrote: >> >>> Ken, if you use Cog 2678, do you see the same problem? >>> >>> frank >>> >>> On 4 March 2013 18:35, Ken G. Brown <[hidden email]> wrote: >>>> Mac 10.7.5, COG 2693 >>>> When updating a fresh Squeak4.4-12327 Release to latest trunk, I get the following: >>>> Ken G. Brown >>>> ================================ >>>> 4 March 2013 10:45:55.288 am >>>> >>>> VM: Mac OS - Smalltalk >>>> Image: Squeak4.4 [latest update: #12327] >>>> >>>> SecurityManager state: >>>> Restricted: false >>>> FileAccess: true >>>> SocketAccess: true >>>> Working Dir /myStuff/mySmalltalkStuff/Sqkb/<Sqkb4.x/Sqkb4.5Trunk >>>> Trusted Dir /foobar/tooBar/forSqueak/bogus/ >>>> Untrusted Dir /Users/kbrownht/Library/Preferences/Croquet/Internet/Untrusted >>>> >>>> SmallInteger(Object)>>doesNotUnderstand: #context >>>> Receiver: 976860964 >>>> Arguments and temporary variables: >>>> aMessage: context >>>> exception: MessageNotUnderstood: SmallInteger>>context >>>> resumeValue: nil >>>> Receiver's instance variables: >>>> 976860964 >>>> <snip> >> > |
On Wed, Mar 6, 2013 at 11:28 AM, Frank Shearar <[hidden email]> wrote: I can't help wondering if this is because of Nicolas' fun with the Parser? Yes it is. Â But the issue is what to do about it. Â I suspect a solution would be to have Monticello process class definitions that remove inst vars in two stages. Â One is to redefine classes with any added inst vars (before new methods are compiled). Â The next stage (as late as possible) is to redefine classes removing any inst vars.
best, Eliot
|
On 2013-03-06, at 21:37, Eliot Miranda <[hidden email]> wrote:
Well, you were supposed to put back the config map that solved this problem, after you debugged your Cog crash. Or am I misremembering? - Bert -
|
On 7 March 2013 11:02, Bert Freudenberg <[hidden email]> wrote:
> > On 2013-03-06, at 21:37, Eliot Miranda <[hidden email]> wrote: > > > > On Wed, Mar 6, 2013 at 11:28 AM, Frank Shearar <[hidden email]> > wrote: >> >> I can't help wondering if this is because of Nicolas' fun with the Parser? > > > Yes it is. But the issue is what to do about it. I suspect a solution > would be to have Monticello process class definitions that remove inst vars > in two stages. One is to redefine classes with any added inst vars (before > new methods are compiled). The next stage (as late as possible) is to > redefine classes removing any inst vars. > > > Well, you were supposed to put back the config map that solved this problem, > after you debugged your Cog crash. Or am I misremembering? > > - Bert - > > > >> >> frank >> >> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >> > Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >> > 12332, updating to Trunk fails at first attempt in the same place, then by >> > abandoning and trying the update again, it apparently completes to 12511. >> > >> > Ken G. Brown >> > >> >> With COG 2678, pretty well the same. First attempt it timed out during >> >> the same update-nice-223, then trying again from what had already been >> >> loaded, got the following during the same update, during compiling >> >> SMLoader-fbs-78 as before: What I find strange about all this is that we take a 4.4-12327 image and whatever the latest Cog is and update it all the way without any probems quite a few times a day on the CI server. frank |
On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote:
>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>> abandoning and trying the update again, it apparently completes to 12511. >>>> >>>> Ken G. Brown >>>> >>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>> the same update-nice-223, then trying again from what had already been >>>>> loaded, got the following during the same update, during compiling >>>>> SMLoader-fbs-78 as before: > > What I find strange about all this is that we take a 4.4-12327 image > and whatever the latest Cog is and update it all the way without any > probems quite a few times a day on the CI server. > > frank Looks like it's an intermittent problem, unfortunately: I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. BOOM. Cog crash. Didn't save the log unfortunately. Tried again. Update, switch to trunk, update again. No crash. What?! Once more. Update, switch to trunk, update. Crash! See below. Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. So it does crash, just not always. But it's been more than 50% in my case. - Bert - Process: Squeak [68769] Path: /Users/USER/Downloads/Squeak-4.4-All-In-One-Cog.app/Contents/MacOS/Squeak Identifier: org.squeak.SqueakAllInOne44 Version: 4.4 (3) Code Type: X86 (Native) Parent Process: launchd [268] User ID: 501 Date/Time: 2013-03-08 00:03:44.535 +0100 OS Version: Mac OS X 10.8.2 (12C60) Report Version: 10 Interval Since Last Report: 208172 sec Crashes Since Last Report: 5 Per-App Interval Since Last Report: 618 sec Per-App Crashes Since Last Report: 2 Anonymous UUID: FA9BEE03-D8B3-4810-7D6F-6242E90E317F Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000074786574 VM Regions Near 0x74786574: MALLOC_SMALL 000000002c800000-000000002d800000 [ 16.0M] rw-/rwx SM=PRV --> __TEXT 000000008feb0000-000000008fee3000 [ 204K] r-x/rwx SM=COW /usr/lib/dyld Application Specific Information: abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x94ddaa6a __pthread_kill + 10 1 libsystem_c.dylib 0x9a509acf pthread_kill + 101 2 libsystem_c.dylib 0x9a5404f8 abort + 168 3 org.squeak.SqueakAllInOne44 0x00070815 sigsegv + 341 4 libsystem_c.dylib 0x9a4f486b _sigtramp + 43 5 ??? 0xffffffff 0 + 4294967295 6 org.squeak.SqueakAllInOne44 0x000706c0 main + 1232 7 ??? 0x091e8181 0 + 152994177 8 ??? 0x09221264 0 + 153227876 9 ??? 0x092554b4 0 + 153441460 10 ??? 0x09253c61 0 + 153435233 11 ??? 0x092478fb 0 + 153385211 12 ??? 0x092537ee 0 + 153434094 Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x94ddb9ae kevent + 10 1 libdispatch.dylib 0x9885cc71 _dispatch_mgr_invoke + 993 2 libdispatch.dylib 0x9885c7a9 _dispatch_mgr_thread + 53 Thread 2: 0 libsystem_kernel.dylib 0x94ddac72 __semwait_signal + 10 1 libsystem_c.dylib 0x9a592a61 nanosleep$UNIX2003 + 189 2 org.squeak.SqueakAllInOne44 0x000ae17b beatStateMachine + 139 3 libsystem_c.dylib 0x9a508557 _pthread_start + 344 4 libsystem_c.dylib 0x9a4f2cee thread_start + 34 Thread 3: 0 libsystem_kernel.dylib 0x94ddb0ee __workq_kernreturn + 10 1 libsystem_c.dylib 0x9a50b04c _pthread_workq_return + 45 2 libsystem_c.dylib 0x9a50ae19 _pthread_wqthread + 448 3 libsystem_c.dylib 0x9a4f2cca start_wqthread + 30 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0xbffc187c ecx: 0xbffc140c edx: 0x94ddaa6a edi: 0xacdb4a28 esi: 0x00000006 ebp: 0xbffc1428 esp: 0xbffc140c ss: 0x00000023 efl: 0x00000206 eip: 0x94ddaa6a cs: 0x0000000b ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f cr2: 0x028cb000 Logical CPU: 0 Binary Images: 0x1000 - 0x124ff7 +org.squeak.SqueakAllInOne44 (4.4 - 3) <6C3D2199-9C7C-A57E-3481-B58CF72F08DA> /Users/USER/Downloads/Squeak-4.4-All-In-One-Cog.app/Contents/MacOS/Squeak 0x7f7000 - 0x7f8ff7 com.apple.carbonbundletemplate (1.01 - 1.0) <2DAE80C4-D737-2EB6-F2F4-976F1E94AEB6> /Users/USER/Downloads/Squeak-4.4-All-In-One-Cog.app/Contents/Resources/FloatArrayPlugin.bundle/Contents/MacOS/FloatArrayPlugin 0x3fe5000 - 0x3ff2ff3 com.apple.Librarian (1.1 - 1) <88A55A5E-40FF-3234-8394-2317120B79AB> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian 0x805c000 - 0x811aff3 ColorSyncDeprecated.dylib (400) <35E3054C-5DF1-30D4-A368-C4FDB0992373> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/Resources/ColorSyncDeprecated.dylib 0x815e000 - 0x815fffd com.apple.ironwoodcore (1.1.1 - 1.1.1) <098CE576-3239-3B41-9141-A5BE6E476C84> /System/Library/PrivateFrameworks/SpeechObjects.framework/Versions/A/Frameworks/DictationServicesCore.framework/DictationServicesCore 0x8feb0000 - 0x8fee2e57 dyld (210.2.3) <23516BE4-29BE-350C-91C9-F36E7999F0F1> /usr/lib/dyld 0x90007000 - 0x90007fff com.apple.Carbon (154 - 155) <604ADD9D-5835-3294-842E-3A4AEBCCB548> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x90008000 - 0x900bcfff com.apple.coreui (2.0 - 181.1) <C15ABF35-B7F5-34ED-A461-386DAF65D96B> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x900bd000 - 0x9015dff7 com.apple.QD (3.42 - 285) <1B8307C6-AFA8-312E-BA5B-679070EF2CA1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x903f8000 - 0x903f8fff libkeymgr.dylib (25) <D5E93F7F-9315-3AD6-92C7-941F7B54C490> /usr/lib/system/libkeymgr.dylib 0x903f9000 - 0x9040bfff libbsm.0.dylib (32) <DADD385E-FE53-3458-94FB-E316A6345108> /usr/lib/libbsm.0.dylib 0x9040c000 - 0x90413fff liblaunch.dylib (442.26.2) <310C99F8-0811-314D-9BB9-D0ED6DFA024B> /usr/lib/system/liblaunch.dylib 0x90414000 - 0x90420ffe libkxld.dylib (2050.18.24) <48A75AF6-9D5A-3552-948E-30A1682D3664> /usr/lib/system/libkxld.dylib 0x90ab0000 - 0x90b99ff7 libxml2.2.dylib (22.3) <015A4FA6-5BB9-3F95-AFB8-B9281E22685B> /usr/lib/libxml2.2.dylib 0x90b9c000 - 0x90beaffb libFontRegistry.dylib (100) <3B8350C2-4D8F-38C4-A22E-2F855D7E83D1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x90cc2000 - 0x90cc6fff com.apple.CommonPanels (1.2.5 - 94) <6B3E7E53-7708-3DA2-8C50-59C2B4735DE1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x90d04000 - 0x90d1dfff com.apple.Kerberos (2.0 - 1) <9BDE8F4D-DBC3-34D1-852C-898D3655A611> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x90d25000 - 0x90d2ffff libCSync.A.dylib (324.6) <D2E8AC70-C6D1-3C40-8A82-E50422EDCFBF> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x91068000 - 0x910adff5 com.apple.opencl (2.1.20 - 2.1.20) <41C4AE6E-67B6-33E2-A9B6-BF6F01580B16> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x910ae000 - 0x910b2ff7 libmacho.dylib (829) <5280A013-4F74-3F74-BE0C-7F612C49F1DC> /usr/lib/system/libmacho.dylib 0x910b3000 - 0x91102ff6 libTIFF.dylib (845) <989A2EB9-3A49-3157-8E9C-B16E6005BC64> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x91103000 - 0x91105fff com.apple.securityhi (4.0 - 55002) <62E3AE75-61CB-341E-B2A0-CFC985A2BF7F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x9110c000 - 0x91228ff7 com.apple.desktopservices (1.7.2 - 1.7.2) <8E74D101-8398-34F1-A463-B4950680A597> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x91342000 - 0x91383ff7 libcups.2.dylib (327) <F46F8703-FEAE-3442-87CB-45C8BF98BEE5> /usr/lib/libcups.2.dylib 0x91384000 - 0x91385fff libsystem_sandbox.dylib (220) <4E42390B-25EC-3530-AF01-337E430C16EB> /usr/lib/system/libsystem_sandbox.dylib 0x91386000 - 0x9138efff com.apple.CommerceCore (1.0 - 26) <AF0D1990-8CBF-3AB4-99DF-8B7AE14FB0D5> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore 0x91394000 - 0x9139bfff libsystem_dnssd.dylib (379.32.1) <6A505284-2382-3F27-B96F-15FFDACF004E> /usr/lib/system/libsystem_dnssd.dylib 0x9139c000 - 0x913c9ffe libsystem_m.dylib (3022.6) <9975D9C3-3B71-38E3-AA21-C5C5F9D9C431> /usr/lib/system/libsystem_m.dylib 0x913ca000 - 0x91432ff7 com.apple.framework.IOKit (2.0 - 755.18.10) <9A80E97E-544F-3A45-916D-6DB7ED217E33> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x91433000 - 0x9143bfff com.apple.DiskArbitration (2.5.1 - 2.5.1) <25A7232F-9B6A-3746-A3A8-12479D086B1E> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x9143c000 - 0x914b8ff3 com.apple.Metadata (10.7.0 - 707.3) <6B6A6216-23D0-34CE-8099-BEE9BA42501E> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x914b9000 - 0x91871ffa libLAPACK.dylib (1073.4) <9A6E5EAD-F2F2-3D5C-B655-2B536DB477F2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x91872000 - 0x91930ff3 com.apple.ColorSync (4.8.0 - 4.8.0) <EFEDCB37-4F20-3CEC-A185-5D2976E11BAC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x91931000 - 0x9198efff com.apple.audio.CoreAudio (4.1.0 - 4.1.0) <9549B81F-4425-34EE-802B-F462068DC0C5> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x9198f000 - 0x919bcffb com.apple.CoreServicesInternal (154.2 - 154.2) <DCCF604B-1DB8-3F09-8122-545E2E7F466D> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal 0x919bd000 - 0x91cc2ff7 com.apple.CoreServices.CarbonCore (1037.3 - 1037.3) <4571EDDC-704A-3FB1-B9A6-59870AA6165F> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x91d06000 - 0x91d09ff9 libCGXType.A.dylib (324.6) <3004616B-51F6-3B9D-8B85-DCCA3DF9BC10> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib 0x91d0a000 - 0x91d4cff7 libauto.dylib (185.1) <B2B5B639-6778-352A-828D-FD8B64A3E8B3> /usr/lib/libauto.dylib 0x91d4d000 - 0x91ff0ffb com.apple.CoreImage (8.2.2 - 1.0.1) <85BFFB09-D765-3F5F-AF65-FB136DDCAEF3> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage 0x91ff1000 - 0x92001ff2 com.apple.LangAnalysis (1.7.0 - 1.7.0) <875363E7-6D02-3229-A9DD-E5A5568A7D61> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x92053000 - 0x92086ff3 com.apple.GSS (3.0 - 2.0) <B1D719C1-B000-3BE3-B747-329D608585DD> /System/Library/Frameworks/GSS.framework/Versions/A/GSS 0x92087000 - 0x920f6ffb com.apple.Heimdal (3.0 - 2.0) <1ABF438B-30E6-3165-968C-E2EA1A9DF1FD> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal 0x920f7000 - 0x92105ff7 libz.1.dylib (43) <245F1B61-2276-3BBB-9891-99934116D833> /usr/lib/libz.1.dylib 0x92106000 - 0x9215dff7 com.apple.ScalableUserInterface (1.0 - 1) <2B5E454B-BC49-3E85-B54D-1950397C448C> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface 0x9215e000 - 0x9216aff7 com.apple.NetAuth (4.0 - 4.0) <4983C4B8-9D95-3C4D-897E-07743326487E> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth 0x922b3000 - 0x922dcfff libxslt.1.dylib (11.3) <0DE17DAA-66FF-3195-AADB-347BEB5E2EFA> /usr/lib/libxslt.1.dylib 0x922e2000 - 0x923efff3 com.apple.ImageIO.framework (3.2.0 - 845) <BF959BCB-C30A-3680-B7C2-91B327B2B63B> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x923f0000 - 0x9266cff7 com.apple.QuickTime (7.7.1 - 2599.13) <FE609160-E1EF-341D-9B6A-205D3E03A4D2> /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime 0x9266d000 - 0x9266ffff libCVMSPluginSupport.dylib (8.6.1) <8A174BD9-992E-351D-8F9A-DF6991723ABE> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib 0x92670000 - 0x9267cff8 libbz2.1.0.dylib (29) <7031A4C0-784A-3EAA-93DF-EA1F26CC9264> /usr/lib/libbz2.1.0.dylib 0x9267d000 - 0x926a1fff com.apple.PerformanceAnalysis (1.16 - 16) <18DE0F9F-1264-394D-AC56-6B2A1771DFBE> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis 0x926a2000 - 0x927a0ff7 libFontParser.dylib (84.5) <B3006327-7B2D-3966-A56A-BD85F1D71641> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x927a1000 - 0x92abeff3 com.apple.Foundation (6.8 - 945.11) <03B242AC-519C-3683-AA52-E73536B3D55F> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x92abf000 - 0x92ac0fff libdnsinfo.dylib (453.18) <41C7B8E2-2A81-31DE-BD8B-F0C29E169D4F> /usr/lib/system/libdnsinfo.dylib 0x92bea000 - 0x92c06ff7 libPng.dylib (845) <14C43094-C670-3575-BF9B-3A967E05EAC0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x92c84000 - 0x92c84ffd com.apple.audio.units.AudioUnit (1.8 - 1.8) <4C13DEA2-1EB0-3D06-901A-DB93184C06F0> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x92c85000 - 0x930a2fff FaceCoreLight (2.4.1) <571DE3F8-CA8A-3E71-9AF4-F06FFE721CE6> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight 0x93237000 - 0x9323afff com.apple.help (1.3.2 - 42) <AD7EB1F0-A068-3A2C-9D59-38E59CEC0D96> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x932f1000 - 0x932f7fff libGFXShared.dylib (8.6.1) <E32A7266-FCDD-352C-9C2A-8939265974AF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x932f8000 - 0x93481ff7 com.apple.vImage (6.0 - 6.0) <1D1F67FE-4F75-3689-BEF6-4A46C8039E70> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x93482000 - 0x9348dfff libcommonCrypto.dylib (60026) <A6C6EDB8-7E69-3827-81F3-9A74D0935461> /usr/lib/system/libcommonCrypto.dylib 0x9348e000 - 0x9348fffd libunc.dylib (25) <58599CBF-E262-3CEA-AFE1-35560E0177DC> /usr/lib/system/libunc.dylib 0x93490000 - 0x93493ff7 libcompiler_rt.dylib (30) <CE5DBDB4-0124-3E2B-9105-989DF98DD108> /usr/lib/system/libcompiler_rt.dylib 0x93494000 - 0x934ebff3 com.apple.HIServices (1.20 - 417) <561A770B-8523-3D09-A763-11F872779A4C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x934fb000 - 0x9393dfff com.apple.CoreGraphics (1.600.0 - 324.6) <66556166-F9A7-3EEC-A562-46061C7A79E4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x9393e000 - 0x93944fff com.apple.print.framework.Print (8.0 - 258) <12AEAD24-6924-3923-9E4A-C5D21231E639> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x93945000 - 0x93948ffc libpam.2.dylib (20) <FCF74195-A99E-3B07-8E49-688D4A6F1E18> /usr/lib/libpam.2.dylib 0x93949000 - 0x9394cff7 com.apple.TCC (1.0 - 1) <437D76CD-6437-3B55-BE2C-A53508858256> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC 0x94a02000 - 0x94a64fff libc++.1.dylib (65.1) <C0CFF9FF-5D52-3EAE-B921-6AE1DA00A135> /usr/lib/libc++.1.dylib 0x94a65000 - 0x94a6cffe com.apple.agl (3.2.1 - AGL-3.2.1) <8E0411D3-19F7-30E1-92A2-337F7F0EBCDA> /System/Library/Frameworks/AGL.framework/Versions/A/AGL 0x94ab5000 - 0x94ab5fff libsystem_blocks.dylib (59) <3A743C5D-CFA5-37D8-80A8-B6795A9DB04F> /usr/lib/system/libsystem_blocks.dylib 0x94ab6000 - 0x94d76fff com.apple.security (7.0 - 55179.1) <CB470E48-621B-34D9-9E78-8B773358CB6B> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x94db9000 - 0x94dbbfff libdyld.dylib (210.2.3) <05D6FF2A-F09B-309D-95F7-7AF10259C707> /usr/lib/system/libdyld.dylib 0x94dc6000 - 0x94de0ffc libsystem_kernel.dylib (2050.18.24) <C17D49D0-7961-3B67-B443-C788C6E5AA76> /usr/lib/system/libsystem_kernel.dylib 0x94e21000 - 0x94e21fff libSystem.B.dylib (169.3) <81C58EAB-0E76-3EAB-BDFD-C5A6FE95536F> /usr/lib/libSystem.B.dylib 0x94e22000 - 0x94e30ff3 libsystem_network.dylib (77.10) <7FBF5A15-97BA-3721-943E-E77F0C40DBE1> /usr/lib/system/libsystem_network.dylib 0x94e31000 - 0x94e97fff com.apple.print.framework.PrintCore (8.1 - 387.1) <F8CF762B-B707-3021-958F-BB8D33DB3576> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x94e98000 - 0x94e99fff libremovefile.dylib (23.1) <98622D14-DAAB-3AD8-A5D9-C322BF572A98> /usr/lib/system/libremovefile.dylib 0x94e9a000 - 0x94e9efff com.apple.IOSurface (86.0.3 - 86.0.3) <E3A4DB0A-1C1A-31E3-A550-5C0E1C874509> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x94e9f000 - 0x9505bffd libicucore.A.dylib (491.11.1) <B19E450A-BAF1-3967-9C95-7F77DC0B4639> /usr/lib/libicucore.A.dylib 0x9509f000 - 0x950adfff libxar.1.dylib (105) <343E4A3B-1D04-34A3-94C2-8C7C9A8F736B> /usr/lib/libxar.1.dylib 0x951bf000 - 0x951c0fff libDiagnosticMessagesClient.dylib (8) <39B3D25A-148A-3936-B800-0D393A00E64F> /usr/lib/libDiagnosticMessagesClient.dylib 0x951c1000 - 0x951cffff com.apple.opengl (1.8.6 - 1.8.6) <1AD1AE7B-B57B-35B5-B571-32A34F0DA737> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x958e3000 - 0x9597aff7 com.apple.ink.framework (10.8.2 - 150) <D90FF7BC-6B90-39F1-AC52-670269947C58> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x9597b000 - 0x95a86ff7 libJP2.dylib (845) <D409C913-6FA4-3D60-BFE0-B9FC6A02FEE0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib 0x95a87000 - 0x95accff7 com.apple.NavigationServices (3.7 - 200) <F6531764-6E43-3AF3-ACDD-8A5551EF016A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices 0x95acd000 - 0x95b11fff libGLU.dylib (8.6.1) <06BAFDCA-800C-35E3-B1A3-F05E105B86AB> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x95b12000 - 0x95c5fffb com.apple.CFNetwork (596.2.3 - 596.2.3) <1221EF86-659B-3136-AB57-0CC6B130CDA2> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x95c60000 - 0x95d51ffc libiconv.2.dylib (34) <B096A9B7-83A6-31B3-8D2F-87D91910BF4C> /usr/lib/libiconv.2.dylib 0x95d52000 - 0x95d71ff3 com.apple.Ubiquity (1.2 - 243.10) <D2C9F356-1681-31D2-B292-5227E2DDEB0B> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity 0x95d93000 - 0x95db1ff3 com.apple.openscripting (1.3.6 - 148.2) <55738D66-CC15-3F43-9265-00C3322D39C4> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x95db2000 - 0x95e16fff com.apple.datadetectorscore (4.0 - 269.1) <4D155F09-1A60-325A-BCAC-1B858C2C051B> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore 0x95e17000 - 0x95e59ffb com.apple.RemoteViewServices (2.0 - 80.5) <60E04F2F-AFD8-3B1F-BF07-8A3A7EABB8E9> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices 0x95fc2000 - 0x960fdff7 libBLAS.dylib (1073.4) <FF74A147-05E1-37C4-BC10-7DEB57FE5326> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x96148000 - 0x96150fff libcopyfile.dylib (89) <4963541B-0254-371B-B29A-B6806888949B> /usr/lib/system/libcopyfile.dylib 0x961b8000 - 0x961bbffd libCoreVMClient.dylib (24.4) <C54E8FD0-61EC-3DC8-8631-54288AC66AC8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x961bc000 - 0x9620aff3 com.apple.SystemConfiguration (1.12.2 - 1.12.2) <7BA6C58B-0357-356F-BB69-17ACB5E35988> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x9659f000 - 0x965acff7 com.apple.AppleFSCompression (49 - 1.0) <166AA1F8-E50A-3533-A3B5-8737C5118CC3> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression 0x965ad000 - 0x965cafff libCRFSuite.dylib (33) <C9D72D0C-871A-39A2-8AFB-682D11AE7D0D> /usr/lib/libCRFSuite.dylib 0x965cb000 - 0x96640ff7 com.apple.ApplicationServices.ATS (332 - 341.1) <95206704-F9C9-33C4-AF25-FE9890E160B2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x96ef4000 - 0x96f2ffe7 libGLImage.dylib (8.6.1) <A3442557-18D5-332E-8859-423D5A20EBBE> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x96f30000 - 0x96fc2ffb libvMisc.dylib (380.6) <6DA3A03F-20BE-300D-A664-B50A7B4E4B1A> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x96fc3000 - 0x96fe3ffd com.apple.ChunkingLibrary (2.0 - 133.2) <FE5F0F1E-B15D-3F76-8655-DC2FE19BF56E> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary 0x96fe4000 - 0x97093ff7 com.apple.CoreText (260.0 - 275.16) <873ADCD9-D361-3753-A220-CDD289196AD8> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 0x97094000 - 0x970bdff7 libRIP.A.dylib (324.6) <7976E6A2-A489-33F5-A727-7634DDE3B761> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x970be000 - 0x970caffa com.apple.CrashReporterSupport (10.8.2 - 415) <BAE9900A-51E7-3AD4-A7FB-7E6CCFFB2F21> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport 0x970d2000 - 0x970d2fff com.apple.CoreServices (57 - 57) <956C6C6D-A5DD-314F-9C57-4A61D41F30CE> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x970d3000 - 0x970d5ffb libRadiance.dylib (845) <3F87840F-217D-3074-A29D-919BAAED2F4A> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x970d6000 - 0x97122fff libcorecrypto.dylib (106.2) <20EBADBA-D6D6-36F0-AE80-168E9AF13DB6> /usr/lib/system/libcorecrypto.dylib 0x97123000 - 0x9719dff7 com.apple.securityfoundation (6.0 - 55115.4) <A959B2F5-9D9D-3C93-A62A-7399594CF238> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x97227000 - 0x97280fff com.apple.AE (645.3 - 645.3) <6745659F-006D-3F25-94D6-DF944E9A01FD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x97281000 - 0x9729eff7 libresolv.9.dylib (51) <B9742A2A-DF15-3F6E-8FCE-778A58214B3A> /usr/lib/libresolv.9.dylib 0x972d3000 - 0x972ddfff libsystem_notify.dylib (98.5) <7EEE9475-18F8-3099-B0ED-23A3E528ABE0> /usr/lib/system/libsystem_notify.dylib 0x972e1000 - 0x9733cfff com.apple.htmlrendering (77 - 1.1.4) <5C0C669F-AE07-3983-B38F-EB829B5CE609> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering 0x97380000 - 0x97763ff3 com.apple.HIToolbox (2.0 - 625) <5A312E41-9940-363E-B891-90C4672E6850> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x9788d000 - 0x9799a057 libobjc.A.dylib (532.2) <FA455371-7395-3D58-A89B-D1520612D1BC> /usr/lib/libobjc.A.dylib 0x9799b000 - 0x979bffff libJPEG.dylib (845) <547FA9A5-0BBB-3E39-BACA-F3E2DAE57DB0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x97c19000 - 0x97c20ffb libunwind.dylib (35.1) <E1E8D8B3-3C78-3AB1-B398-C180DC6DCF05> /usr/lib/system/libunwind.dylib 0x97c21000 - 0x97c2affd com.apple.audio.SoundManager (4.0 - 4.0) <ABC5FE40-B222-36EB-9905-5C8C4BFD8C87> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound 0x97c2b000 - 0x97c2bfff com.apple.ApplicationServices (45 - 45) <677C4ACC-9D12-366F-8A87-B898AC806DD9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x97c2c000 - 0x987e8ffb com.apple.AppKit (6.8 - 1187.34) <06EDB1D1-3B8A-3699-8E3A-D8F50A27AB7C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x987e9000 - 0x9881fffb com.apple.DebugSymbols (98 - 98) <9A9ADA0A-E487-3C8F-9998-286EE04C235A> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols 0x98820000 - 0x98836fff com.apple.CFOpenDirectory (10.8 - 151.10) <56C3F276-BD1F-3031-8CF9-8F4F481A534E> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x9883e000 - 0x98855fff com.apple.GenerationalStorage (1.1 - 132.2) <93694E0D-35D3-3633-976E-F354CBD92F54> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage 0x98856000 - 0x98857fff liblangid.dylib (116) <E13CC8C5-5034-320A-A210-41A2BDE4F846> /usr/lib/liblangid.dylib 0x98858000 - 0x9886aff7 libdispatch.dylib (228.23) <86EF7D45-2D97-3465-A449-95038AE5DABA> /usr/lib/system/libdispatch.dylib 0x9886b000 - 0x98903fff com.apple.CoreServices.OSServices (557.4 - 557.4) <C724AB29-A596-3E1E-9FF1-A4E509AD843A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x98904000 - 0x98a7cff5 com.apple.QuartzCore (1.8 - 304.0) <0B0EC55A-9084-3E28-9A84-1813CE3FAA9B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x98a7d000 - 0x98a7dfff com.apple.Accelerate (1.8 - Accelerate 1.8) <4EC0548E-3A3F-310D-A366-47B51D5B6398> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x98a7e000 - 0x98b52fff com.apple.backup.framework (1.4.1 - 1.4.1) <55F2A679-9B21-3F43-A580-4C2ECF6A5FC5> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup 0x98b79000 - 0x98d90fff com.apple.CoreData (106.1 - 407.7) <17FD06D6-AD7C-345A-8FA4-1F0FBFF4DAE1> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x98d91000 - 0x98daefff libxpc.dylib (140.41) <1BFE3149-C242-3A77-9729-B00DEDC8CCF2> /usr/lib/system/libxpc.dylib 0x9903c000 - 0x99046ffe com.apple.bsd.ServiceManagement (2.0 - 2.0) <9732BA61-D6F6-3644-82DA-FF0D6FEEFC69> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement 0x990c1000 - 0x990d6fff com.apple.ImageCapture (8.0 - 8.0) <B8BD421F-D5A9-3FB4-8E89-AD5CFC0D4030> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x990d7000 - 0x990deff3 com.apple.NetFS (5.0 - 4.0) <1F7041F2-4E97-368C-8F5D-24153D81BBDB> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x990df000 - 0x99104ffb com.apple.framework.familycontrols (4.1 - 410) <5A8504E7-D95D-3101-8E20-38EADE8DEAE1> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls 0x99105000 - 0x99118ff9 com.apple.MultitouchSupport.framework (235.28 - 235.28) <5C8CFA21-D4FC-32E8-B199-0F7155E6ED9A> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x9916a000 - 0x99177fff libGL.dylib (8.6.1) <C7A3917A-C444-33CC-8599-BB9CD8C12BC4> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x991dc000 - 0x992d4ff9 libsqlite3.dylib (138.1) <AD7C5914-35F0-37A3-9238-A29D2E26C755> /usr/lib/libsqlite3.dylib 0x992d5000 - 0x992d9ffe libcache.dylib (57) <834FDCA7-FE3B-33CC-A12A-E11E202477EC> /usr/lib/system/libcache.dylib 0x996d7000 - 0x99731fff com.apple.Symbolication (1.3 - 93) <684ECF0D-D416-3DF8-8B5B-3902953853A8> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication 0x997eb000 - 0x997f4ff9 com.apple.CommonAuth (3.0 - 2.0) <A1A6CC3D-AA88-3519-A305-9B5D76C5D63B> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth 0x997f5000 - 0x99834ff7 com.apple.bom (12.0 - 192) <0637E52C-D151-37B3-904F-8656B2FD44DD> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom 0x99835000 - 0x99a1dff3 com.apple.CoreFoundation (6.8 - 744.12) <E939CEA0-493C-3233-9983-5070981BB350> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x99a2a000 - 0x99a56ff7 libsystem_info.dylib (406.17) <AA5611DB-A944-3072-B6BE-ACAB08689547> /usr/lib/system/libsystem_info.dylib 0x99a65000 - 0x99a6ffff com.apple.speech.recognition.framework (4.1.5 - 4.1.5) <B855E8B4-2EE3-3BFF-8547-98A0F084F9AF> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x99a70000 - 0x99a71fff libquarantine.dylib (52) <D526310F-DC77-37EA-8F5F-83928EFA3262> /usr/lib/system/libquarantine.dylib 0x99deb000 - 0x99debfff com.apple.vecLib (3.8 - vecLib 3.8) <83160DD1-5614-3E34-80EB-97041016EF1F> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x99dec000 - 0x99e50ff3 libstdc++.6.dylib (56) <F8FA490A-8F3C-3645-ABF5-78926CE9C62C> /usr/lib/libstdc++.6.dylib 0x99e51000 - 0x99e51fff com.apple.Accelerate.vecLib (3.8 - vecLib 3.8) <908B8D40-3FB5-3047-B482-3DF95025ECFC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x99e52000 - 0x99ebafe7 libvDSP.dylib (380.6) <55780308-4DCA-3B10-9703-EAFC3E13A3FA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x99ebb000 - 0x99ebbffd libOpenScriptingUtil.dylib (148.2) <907E25B1-4F50-3461-B8D5-733C687EB534> /usr/lib/libOpenScriptingUtil.dylib 0x99ebc000 - 0x99ed1fff com.apple.speech.synthesis.framework (4.1.12 - 4.1.12) <DE68CEB5-4959-3652-83B8-D2B00D3B932D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x99fc0000 - 0x9a045ff7 com.apple.SearchKit (1.4.0 - 1.4.0) <454E950F-291C-3E95-8F35-05CA0AD6B327> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x9a277000 - 0x9a3cfffb com.apple.audio.toolbox.AudioToolbox (1.8 - 1.8) <9205DFC2-8DAE-354E-AD87-46E229B5F2F1> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x9a3d0000 - 0x9a3f2fff libc++abi.dylib (24.4) <06479DA4-BC23-34B6-BAFC-A885814261D0> /usr/lib/libc++abi.dylib 0x9a3f3000 - 0x9a418ff7 com.apple.CoreVideo (1.8 - 99.3) <5B872AC0-E82D-3475-A3F9-FD95F380560D> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x9a419000 - 0x9a41dfff com.apple.OpenDirectory (10.8 - 151.10) <A1858D81-086F-3BF5-87E3-9B70409FFDF6> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x9a41e000 - 0x9a44ffff com.apple.DictionaryServices (1.2 - 184.4) <0D5BE86F-F40A-3E39-8569-19FCA5EDF9D3> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x9a450000 - 0x9a451ffd com.apple.TrustEvaluationAgent (2.0 - 23) <E42347C0-2D3C-36A4-9200-757FFA61B388> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x9a452000 - 0x9a456ffc libGIF.dylib (845) <714E9F0D-D7A3-3F58-B46E-FCBE0F144B23> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x9a457000 - 0x9a4f1fff com.apple.CoreSymbolication (3.0 - 87) <6A27BBE5-6EF0-3D5D-A485-2145826B9796> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication 0x9a4f2000 - 0x9a5affeb libsystem_c.dylib (825.25) <B1F6916A-F558-38B5-A18C-D9733625FDC9> /usr/lib/system/libsystem_c.dylib 0x9a5b0000 - 0x9a65afff com.apple.LaunchServices (539.7 - 539.7) <AF33EBD3-BC0B-30B5-B7DA-5CCCF12D7EDD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 2 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 42149 thread_create: 1 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=119.5M resident=61.8M(52%) swapped_out_or_unallocated=57.7M(48%) Writable regions: Total=695.2M written=2824K(0%) resident=67.7M(10%) swapped_out=0K(0%) unallocated=627.4M(90%) REGION TYPE VIRTUAL =========== ======= (null) (reserved) 384.0M reserved VM address space (unallocated) ATS (font support) 32.1M ATS (font support) (reserved) 4K reserved VM address space (unallocated) CG backing stores 3360K CG shared images 288K CoreServices 15.9M MALLOC 105.9M MALLOC guard page 48K Memory tag=240 4K Memory tag=242 12K Memory tag=243 4K Memory tag=35 7088K Stack 65.5M VM_ALLOCATE 144.1M __DATA 5716K __DATA/__OBJC 112K __IMAGE 528K __LINKEDIT 31.8M __OBJC 1600K __OBJC/__DATA 12K __PAGEZERO 4K __TEXT 87.7M __UNICODE 544K mapped file 120.3M shared memory 308K =========== ======= TOTAL 1.0G TOTAL, minus reserved VM space 622.4M |
On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote:
> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: > >>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>> >>>>> Ken G. Brown >>>>> >>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>> the same update-nice-223, then trying again from what had already been >>>>>> loaded, got the following during the same update, during compiling >>>>>> SMLoader-fbs-78 as before: >> >> What I find strange about all this is that we take a 4.4-12327 image >> and whatever the latest Cog is and update it all the way without any >> probems quite a few times a day on the CI server. >> >> frank > > Looks like it's an intermittent problem, unfortunately: > > I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. > > I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. > > BOOM. Cog crash. Didn't save the log unfortunately. > > Tried again. Update, switch to trunk, update again. No crash. What?! > > Once more. Update, switch to trunk, update. Crash! See below. > > Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. > > So it does crash, just not always. But it's been more than 50% in my case. Ah, interesting. The CI jobs, naturally, don't update from squeak44; they switch to trunk and update just like that. Which I would have thought would make no difference... frank > - Bert - |
On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote:
> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >> >>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>> >>>>>> Ken G. Brown >>>>>> >>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>> loaded, got the following during the same update, during compiling >>>>>>> SMLoader-fbs-78 as before: >>> >>> What I find strange about all this is that we take a 4.4-12327 image >>> and whatever the latest Cog is and update it all the way without any >>> probems quite a few times a day on the CI server. >>> >>> frank >> >> Looks like it's an intermittent problem, unfortunately: >> >> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >> >> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >> >> BOOM. Cog crash. Didn't save the log unfortunately. >> >> Tried again. Update, switch to trunk, update again. No crash. What?! >> >> Once more. Update, switch to trunk, update. Crash! See below. >> >> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >> >> So it does crash, just not always. But it's been more than 50% in my case. > > Ah, interesting. The CI jobs, naturally, don't update from squeak44; > they switch to trunk and update just like that. Which I would have > thought would make no difference... Actually, I lie. Here's an example of the CI jobs hitting the same issue: http://build.squeak.org/job/SqueakTrunk/204/console And further if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to see the failing tests you'll see times (say around build #184) where the test failure count is unusually low. And http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey streaks where builds die. frank > frank > >> - Bert - |
On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: > On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>> >>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>> >>>>>>> Ken G. Brown >>>>>>> >>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>> SMLoader-fbs-78 as before: >>>> >>>> What I find strange about all this is that we take a 4.4-12327 image >>>> and whatever the latest Cog is and update it all the way without any >>>> probems quite a few times a day on the CI server. >>>> >>>> frank >>> >>> Looks like it's an intermittent problem, unfortunately: >>> >>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>> >>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>> >>> BOOM. Cog crash. Didn't save the log unfortunately. >>> >>> Tried again. Update, switch to trunk, update again. No crash. What?! >>> >>> Once more. Update, switch to trunk, update. Crash! See below. >>> >>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>> >>> So it does crash, just not always. But it's been more than 50% in my case. >> >> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >> they switch to trunk and update just like that. Which I would have >> thought would make no difference... > > Actually, I lie. Here's an example of the CI jobs hitting the same > issue: http://build.squeak.org/job/SqueakTrunk/204/console And further > if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to > see the failing tests you'll see times (say around build #184) where > the test failure count is unusually low. And > http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey > streaks where builds die. Curious that it still runs the tests at all if the update failed ... So Cog crashes, but has someone tried to replicate this on an interpreter? - Bert - |
2013/3/8 Bert Freudenberg <[hidden email]>:
> > On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: > >> On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >>> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>>> >>>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>>> >>>>>>>> Ken G. Brown >>>>>>>> >>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>>> SMLoader-fbs-78 as before: >>>>> >>>>> What I find strange about all this is that we take a 4.4-12327 image >>>>> and whatever the latest Cog is and update it all the way without any >>>>> probems quite a few times a day on the CI server. >>>>> >>>>> frank >>>> >>>> Looks like it's an intermittent problem, unfortunately: >>>> >>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>>> >>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>>> >>>> BOOM. Cog crash. Didn't save the log unfortunately. >>>> >>>> Tried again. Update, switch to trunk, update again. No crash. What?! >>>> >>>> Once more. Update, switch to trunk, update. Crash! See below. >>>> >>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>>> >>>> So it does crash, just not always. But it's been more than 50% in my case. >>> >>> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >>> they switch to trunk and update just like that. Which I would have >>> thought would make no difference... >> >> Actually, I lie. Here's an example of the CI jobs hitting the same >> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further >> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to >> see the failing tests you'll see times (say around build #184) where >> the test failure count is unusually low. And >> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey >> streaks where builds die. > > Curious that it still runs the tests at all if the update failed ... > > So Cog crashes, but has someone tried to replicate this on an interpreter? > > - Bert - > I think that the problem comes form COG which tries to use an obsolete method sent AFTER the recompilation of Parser which is not the expected behavior. I have triggered such kind of strange behavior that does not happen on an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog VM Crash on Windows' For me, it must be related to a cache that is not cleaned-up, I don't know why. Nicolas |
OK, see the VM thread, I now think that problems does not come from
COG, but from ClassBuilder which in some cases fail to clean a cache (primitive 116). The problem does not show up in interpreter VM thanks to primitive 119 (this primitives does not unlink send in cogit). I have attempted a ClassBuilder fix and posted new updates from nice-222 to cwp-227. Can I please ask our testers contribution once again? Nicolas 2013/3/8 Nicolas Cellier <[hidden email]>: > 2013/3/8 Bert Freudenberg <[hidden email]>: >> >> On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: >> >>> On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >>>> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>>>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>>>> >>>>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>>>> >>>>>>>>> Ken G. Brown >>>>>>>>> >>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>>>> SMLoader-fbs-78 as before: >>>>>> >>>>>> What I find strange about all this is that we take a 4.4-12327 image >>>>>> and whatever the latest Cog is and update it all the way without any >>>>>> probems quite a few times a day on the CI server. >>>>>> >>>>>> frank >>>>> >>>>> Looks like it's an intermittent problem, unfortunately: >>>>> >>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>>>> >>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>>>> >>>>> BOOM. Cog crash. Didn't save the log unfortunately. >>>>> >>>>> Tried again. Update, switch to trunk, update again. No crash. What?! >>>>> >>>>> Once more. Update, switch to trunk, update. Crash! See below. >>>>> >>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>>>> >>>>> So it does crash, just not always. But it's been more than 50% in my case. >>>> >>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >>>> they switch to trunk and update just like that. Which I would have >>>> thought would make no difference... >>> >>> Actually, I lie. Here's an example of the CI jobs hitting the same >>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further >>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to >>> see the failing tests you'll see times (say around build #184) where >>> the test failure count is unusually low. And >>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey >>> streaks where builds die. >> >> Curious that it still runs the tests at all if the update failed ... >> >> So Cog crashes, but has someone tried to replicate this on an interpreter? >> >> - Bert - >> > > I think that the problem comes form COG which tries to use an obsolete > method sent AFTER the recompilation of Parser which is not the > expected behavior. > I have triggered such kind of strange behavior that does not happen on > an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog > VM Crash on Windows' > For me, it must be related to a cache that is not cleaned-up, I don't know why. > > Nicolas |
http://build.squeak.org/job/SqueakTrunk-OSX/88/ shows things working,
and the trend shows that the Mac Cog seems to have always been OK. http://build.squeak.org/job/SqueakTrunk/212/ shows bad things still happening with the Parser. If you look at the test history (show test failures only on http://build.squeak.org/job/SqueakTrunk/) you'll see this bug's biting hard - all the only-2-failing-test builds exhibit the behaviour. (Why do the tests run at all when it's a failing update? I _think_ that's because the build script is insufficiently suicidal, and ends up running a TrunkImage from a previous build.) frank On 10 March 2013 19:10, Nicolas Cellier <[hidden email]> wrote: > OK, see the VM thread, I now think that problems does not come from > COG, but from ClassBuilder which in some cases fail to clean a cache > (primitive 116). > The problem does not show up in interpreter VM thanks to primitive 119 > (this primitives does not unlink send in cogit). > I have attempted a ClassBuilder fix and posted new updates from > nice-222 to cwp-227. > > Can I please ask our testers contribution once again? > > Nicolas > > 2013/3/8 Nicolas Cellier <[hidden email]>: >> 2013/3/8 Bert Freudenberg <[hidden email]>: >>> >>> On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: >>> >>>> On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >>>>> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>>>>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>>>>> >>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>>>>> >>>>>>>>>> Ken G. Brown >>>>>>>>>> >>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>>>>> SMLoader-fbs-78 as before: >>>>>>> >>>>>>> What I find strange about all this is that we take a 4.4-12327 image >>>>>>> and whatever the latest Cog is and update it all the way without any >>>>>>> probems quite a few times a day on the CI server. >>>>>>> >>>>>>> frank >>>>>> >>>>>> Looks like it's an intermittent problem, unfortunately: >>>>>> >>>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>>>>> >>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>>>>> >>>>>> BOOM. Cog crash. Didn't save the log unfortunately. >>>>>> >>>>>> Tried again. Update, switch to trunk, update again. No crash. What?! >>>>>> >>>>>> Once more. Update, switch to trunk, update. Crash! See below. >>>>>> >>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>>>>> >>>>>> So it does crash, just not always. But it's been more than 50% in my case. >>>>> >>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >>>>> they switch to trunk and update just like that. Which I would have >>>>> thought would make no difference... >>>> >>>> Actually, I lie. Here's an example of the CI jobs hitting the same >>>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further >>>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to >>>> see the failing tests you'll see times (say around build #184) where >>>> the test failure count is unusually low. And >>>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey >>>> streaks where builds die. >>> >>> Curious that it still runs the tests at all if the update failed ... >>> >>> So Cog crashes, but has someone tried to replicate this on an interpreter? >>> >>> - Bert - >>> >> >> I think that the problem comes form COG which tries to use an obsolete >> method sent AFTER the recompilation of Parser which is not the >> expected behavior. >> I have triggered such kind of strange behavior that does not happen on >> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog >> VM Crash on Windows' >> For me, it must be related to a cache that is not cleaned-up, I don't know why. >> >> Nicolas > |
I'm not sure exactly how to read the CI results, but I confirm that
the update may fail, I experienced two trunk update failure starting at Squeak4.4-12327 on MacOS-X with latest COG VM. So I renewed my fix in Kernel-nice.747, changed updates 222 to 227 again, and will wait for the reports... Nicolas 2013/3/10 Frank Shearar <[hidden email]>: > http://build.squeak.org/job/SqueakTrunk-OSX/88/ shows things working, > and the trend shows that the Mac Cog seems to have always been OK. > > http://build.squeak.org/job/SqueakTrunk/212/ shows bad things still > happening with the Parser. If you look at the test history (show test > failures only on http://build.squeak.org/job/SqueakTrunk/) you'll see > this bug's biting hard - all the only-2-failing-test builds exhibit > the behaviour. > > (Why do the tests run at all when it's a failing update? I _think_ > that's because the build script is insufficiently suicidal, and ends > up running a TrunkImage from a previous build.) > > frank > > On 10 March 2013 19:10, Nicolas Cellier > <[hidden email]> wrote: >> OK, see the VM thread, I now think that problems does not come from >> COG, but from ClassBuilder which in some cases fail to clean a cache >> (primitive 116). >> The problem does not show up in interpreter VM thanks to primitive 119 >> (this primitives does not unlink send in cogit). >> I have attempted a ClassBuilder fix and posted new updates from >> nice-222 to cwp-227. >> >> Can I please ask our testers contribution once again? >> >> Nicolas >> >> 2013/3/8 Nicolas Cellier <[hidden email]>: >>> 2013/3/8 Bert Freudenberg <[hidden email]>: >>>> >>>> On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: >>>> >>>>> On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >>>>>> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>>>>>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>>>>>> >>>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>>>>>> >>>>>>>>>>> Ken G. Brown >>>>>>>>>>> >>>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>>>>>> SMLoader-fbs-78 as before: >>>>>>>> >>>>>>>> What I find strange about all this is that we take a 4.4-12327 image >>>>>>>> and whatever the latest Cog is and update it all the way without any >>>>>>>> probems quite a few times a day on the CI server. >>>>>>>> >>>>>>>> frank >>>>>>> >>>>>>> Looks like it's an intermittent problem, unfortunately: >>>>>>> >>>>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>>>>>> >>>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>>>>>> >>>>>>> BOOM. Cog crash. Didn't save the log unfortunately. >>>>>>> >>>>>>> Tried again. Update, switch to trunk, update again. No crash. What?! >>>>>>> >>>>>>> Once more. Update, switch to trunk, update. Crash! See below. >>>>>>> >>>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>>>>>> >>>>>>> So it does crash, just not always. But it's been more than 50% in my case. >>>>>> >>>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >>>>>> they switch to trunk and update just like that. Which I would have >>>>>> thought would make no difference... >>>>> >>>>> Actually, I lie. Here's an example of the CI jobs hitting the same >>>>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further >>>>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to >>>>> see the failing tests you'll see times (say around build #184) where >>>>> the test failure count is unusually low. And >>>>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey >>>>> streaks where builds die. >>>> >>>> Curious that it still runs the tests at all if the update failed ... >>>> >>>> So Cog crashes, but has someone tried to replicate this on an interpreter? >>>> >>>> - Bert - >>>> >>> >>> I think that the problem comes form COG which tries to use an obsolete >>> method sent AFTER the recompilation of Parser which is not the >>> expected behavior. >>> I have triggered such kind of strange behavior that does not happen on >>> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog >>> VM Crash on Windows' >>> For me, it must be related to a cache that is not cleaned-up, I don't know why. >>> >>> Nicolas >> > |
Unfortunately, I can't check, all recent SqueakTrunk CI jobs seem to
hang (timeout after 15minutes). There are quite many tests failing with last Environmental changes (AttemptToWriteReadOnlyGlobal), and this might be related. Should we increase the timeout, or is it something else that blocks the image? Nicolas 2013/3/10 Nicolas Cellier <[hidden email]>: > I'm not sure exactly how to read the CI results, but I confirm that > the update may fail, I experienced two trunk update failure starting > at Squeak4.4-12327 on MacOS-X with latest COG VM. > > So I renewed my fix in Kernel-nice.747, changed updates 222 to 227 > again, and will wait for the reports... > > Nicolas > > 2013/3/10 Frank Shearar <[hidden email]>: >> http://build.squeak.org/job/SqueakTrunk-OSX/88/ shows things working, >> and the trend shows that the Mac Cog seems to have always been OK. >> >> http://build.squeak.org/job/SqueakTrunk/212/ shows bad things still >> happening with the Parser. If you look at the test history (show test >> failures only on http://build.squeak.org/job/SqueakTrunk/) you'll see >> this bug's biting hard - all the only-2-failing-test builds exhibit >> the behaviour. >> >> (Why do the tests run at all when it's a failing update? I _think_ >> that's because the build script is insufficiently suicidal, and ends >> up running a TrunkImage from a previous build.) >> >> frank >> >> On 10 March 2013 19:10, Nicolas Cellier >> <[hidden email]> wrote: >>> OK, see the VM thread, I now think that problems does not come from >>> COG, but from ClassBuilder which in some cases fail to clean a cache >>> (primitive 116). >>> The problem does not show up in interpreter VM thanks to primitive 119 >>> (this primitives does not unlink send in cogit). >>> I have attempted a ClassBuilder fix and posted new updates from >>> nice-222 to cwp-227. >>> >>> Can I please ask our testers contribution once again? >>> >>> Nicolas >>> >>> 2013/3/8 Nicolas Cellier <[hidden email]>: >>>> 2013/3/8 Bert Freudenberg <[hidden email]>: >>>>> >>>>> On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: >>>>> >>>>>> On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >>>>>>> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>>>>>>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>>>>>>> >>>>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>>>>>>> >>>>>>>>>>>> Ken G. Brown >>>>>>>>>>>> >>>>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>>>>>>> SMLoader-fbs-78 as before: >>>>>>>>> >>>>>>>>> What I find strange about all this is that we take a 4.4-12327 image >>>>>>>>> and whatever the latest Cog is and update it all the way without any >>>>>>>>> probems quite a few times a day on the CI server. >>>>>>>>> >>>>>>>>> frank >>>>>>>> >>>>>>>> Looks like it's an intermittent problem, unfortunately: >>>>>>>> >>>>>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>>>>>>> >>>>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>>>>>>> >>>>>>>> BOOM. Cog crash. Didn't save the log unfortunately. >>>>>>>> >>>>>>>> Tried again. Update, switch to trunk, update again. No crash. What?! >>>>>>>> >>>>>>>> Once more. Update, switch to trunk, update. Crash! See below. >>>>>>>> >>>>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>>>>>>> >>>>>>>> So it does crash, just not always. But it's been more than 50% in my case. >>>>>>> >>>>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >>>>>>> they switch to trunk and update just like that. Which I would have >>>>>>> thought would make no difference... >>>>>> >>>>>> Actually, I lie. Here's an example of the CI jobs hitting the same >>>>>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further >>>>>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to >>>>>> see the failing tests you'll see times (say around build #184) where >>>>>> the test failure count is unusually low. And >>>>>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey >>>>>> streaks where builds die. >>>>> >>>>> Curious that it still runs the tests at all if the update failed ... >>>>> >>>>> So Cog crashes, but has someone tried to replicate this on an interpreter? >>>>> >>>>> - Bert - >>>>> >>>> >>>> I think that the problem comes form COG which tries to use an obsolete >>>> method sent AFTER the recompilation of Parser which is not the >>>> expected behavior. >>>> I have triggered such kind of strange behavior that does not happen on >>>> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog >>>> VM Crash on Windows' >>>> For me, it must be related to a cache that is not cleaned-up, I don't know why. >>>> >>>> Nicolas >>> >> |
They are hanging, and I haven't had a chance to run them by hand to
see what's going wrong. It doesn't help that we have potentially three breaking things on the go right now: * the Parser issue * Environments upgrade * my snafu with deleting/readding classes (unlikely?) frank On 11 March 2013 22:10, Nicolas Cellier <[hidden email]> wrote: > Unfortunately, I can't check, all recent SqueakTrunk CI jobs seem to > hang (timeout after 15minutes). > There are quite many tests failing with last Environmental changes > (AttemptToWriteReadOnlyGlobal), and this might be related. > Should we increase the timeout, or is it something else that blocks the image? > > Nicolas > > 2013/3/10 Nicolas Cellier <[hidden email]>: >> I'm not sure exactly how to read the CI results, but I confirm that >> the update may fail, I experienced two trunk update failure starting >> at Squeak4.4-12327 on MacOS-X with latest COG VM. >> >> So I renewed my fix in Kernel-nice.747, changed updates 222 to 227 >> again, and will wait for the reports... >> >> Nicolas >> >> 2013/3/10 Frank Shearar <[hidden email]>: >>> http://build.squeak.org/job/SqueakTrunk-OSX/88/ shows things working, >>> and the trend shows that the Mac Cog seems to have always been OK. >>> >>> http://build.squeak.org/job/SqueakTrunk/212/ shows bad things still >>> happening with the Parser. If you look at the test history (show test >>> failures only on http://build.squeak.org/job/SqueakTrunk/) you'll see >>> this bug's biting hard - all the only-2-failing-test builds exhibit >>> the behaviour. >>> >>> (Why do the tests run at all when it's a failing update? I _think_ >>> that's because the build script is insufficiently suicidal, and ends >>> up running a TrunkImage from a previous build.) >>> >>> frank >>> >>> On 10 March 2013 19:10, Nicolas Cellier >>> <[hidden email]> wrote: >>>> OK, see the VM thread, I now think that problems does not come from >>>> COG, but from ClassBuilder which in some cases fail to clean a cache >>>> (primitive 116). >>>> The problem does not show up in interpreter VM thanks to primitive 119 >>>> (this primitives does not unlink send in cogit). >>>> I have attempted a ClassBuilder fix and posted new updates from >>>> nice-222 to cwp-227. >>>> >>>> Can I please ask our testers contribution once again? >>>> >>>> Nicolas >>>> >>>> 2013/3/8 Nicolas Cellier <[hidden email]>: >>>>> 2013/3/8 Bert Freudenberg <[hidden email]>: >>>>>> >>>>>> On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: >>>>>> >>>>>>> On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >>>>>>>> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>>>>>>>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>>>>>>>> >>>>>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>>>>>>>> >>>>>>>>>>>>> Ken G. Brown >>>>>>>>>>>>> >>>>>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>>>>>>>> SMLoader-fbs-78 as before: >>>>>>>>>> >>>>>>>>>> What I find strange about all this is that we take a 4.4-12327 image >>>>>>>>>> and whatever the latest Cog is and update it all the way without any >>>>>>>>>> probems quite a few times a day on the CI server. >>>>>>>>>> >>>>>>>>>> frank >>>>>>>>> >>>>>>>>> Looks like it's an intermittent problem, unfortunately: >>>>>>>>> >>>>>>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>>>>>>>> >>>>>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>>>>>>>> >>>>>>>>> BOOM. Cog crash. Didn't save the log unfortunately. >>>>>>>>> >>>>>>>>> Tried again. Update, switch to trunk, update again. No crash. What?! >>>>>>>>> >>>>>>>>> Once more. Update, switch to trunk, update. Crash! See below. >>>>>>>>> >>>>>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>>>>>>>> >>>>>>>>> So it does crash, just not always. But it's been more than 50% in my case. >>>>>>>> >>>>>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >>>>>>>> they switch to trunk and update just like that. Which I would have >>>>>>>> thought would make no difference... >>>>>>> >>>>>>> Actually, I lie. Here's an example of the CI jobs hitting the same >>>>>>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further >>>>>>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to >>>>>>> see the failing tests you'll see times (say around build #184) where >>>>>>> the test failure count is unusually low. And >>>>>>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey >>>>>>> streaks where builds die. >>>>>> >>>>>> Curious that it still runs the tests at all if the update failed ... >>>>>> >>>>>> So Cog crashes, but has someone tried to replicate this on an interpreter? >>>>>> >>>>>> - Bert - >>>>>> >>>>> >>>>> I think that the problem comes form COG which tries to use an obsolete >>>>> method sent AFTER the recompilation of Parser which is not the >>>>> expected behavior. >>>>> I have triggered such kind of strange behavior that does not happen on >>>>> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog >>>>> VM Crash on Windows' >>>>> For me, it must be related to a cache that is not cleaned-up, I don't know why. >>>>> >>>>> Nicolas >>>> >>> > |
Most likely Environments.
The Parser problem did crash well earlier. Nicolas 2013/3/11 Frank Shearar <[hidden email]>: > They are hanging, and I haven't had a chance to run them by hand to > see what's going wrong. It doesn't help that we have potentially three > breaking things on the go right now: > * the Parser issue > * Environments upgrade > * my snafu with deleting/readding classes (unlikely?) > > frank > > On 11 March 2013 22:10, Nicolas Cellier > <[hidden email]> wrote: >> Unfortunately, I can't check, all recent SqueakTrunk CI jobs seem to >> hang (timeout after 15minutes). >> There are quite many tests failing with last Environmental changes >> (AttemptToWriteReadOnlyGlobal), and this might be related. >> Should we increase the timeout, or is it something else that blocks the image? >> >> Nicolas >> >> 2013/3/10 Nicolas Cellier <[hidden email]>: >>> I'm not sure exactly how to read the CI results, but I confirm that >>> the update may fail, I experienced two trunk update failure starting >>> at Squeak4.4-12327 on MacOS-X with latest COG VM. >>> >>> So I renewed my fix in Kernel-nice.747, changed updates 222 to 227 >>> again, and will wait for the reports... >>> >>> Nicolas >>> >>> 2013/3/10 Frank Shearar <[hidden email]>: >>>> http://build.squeak.org/job/SqueakTrunk-OSX/88/ shows things working, >>>> and the trend shows that the Mac Cog seems to have always been OK. >>>> >>>> http://build.squeak.org/job/SqueakTrunk/212/ shows bad things still >>>> happening with the Parser. If you look at the test history (show test >>>> failures only on http://build.squeak.org/job/SqueakTrunk/) you'll see >>>> this bug's biting hard - all the only-2-failing-test builds exhibit >>>> the behaviour. >>>> >>>> (Why do the tests run at all when it's a failing update? I _think_ >>>> that's because the build script is insufficiently suicidal, and ends >>>> up running a TrunkImage from a previous build.) >>>> >>>> frank >>>> >>>> On 10 March 2013 19:10, Nicolas Cellier >>>> <[hidden email]> wrote: >>>>> OK, see the VM thread, I now think that problems does not come from >>>>> COG, but from ClassBuilder which in some cases fail to clean a cache >>>>> (primitive 116). >>>>> The problem does not show up in interpreter VM thanks to primitive 119 >>>>> (this primitives does not unlink send in cogit). >>>>> I have attempted a ClassBuilder fix and posted new updates from >>>>> nice-222 to cwp-227. >>>>> >>>>> Can I please ask our testers contribution once again? >>>>> >>>>> Nicolas >>>>> >>>>> 2013/3/8 Nicolas Cellier <[hidden email]>: >>>>>> 2013/3/8 Bert Freudenberg <[hidden email]>: >>>>>>> >>>>>>> On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: >>>>>>> >>>>>>>> On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >>>>>>>>> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>>>>>>>>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>>>>>>>>> >>>>>>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ken G. Brown >>>>>>>>>>>>>> >>>>>>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>>>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>>>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>>>>>>>>> SMLoader-fbs-78 as before: >>>>>>>>>>> >>>>>>>>>>> What I find strange about all this is that we take a 4.4-12327 image >>>>>>>>>>> and whatever the latest Cog is and update it all the way without any >>>>>>>>>>> probems quite a few times a day on the CI server. >>>>>>>>>>> >>>>>>>>>>> frank >>>>>>>>>> >>>>>>>>>> Looks like it's an intermittent problem, unfortunately: >>>>>>>>>> >>>>>>>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>>>>>>>>> >>>>>>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>>>>>>>>> >>>>>>>>>> BOOM. Cog crash. Didn't save the log unfortunately. >>>>>>>>>> >>>>>>>>>> Tried again. Update, switch to trunk, update again. No crash. What?! >>>>>>>>>> >>>>>>>>>> Once more. Update, switch to trunk, update. Crash! See below. >>>>>>>>>> >>>>>>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>>>>>>>>> >>>>>>>>>> So it does crash, just not always. But it's been more than 50% in my case. >>>>>>>>> >>>>>>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >>>>>>>>> they switch to trunk and update just like that. Which I would have >>>>>>>>> thought would make no difference... >>>>>>>> >>>>>>>> Actually, I lie. Here's an example of the CI jobs hitting the same >>>>>>>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further >>>>>>>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to >>>>>>>> see the failing tests you'll see times (say around build #184) where >>>>>>>> the test failure count is unusually low. And >>>>>>>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey >>>>>>>> streaks where builds die. >>>>>>> >>>>>>> Curious that it still runs the tests at all if the update failed ... >>>>>>> >>>>>>> So Cog crashes, but has someone tried to replicate this on an interpreter? >>>>>>> >>>>>>> - Bert - >>>>>>> >>>>>> >>>>>> I think that the problem comes form COG which tries to use an obsolete >>>>>> method sent AFTER the recompilation of Parser which is not the >>>>>> expected behavior. >>>>>> I have triggered such kind of strange behavior that does not happen on >>>>>> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog >>>>>> VM Crash on Windows' >>>>>> For me, it must be related to a cache that is not cleaned-up, I don't know why. >>>>>> >>>>>> Nicolas >>>>> >>>> >> > |
In reply to this post by Nicolas Cellier
On Sun, Mar 10, 2013 at 12:10 PM, Nicolas Cellier
<[hidden email]> wrote: > OK, see the VM thread, I now think that problems does not come from > COG, but from ClassBuilder which in some cases fail to clean a cache > (primitive 116). > The problem does not show up in interpreter VM thanks to primitive 119 > (this primitives does not unlink send in cogit). it does unlink sends, but only for that selector. But is it really the case that it is a missing cache flush or is it a bug in Cog with its cache flushing? I realised the way to test this is to try the Stack VM and see if it crashes or not. I just tried that but now neither Cog nor the Stack VM crash although both fail the load with an MNU of #do: to UndefinedObject in Environment>>bindingOf:ifAbsent:. So how do I get the system back to a state where I can reproduce the Cog crash to compare the Stack and Cog VMs with each other? (Apologies for being unresponsive; I've just moved into a new apartment and only got my internet connection yesterday afternoon; at least its fast (for the states) :) ). > I have attempted a ClassBuilder fix and posted new updates from > nice-222 to cwp-227. > > Can I please ask our testers contribution once again? > > Nicolas > > 2013/3/8 Nicolas Cellier <[hidden email]>: >> 2013/3/8 Bert Freudenberg <[hidden email]>: >>> >>> On 2013-03-08, at 10:55, Frank Shearar <[hidden email]> wrote: >>> >>>> On 7 March 2013 23:25, Frank Shearar <[hidden email]> wrote: >>>>> On 7 March 2013 23:11, Bert Freudenberg <[hidden email]> wrote: >>>>>> On 2013-03-07, at 23:42, Frank Shearar <[hidden email]> wrote: >>>>>> >>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <[hidden email]> wrote: >>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to >>>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by >>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511. >>>>>>>>>> >>>>>>>>>> Ken G. Brown >>>>>>>>>> >>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during >>>>>>>>>>> the same update-nice-223, then trying again from what had already been >>>>>>>>>>> loaded, got the following during the same update, during compiling >>>>>>>>>>> SMLoader-fbs-78 as before: >>>>>>> >>>>>>> What I find strange about all this is that we take a 4.4-12327 image >>>>>>> and whatever the latest Cog is and update it all the way without any >>>>>>> probems quite a few times a day on the CI server. >>>>>>> >>>>>>> frank >>>>>> >>>>>> Looks like it's an intermittent problem, unfortunately: >>>>>> >>>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697. >>>>>> >>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again. >>>>>> >>>>>> BOOM. Cog crash. Didn't save the log unfortunately. >>>>>> >>>>>> Tried again. Update, switch to trunk, update again. No crash. What?! >>>>>> >>>>>> Once more. Update, switch to trunk, update. Crash! See below. >>>>>> >>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place. >>>>>> >>>>>> So it does crash, just not always. But it's been more than 50% in my case. >>>>> >>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44; >>>>> they switch to trunk and update just like that. Which I would have >>>>> thought would make no difference... >>>> >>>> Actually, I lie. Here's an example of the CI jobs hitting the same >>>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further >>>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to >>>> see the failing tests you'll see times (say around build #184) where >>>> the test failure count is unusually low. And >>>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey >>>> streaks where builds die. >>> >>> Curious that it still runs the tests at all if the update failed ... >>> >>> So Cog crashes, but has someone tried to replicate this on an interpreter? >>> >>> - Bert - >>> >> >> I think that the problem comes form COG which tries to use an obsolete >> method sent AFTER the recompilation of Parser which is not the >> expected behavior. >> I have triggered such kind of strange behavior that does not happen on >> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog >> VM Crash on Windows' >> For me, it must be related to a cache that is not cleaned-up, I don't know why. >> >> Nicolas > -- best, Eliot |
Free forum by Nabble | Edit this page |