|
There is more to it actually. Because this only loops because there is a "magical" duplication of the UI process in here:
``` debugProcess: process context: context label: title fullView: bool notification: notificationString "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."
| debugSession |
debugSession := process newDebugSessionNamed: title startedAt: context.
debugSession logStackToFileIfNeeded. debugSession isAboutUIProcess ifTrue: [ DefaultExecutionEnvironment beActiveDuring: [self spawnNewProcess]].
self defer: [ "schedule debugger in deferred UI message to address redraw problems after opening a debugger e.g. from the testrunner." [ Smalltalk tools debugger openOn: debugSession withFullView: bool andNotification: notificationString. ] on: Error do: [ :ex | debugSession signalDebuggerError: ex] ].
process suspend. ```
If an error happens what usually happens is that that error process is suspended and a debugger is open on that process. However, if the error happens in the UI thread, we cannot naively suspend the UI thread because then we would have UI no more :). So then, what happens is that it detects if a process it the UI process and if it is, - it will first create a new UI process - then suspend and debug the original process from this new process
|
|
|
Priority: 5 – Fix If Time
|
|
Status: Work Needed
|
|
Assigned to: Guillermo Polito
|
|
Milestone: Later
|
Go to Case
|
|