Re: [STUMP] Interesting Bug...

[Brit Butler]

Ben,

> Sorry I've been working...

No worries. Sorry I've been so long in replying, myself.

> ...can't replicate this behavior here. That debug log might help...

http://redlinernotes.com/docs/stump_profile.txt is for the complete
profile data from before.
http://redlinernotes.com/docs/stump_weirdness.png and
http://redlinernotes.com/docs/stump_weirdness2.png are pictures that
show strangeness.

I've run some stuff with *debug-level* 4 but the REPL output wasn't
higher and...potentially more concerning, this was the only thing in
~/.stumplog:
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>

> What version of SBCL are you
running?  Does (run-shell-command "xdpyinfo -ext XINERAMA" t) from a
REPL run in reasonable time?

I'm running SBCL 1.0.34 64-bit and have been since 2010-01-13. A loop
that called (time (run-shell-command "xdpyinfo -ext XINERAMA" t)) from
SLIME averaged 0.16 seconds.

I've tried to reproduce the hang but am not able to at the moment. It
used to hang outright, now it just takes ~5 seconds where before it
never completed. I still assume the run-prog call to xdpyinfo is at
fault. I'll try again on Thursday or Friday and get the backtrace from
initial-thread if successful. I recently upgraded the following:
[2010-02-01 13:22] upgraded libx11 (1.3.2-1 -> 1.3.3-1)
[2010-02-01 13:22] upgraded xorg-apps (7.5-2 -> 7.5-3)
[2010-02-01 13:22] upgraded xorg-server (1.7.3.902-1 -> 1.7.4.901-1)
which could have something to do with it. I've always been a little
suspicious of Linux's interactions with the dock. Not many people have
an X200 with a dock and it certainly could be a lower level thing than
stump.

Thanks again for your time spent looking into this. This isn't
happening very often and certainly isn't enough to dissuade me from
using stump but I just wanted to say I appreciate the effort. :)

Cheers,
B

On 1/31/10, Ben Spencer <address@hidden> wrote:
> 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
>
>
> _______________________________________________
> Stumpwm-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>