3.8.1 Sloooooow redraw with debugger

I've recently started doing some work in 3.8.1 and whenever the  
debugger appears, it takes about a minute for the screen to redraw  
bit by bit.  Text looks like it is being hand typed.  Is there a fix  
for this?

-Todd Blanchard

On Oct 27, 2006, at 1:45 AM, Todd Blanchard wrote:

> I've recently started doing some work in 3.8.1 and whenever the  
> debugger appears, it takes about a minute for the screen to redraw  
> bit by bit.  Text looks like it is being hand typed.  Is there a  
> fix for this?

A crude hack that I've found works is to disable  
#primitiveDeferUpdates: - for example by having it simply return nil.

Avi

And in 3.9 it's even more strange: drawing is slow with the stock image  
and gets sloooooooooweeeeeeer after applying the #primitiveDeferUpdates:  
^nil hack. One can watch the pixel-shuffeling...

/Klaus

On Fri, 27 Oct 2006 10:53:29 +0200, Avi Bryant wrote:

Am 27.10.2006 um 10:53 schrieb Avi Bryant:

I only ever saw this on the Mac Carbon VM - does it happen on other  
VMs, too? Also, John might have fixed it in latest versions.

- Bert -

> I only ever saw this on the Mac Carbon VM - does it happen on other
> VMs, too? Also, John might have fixed it in latest versions.

Yes, it happens on the Mac Unix VM as well.

Ironically, when I press Ctrl+. during the slow update I mostly end up
in a method #copyLoopFaster or #copyLoopFastest.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

I once had a situation in which I could reproduce the problem and  
then found a way to fix it by changing Debugger  
class>>openOn:context:label:contents:fullView: not to fork  
immediately but to do a WorldState addDeferredUIMessage: [..] instead.
This change went into 3.9, and I have the impression that the issue  
doesn't pop up that often anymore, however, it is still there.

Adrian

On Oct 27, 2006, at 11:13 , Bert Freudenberg wrote:

> And in 3.9 it's even more strange: drawing is slow with the stock image
> and gets sloooooooooweeeeeeer after applying the #primitiveDeferUpdates:
> ^nil hack. One can watch the pixel-shuffeling...

Yes, I can confirm: Avi's hack doesn't work in 3.9.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

On Oct 27, 2006, at 2:29 AM, Lukas Renggli wrote:

>> And in 3.9 it's even more strange: drawing is slow with the stock  
>> image
>> and gets sloooooooooweeeeeeer after applying the  
>> #primitiveDeferUpdates:
>> ^nil hack. One can watch the pixel-shuffeling...
>
> Yes, I can confirm: Avi's hack doesn't work in 3.9.

I think it may have a 50% chance of working - it depends on whether,  
when you do it, the image thinks you're in deferred mode or not.  So  
it may work if done at the same time as setting the appropriate  
global.  But it's too late for me to be any more specific or coherent  
than that...

Avi

The worst is when proceeding.  Simply closing the debugger is quick  
enough.  This seems like kind of a showstopper problem to me.  I  
experience it on both carbon and unix vms with the same image.

-Todd

On Oct 27, 2006, at 2:29 AM, Adrian Lienhard wrote:

Is somebody able to reproduce the problem? This would certainly help...
I once was able to do so by just putting a halt in a testcase, or  
maybe in the OmniBrowser, but I don't remember exactly.

Adrian

On Oct 27, 2006, at 11:41 , Todd Blanchard wrote:

On Oct 27, 2006, at 2:29 AM, Adrian Lienhard wrote:

> I once had a situation in which I could reproduce the problem and  
> then found a way to fix it by changing Debugger  
> class>>openOn:context:label:contents:fullView: not to fork  
> immediately but to do a WorldState addDeferredUIMessage: [..] instead.
> This change went into 3.9, and I have the impression that the issue  
> doesn't pop up that often anymore, however, it is still there.

This is my experience as well.

I had lots of images where it would happen reliably anytime I got a  
debugger via a test case, whether it was a failure, an error, or a  
halt. I pulled that debugger change out of 3.9 and use it in 3.7 and  
3.8 to make developing with tests bearable.

The problem is definitely still there, patching the debugger just  
causes it to happen much less frequently.

Colin

Colin Putney wrote:
>> I once had a situation in which I could reproduce the problem and then
>> found a way to fix it by changing Debugger
>> class>>openOn:context:label:contents:fullView: not to fork immediately
>> but to do a WorldState addDeferredUIMessage: [..] instead.
>> This change went into 3.9, and I have the impression that the issue
>> doesn't pop up that often anymore, however, it is still there.
>
> This is my experience as well.

I haven't seen it after these fixes went in. What seems to happen is
that the redraw of the debugger is competing with the UI process (this
is why scheduling it with WorldState fixes the problem). You can see
this for example by doing something like here:

[
        process := [] newProcess.
        context := process suspendedContext.
        debugger := Debugger new process: process controller: nil context: context.
        debugger openFullNoSuspendLabel: 'test'.
] fork.

This (for me) shows the effect in about 1 out of three attempts (there
is some randomness to it because it's competing with the UI process).

> The problem is definitely still there, patching the debugger just causes
> it to happen much less frequently.

If you see it happen you should immediately make a snapshot of the
processes you have running and see if any of them might do the
equivalent of what you see above. It might also be triggered by
overrides in packages you use.

Cheers,
   - Andreas

As a point of technique - how do I do this with the UI being  
unresponsive?

On Oct 27, 2006, at 10:40 AM, Andreas Raab wrote:

>
> If you see it happen you should immediately make a snapshot of the  
> processes you have running and see if any of them might do the  
> equivalent of what you see above. It might also be triggered by  
> overrides in packages you use.
>
> Cheers,
>   - Andreas
>

Todd,

A relatively long time ago, I was doing some MIDI/Morphic experiments,
and deliberately avoided stepping for a few reasons.  High on the list
was that separate threads were a better model for what I would
ultimately want to do with Squeak, and IMHO were easier to understand
given that multiple things were happening on their own time scales.

Making a long story short, I managed to hang Morphic in a big way, and
needed a tool to debug it.  I approached it with a variant of a trick I
use in Dolphin, specifically for deployed executables, where I hook
control-break to export call stacks on all non-dead threads.  Squeak is
different because the VM is (in my experience at least) interactive even
if Morphic hangs.  Dolphin deployed executables will hang if the message
loop stops [*], leaving control-break as the escape valve.  In Squeak,
it appears that hacking the debug menu is sufficient.  I simply replaced
the dump of the active thread with all non-dead threads, IIRC, putting
the active one on top.  I also cleaned up the new lines a little to make
the output look better.  If there is interest, I can try to gather up a
change set for it.  It was invaluable to me in finding the problem I
had, and suspect it would be useful to others.

Bill

[*]  Please do not conclude that this is common, but I have encountered
when COM based things failed to respond, when I managed to deadlock the
GUI thread, etc.  The control-break trick saved my hide a few times.



Todd Blanchard:
As a point of technique - how do I do this with the UI being
unresponsive?

On Oct 27, 2006, at 10:40 AM, Andreas Raab wrote:

>
> If you see it happen you should immediately make a snapshot of the
> processes you have running and see if any of them might do the
> equivalent of what you see above. It might also be triggered by
> overrides in packages you use.
>
> Cheers,
> - Andreas
>




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

On Oct 27, 2006, at 2:09 PM, Bill Schwab wrote:

> Making a long story short, I managed to hang Morphic in a big way, and
> needed a tool to debug it.  I approached it with a variant of a  
> trick I
> use in Dolphin, specifically for deployed executables, where I hook
> control-break to export call stacks on all non-dead threads.  
> Squeak is
> different because the VM is (in my experience at least) interactive  
> even
> if Morphic hangs.  Dolphin deployed executables will hang if

The way to do this in Squeak without hacking the VM is to run it  
under gdb, trigger the slow redraw, then interrupt it from gdb. Then  
you can print the stack for all active threads with "call (int)  
printAllStacks()".

Admittedly though, this is a pretty inconvenient technique to use on  
something that's not easily reproducible. I find that with the  
debugger fix from 3.9, I can go weeks without encountering a slow  
redraw.

Colin

Colin,

Fair enough, but the last time I tried it, printAllStacks() had a few
out of place crs; the output can be improved with some small fixes.  Is
there a way to trigger printAllStacks() from the main window?  It seems
a very useful feature, and should be exposed (or I would like to be
shown how to get to it directly).

For rare bugs, it is helpful to have such tools readily available.

Bill


Colin Putney:
The way to do this in Squeak without hacking the VM is to run it
under gdb, trigger the slow redraw, then interrupt it from gdb. Then
you can print the stack for all active threads with "call (int)
printAllStacks()".

Admittedly though, this is a pretty inconvenient technique to use on
something that's not easily reproducible. I find that with the
debugger fix from 3.9, I can go weeks without encountering a slow
redraw.




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

Well I didn't notice any info on which VM it is. However if you draw  
*each* pixel via Morphic/BitBlt confusion then mmm it will be slow
The unix vm does a draw a pixel, flush, that will take forever,  
earlier versions of the mac carbon vm also did the same. Current  
versions
draw a pixel but regulate flushing, so it's *slow* but not render  
each pixel slow...

On 27-Oct-06, at 2:28 AM, Lukas Renggli wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is there any aggregated fix or changeset for 3.8/3.8.1?

Thanks in advance.


Colin Putney wrote:
> Admittedly though, this is a pretty inconvenient technique to use on
> something that's not easily reproducible. I find that with the debugger
> fix from 3.9, I can go weeks without encountering a slow redraw.
>
> Colin
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFQrlzQqspS1+XJHgRApOYAJ95xpCHUP4j6vxoK1BFV5Vm5OT+MQCghalw
IISs95eXXEaIagl9g2rzemY=
=rlJ8
-----END PGP SIGNATURE-----

On Oct 27, 2006, at 6:59 PM, Sungjin Chun wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Is there any aggregated fix or changeset for 3.8/3.8.1?
>
> Thanks in advance.

It's a pretty simple fix: