Xmonad Restart not working

Hi, With xmonad --recompile followed by xmonad --restart, sometimes there is no restart but instead I get "stack overflow" in the xinit log everytime I try to restart xmonad. This is with 1.13.1 version of X server and darcs xmonad. Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net

Hi,
* On Fri, Dec 28, 2012 at 11:52:22PM +0530, Raghavendra D Prabhu
Hi,
With xmonad --recompile followed by xmonad --restart, sometimes there is no restart but instead I get "stack overflow" in the xinit log everytime I try to restart xmonad. This is with 1.13.1 version of X server and darcs xmonad.
I fixed this by providing higher stack size while building xmonad. "" cabal install --haddock-executables --ghc-option=+RTS --ghc-option=-K16m --ghc-option=-RTS "" The default max stack size is 8M and if anything goes higher than that, a stack overflow exception is raised. (http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/runtime-control.html ) I wonder why this overflow happens when I restart it but not during normal start, is it because during restart double or more than double the stack size is required for a short while?
Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net

On Fri, Dec 28, 2012 at 1:53 PM, Raghavendra D Prabhu < raghu.prabhu13@gmail.com> wrote:
The default max stack size is 8M and if anything goes higher than that, a stack overflow exception is raised. (http://www.haskell.org/ghc/** docs/7.4.1/html/users_guide/**runtime-control.htmlhttp://www.haskell.org/ghc/docs/7.4.1/html/users_guide/runtime-control.html)
I wonder why this overflow happens when I restart it but not during normal start, is it because during restart double or more than double the stack size is required for a short while?
xmonad passes the current state of the layout plus any ExtensibleState (which is hidden in the layout so it will be persistent and relayed) between instances, and may possibly require additional memory when serializing or deserializing the layout data. This is one of several possible failure modes with extremely complex layouts, a large number of workspaces, etc. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (2)
-
Brandon Allbery
-
Raghavendra D Prabhu