Mantis Bugtracker
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007656 [Squeak] Kernel minor sometimes 08-11-11 18:21 12-16-11 13:49
Reporter wiz View Status public  
Assigned To
Priority low Resolution open  
Status new   Product Version trunk
Summary 0007656: User interrupts key does not always work the first time it is pressed.
Description I have only anecdotal evidence at present.

When running a buggy program that does not stop, pressing user interrupt usually does not work. Often it doesn't work until the third press and then a predebug box comes up saying we have interrupted the finalization process. This stops the runaway calculation.
With out doing anything else that I am aware of and after some time has passed, two other predebug boxes pop up. One of which seems associated with the original runaway process.
Additional Information So my speculation is that the first time the interrupt key is pressed it is noted but it doesn't stop anything. The second time it interrupts the debug process but doesn't stop anything either. The third time it interrupts the finalization process and that brings other things to a halt giving the vm some breathing room. Then it catches up with the notifications probably in reverse chronological order.

Can anyone confirm, contradict or add to these observations?
Attached Files

- Relationships
child of 0007655new  A mother for user interupt bugs and problems 

- Notes
(0014208 - 1921 - 2249 - 2290 - 2290 - 2290 - 2290)
lewis
12-16-11 13:49

 See December 2011 thread on squeak-dev. Andreas Raab offers this guidance:

Date: Fri, 16 Dec 2011 08:00:03 +0100
From: Andreas Raab <andreas.raab@gmx.de>
Subject: [squeak-dev] Re: The broken user interrupt, or the saga of 100000 factorial.

On 12/16/2011 3:33, Levente Uzonyi wrote:
>On Thu, 15 Dec 2011, Christopher Oliver wrote:
>
>>On Thu, 15 Dec 2011 11:35:55 +0100
>>I added a tty output debug to
>>MorphicProject>>interruptName:preemptedProcess:, and I found
>>that Processor>>preemptedProcess occasionally answers the system weak
>>array finalization process. Yikes! This isn't what we want to debug at
>>all. Are we being adequately clever
>>in determining which process to debug?
>
>I'm pretty sure that the currently running process is interrupted. After
>GC (which happens often during calculations with LargeIntegers) this is
>likely to be the finalization process.

Correct. To make matters worse, when an interrupt is signaled in the
midst of GC, the signal will be delivered after the GC cycle completes,
therefore almost guaranteeing that the interrupted process will be the
finalization process.

And so the determination of the process to be interrupted is moderately
stupid. What we'd really need to do is to start a slightly leaner
version of CPUWatcher, i.e., instead of blindly interrupting whatever
process is active, start sampling the running processes and after a
short while (100-500 ms) decide which process to kick[*]. Plus, after
that ensure that the UI is actually responsive so that the user can
interact with the system and if not, keep kicking processes unless the
system becomes interactive again. Alas, not a trivial task to be solved.

[*] A more radical version would suspend *all* user processes and let
the user decide which of the suspended processes to inspect. This might
have some interesting side effects though...

Cheers,
  - Andreas
 

- Issue History
Date Modified Username Field Change
08-11-11 18:21 wiz New Issue
08-11-11 18:21 wiz Relationship added child of 0007655
08-11-11 18:23 wiz Description Updated
12-16-11 13:49 lewis Note Added: 0014208

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
39 total queries executed.
29 unique queries executed.
Powered by Mantis Bugtracker