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/ |
