2015-06-01 23:44 GMT+02:00 Craig Johnson <[hidden email]>: Sure thing. This worked until pharo 40245
|
I passed the info to martin mcClure.
May be he will have a look at the issue. Le 2/6/15 00:12, Nicolai Hess a écrit :
|
On 06/04/2015 12:38 PM, stepharo wrote:
> I passed the info to martin mcClure. > May be he will have a look at the issue. Well, I can reproduce the problem, in Windows. In Linux, my usual platform, the image does not hang. This suggests that the problem might be in the Windows VM. Is there a way to get trace output from the VM so I can see the sequence leading up to the hang, or a way to get a Smalltalk stack trace from a C debugger? Regards, -Martin > > Le 2/6/15 00:12, Nicolai Hess a écrit : >> >> >> 2015-06-01 23:44 GMT+02:00 Craig Johnson <[hidden email] >> <mailto:[hidden email]>>: >> >> Sure thing. >> >> To see the bug, file the code below into a clean image and run the >> example. The when the debugger pops, step over each line in the >> method. I'm doing this on a Windows OS. >> >> Object subclass: #Cooler >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'ImageFreeze'! >> >> !Cooler methodsFor: 'as yet unclassified' stamp: 'CraigJohnson >> 6/1/2015 23:31'! >> runMe >> | a | >> self halt. >> self except. >> a := 1.! ! >> >> "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! >> >> Cooler class >> instanceVariableNames: ''! >> >> !Cooler class methodsFor: 'as yet unclassified' stamp: >> 'CraigJohnson 6/1/2015 23:16'! >> example >> self new runMe ! ! >> >> >> This worked until pharo 40245 >> -> it looks like phase4 in issue >> 11996 <https://pharo.fogbugz.com/default.asp?11996> >> Wrong exception handler problem >> >> introduced this behavior. > |
On 06/04/2015 03:35 PM, Martin McClure wrote:
> On 06/04/2015 12:38 PM, stepharo wrote: >> I passed the info to martin mcClure. >> May be he will have a look at the issue. > > Well, I can reproduce the problem, in Windows. In Linux, my usual > platform, the image does not hang. This suggests that the problem might > be in the Windows VM. Is there a way to get trace output from the VM so > I can see the sequence leading up to the hang, or a way to get a > Smalltalk stack trace from a C debugger? Well, the "trace" option to the VM sounded promising, but all that yields is an access violation while the image is loading. Regards, -Martin |
In reply to this post by Martin McClure-2
Hi Martin-- > ...the problem might be in the Windows VM. Is there a way to get > trace output from the VM so I can see the sequence leading up to the > hang, or a way to get a Smalltalk stack trace from a C debugger? You can evaluate, for example, printCallStack() from the Microsoft Visual C++ debugger console. Or make a snapshot at that point with primitiveSnapshot(), and poke around with the virtual machine simulator on your preferred host platform. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
In reply to this post by Martin McClure-2
2015-06-05 1:51 GMT+02:00 Martin McClure <[hidden email]>: On 06/04/2015 03:35 PM, Martin McClure wrote: This happens on linux too, but not always. And the image does not freeze, but it looks like an endless loop of dnu: excerpt from the debug log: Message>>sentTo: Cooler(Object)>>doesNotUnderstand: #except Message>>sentTo: Cooler(Object)>>doesNotUnderstand: #except Message>>sentTo: Cooler(Object)>>doesNotUnderstand: #except Message>>sentTo: Cooler(Object)>>doesNotUnderstand: #except Message>>sentTo: Cooler(Object)>>doesNotUnderstand: #except Message>>sentTo: Cooler(Object)>>doesNotUnderstand: #except Message>>sentTo: Cooler(Object)>>doesNotUnderstand: #except Message>>sentTo: Cooler(Object)>>doesNotUnderstand: #except Message>>sentTo: |
Free forum by Nabble | Edit this page |