The Trunk: Tools-cmm.755.mcz
Locked
 
|
Chris Muller uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-cmm.755.mcz ==================== Summary ==================== Name: Tools-cmm.755 Author: cmm Time: 4 April 2017, 3:49:36.354898 pm UUID: d6acf9c9-c3e4-4076-b2a5-9757eefe0b0e Ancestors: Tools-eem.754 Fix the race condition introduced with Debugger>>'ErrorRecursion' which resulted in the Emergency Evaluator being opened too eagerly (and unable to be closed!) -- even when there was no recursion. =============== Diff against Tools-eem.754 =============== Item was changed: CodeHolder subclass: #Debugger instanceVariableNames: 'interruptedProcess interruptedController contextStack contextStackIndex contextStackList receiverInspector contextVariablesInspector externalInterrupt proceedValue selectingPC savedCursor isolationHead failedProject errorWasInUIProcess labelString message untilExpression' + classVariableNames: 'ContextStackKeystrokes ErrorRecursion ErrorRecursionGuard ErrorReportServer InterruptUIProcessIfBlockedOnErrorInBackgroundProcess WantsAnnotationPane' - classVariableNames: 'ContextStackKeystrokes ErrorRecursion ErrorReportServer InterruptUIProcessIfBlockedOnErrorInBackgroundProcess WantsAnnotationPane' poolDictionaries: '' category: 'Tools-Debugger'! !Debugger commentStamp: '<historical>' prior: 0! I represent the machine state at the time of an interrupted process. I also represent a query path into the state of the process. The debugger is typically viewed through a window that views the stack of suspended contexts, the code for, and execution point in, the currently selected message, and inspectors on both the receiver of the currently selected message, and the variables in the current context. Special note on recursive errors: Some errors affect Squeak's ability to present a debugger. This is normally an unrecoverable situation. However, if such an error occurs in an isolation layer, Squeak will attempt to exit from the isolation layer and then present a debugger. Here is the chain of events in such a recovery. * A recursive error is detected. * The current project is queried for an isolationHead * Changes in the isolationHead are revoked * The parent project of isolated project is returned to * The debugger is opened there and execution resumes. If the user closes that debugger, execution continues in the outer project and layer. If, after repairing some damage, the user proceeds from the debugger, then the isolationHead is re-invoked, the failed project is re-entered, and execution resumes in that world. ! Item was changed: ----- Method: Debugger class>>initialize (in category 'class initialization') ----- initialize ErrorRecursion := false. + ErrorRecursionGuard := Mutex new. ContextStackKeystrokes := Dictionary new at: $e put: #send; at: $t put: #doStep; at: $T put: #stepIntoBlock; at: $p put: #proceed; at: $r put: #restart; at: $f put: #fullStack; at: $w put: #where; yourself. "Debugger initialize"! Item was changed: + (PackageInfo named: 'Tools') postscript: 'Debugger initialize.'! - (PackageInfo named: 'Tools') postscript: 'ProcessBrowser initialize.'! |
Re: The Trunk: Tools-cmm.755.mcz
|
|
Hi Chris, this won't work as written. Suspending the active process within a critical: block prevents the critical: block from completing and releasing the lock. So with the changes as written another debugger won't open when one is already open. One should never do this: aMutexOrSemaphore critical: [self doStuff. Processor activeProcess suspend] I'm revising these cases to pull the suspend out of the critical block. On Tue, Apr 4, 2017 at 1:49 PM, <[hidden email]> wrote: Chris Muller uploaded a new version of Tools to project The Trunk: _,,,^..^,,,_ best, Eliot |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |