[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [STUMP] Interesting Bug...
From: |
Ben Spencer |
Subject: |
Re: [STUMP] Interesting Bug... |
Date: |
Sat, 23 Jan 2010 16:36:03 +0000 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
- [STUMP] Interesting Bug..., Brit Butler, 2010/01/19
- Re: [STUMP] Interesting Bug..., Ben Spencer, 2010/01/20
- Message not available
- Re: [STUMP] Interesting Bug..., Ben Spencer, 2010/01/21
- Re: [STUMP] Interesting Bug..., Brit Butler, 2010/01/21
- Re: [STUMP] Interesting Bug..., Ben Spencer, 2010/01/21
- Re: [STUMP] Interesting Bug..., Brit Butler, 2010/01/22
- Re: [STUMP] Interesting Bug..., Ben Spencer, 2010/01/23
- Re: [STUMP] Interesting Bug..., Brit Butler, 2010/01/23
- Re: [STUMP] Interesting Bug...,
Ben Spencer <=
- Message not available
- Re: [STUMP] Interesting Bug..., Brit Butler, 2010/01/27
- Re: [STUMP] Interesting Bug..., Julian Stecklina, 2010/01/31
- Message not available
- Re: [STUMP] Interesting Bug..., Ben Spencer, 2010/01/31
- Re: [STUMP] Interesting Bug..., Shawn Betts, 2010/01/21