Re: [STUMP] Interesting Bug...

[Ben Spencer]

On Tue, Jan 26, 2010 at 06:13:21PM -0500, Brit Butler wrote:
> STUMPWM> (stumpwm::group-frames (current-group))
> (#S(frame 0 #S(TILE-WINDOW "screenshots - File Manager" #x800003) 0 0 640 800)
>  #S(frame 1 #S(TILE-WINDOW
> "address@hidden:~/builds/clbuild-dev/source/paktahn-dev"
> #x2200006) 640 0 640 400)
>  #S(frame 2 #S(TILE-WINDOW
> "address@hidden:~/projects/cl-web-apis" #x2400006) 640 400 640
> 400))
> STUMPWM> (stumpwm::group-frames (current-group))
> (#S(frame 0 #S(TILE-WINDOW "screenshots - File Manager" #x800003) 0 0 640 800)
>  #S(frame 1 #S(TILE-WINDOW "Display Settings" #x1800003) 640 0 640 400)
>  #S(frame 2 #S(TILE-WINDOW
> "address@hidden:~/projects/cl-web-apis" #x2400006) 640 400 640
> 400))

If this second result is while (screen-heads (current-screen)) shows a
1680x1050 head, then something is definitely up.  I can't replicate
the behaviour here though :( That debug log might help.


> 2) Regardless of *top-level-error-action*'s setting I have to call
> (loadrc) as there is no "crash". The "hang" must be some loop that
> isn't terminating. That would fit with the high CPU usage. Calling
> (loadrc) and then aborting for some reasons kicks the loop out.

I guess I was wrong about *top-level-error-action*.  When it crashes,
could you switch to slime and interrupt the main stumpwm thread (C-c
C-x t, then press d on 'initial thread'), and post the backtrace that
is displayed.

As to the profiling results, 4 seconds in run-prog (presumably to run
xdpyinfo) is definitely suspicious.  What version of SBCL are you
running?  Does (run-shell-command "xdpyinfo -ext XINERAMA" t) from a
REPL run in reasonable time?


Ben