On Thu, 15 Dec 2011 11:35:55 +0100
Bert Freudenberg <bert at freudenbergs.de> wrote:

> Sounds tempting, but I don't think that is the core of the problem. Try this in Debugger>>openInterrupt:onProcess:

I'll look at these, but figure I'd share things found out so far.  I've been using this
crude instrument to see where and when things are going on:

|counter enabled|

counter := 0.
enabled := false.

WriteTTYEnabled := [:arg| enabled := arg].


WriteTTY :=
	[:arg | | sender |
		sender := thisContext sender.
		enabled ifTrue:	[
			FileStream fileNamed: '/dev/tty' do:
				[:handle|
					handle 	nextPutAll: '== ',
						counter asString,' ',
						sender receiver className,'(',
						sender methodClass asString,')>>',
						(sender method selector)
							asString,  
						' ',Time now asString,' ==  ',
						arg asString;
					 lf].
			counter := counter+1]].
		
WriteTTYReset := [counter := 0].

"
WriteTTYReset value
WriteTTYEnabled value: true
WriteTTYEnabled value: false
"

When I file this in and evaluate 'WriteTTYEnabled value: true', I can sprinkle the code I want to understand with 'WriteTTY value: SOMESTRING', and have output on the console without
depending on morphic display updates and the like.  I put this in the vars loop in ContextPart>>errorReportOn:, and in Object>>printStringLimitedTo: contingent on a Flag in
the Smalltalk globals.  I found that sometimes, Smaltalk indeed gets stuck converting that
bignum, but other times, the seems to go astray and the factorial marches on.  Hitting the
interrupt a second time sometimes succeeds, and two debugs appear after a while: the
expected factorial, but also BlockClosure>>newProcess/WeakArray class>>restartFinalizationProcess.  This suggests the running process has been misidentified, but I've not much idea what is happening here.

Thoughts?

-- 
Christopher Oliver <current.input.port at gmail.com>