Re: [STUMP] Interesting Bug...

[Ben Spencer]

On Sat, Jan 23, 2010 at 10:18:15AM -0500, Brit Butler wrote:
> For example, I just switched from VGA to laptop in a group with a
> hsplit and a vsplit, a file manager on the left and two terminals on
> the right. The file manager resized immediately but the terminals
> didn't. Launching lxrandr in one of the terminals made it resize
> right away. Here's a screenshot:
> http://redlinernotes.com/docs/2010-01-23.png

This behaviour is very odd.  Does it happen consistently with
particular applications?

Could you let me know what (stumpwm::group-frames (current-group))
looks like immediately after switching (while things are still in the
wrong place).

If you have the time it would be useful if you could set *debug-level*
to 4 and send me a log of the breakage happening.


> It's a bit embarrassing but I can't narrow this down enough to
> reproduce it with complete reliability. I just managed to cause the
> error a few times, once with *top-level-error-action* set to :break
> and once set to :abort but I only saw the same restarts from before.
> 
> Essentially, the bug is: input becomes trapped in whatever frame I was
> in as stump is unresponsive, the mode-line goes blank. Switching to
> tty1 and running htop shows stumpwm using ~90% cpu, running emacs -nw
> in this tty and slime-connecting works, (in-package :stumpmw). I
> generally try to run (loadrc) and after a second it gives me the
> restart options I mailed before. Selecting abort returns the system to
> normal. It's worth noting that the lxrandr window doesn't close after
> switching screens as it should. It just stays open (and no frames
> resize) until I've selected a restart for the type-error.

Hmm.  I was working on the basis that things were locking up *because*
you had it set to :break (which is intended to break out to the
debugger and thus offer you restarts).  In this case using :abort
should make it display an error and restart stumpwm immediately.

So, obligatory stupid question: are you absolutely sure
stumpwm:*top-level-error-action* was set to :abort at the point the
error occurred?  I notice that your rc (which I probably should have
read in more detail earlier...) sets it to :abort when swank is
started, and swank is not started automatically.

That said, I don't know why breaking would make it start hogging cpu,
so maybe I'm missing something here.


Ben