|
|
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
|
|
Locked
Debugging: 1. Pharo Image
• You are subscribed to this case
