Re: sawfish has lost a window - window is found with xdotool

[Janek Kozicki <janek_listy wp pl>]

Jeremy Hankins said:     (by the date of Tue, 02 Nov 2010 10:01:12 -0500)

> > e.g. a 128MB-sized stack?
> 
> Dunno.  But I was thinking maybe it's some poor memory management
> someplace.  Whether in sawfish or X I don't know enough to guess -- and
> without being able to reproduce it at will it'd be tough to isolate.

we have time, there's a chance that after few months I'll narrow down
the cause and then you'll be able to reproduce.

 
> in your .sawfishrc you'll need to restart, otherwise run this from
> sawfish-client:
> 
> (require 'debug-utils)
> (setq window-logger-poll-delay 60)
> (window-logger-init)

thanks. For now I prefer to not restart, even though I know that
restarting should be now fine, except for tabs :) Also, it is
possible that this bug occurs only with higher sawfish uptime.

Also I still cannot compile 1.7.0.1, but that is another problem.
Tough to find time for all this here :)

I'll run this script in a day or two, and let it monitor window behavior.
 
> No, it wont.  It will only detect windows lost while it's running.  If
> you really want to compare it to xwininfo output you could write a list
> of windows from sawfish for feeding into a script from sawfish-client:
> 
> (setq f (open-file "file-name" 'write))
> (format f "%s\n" (mapconcat window-name (managed-windows) "\n"))
> (close-file f)
> 
> Or if you prefer window ids (in hex):
> 
> (setq f (open-file "file-name" 'write))
> (format f "%s\n" (mapconcat (lambda (w) (format nil "%x" (window-id w))) (managed-windows) "\n"))
> (close-file f)

those command seem to work. It produced a sensibly looking file,
I will compare it with xwininfo to check for other possible lost
windows.

-- 
Janek Kozicki                               http://janek.kozicki.pl/  |