For the record, in case anyone else happens to encounter this -- it was pointed out to me by a helpful individual off-list that this is actually a known problem when running binaries mmaped out of AFS, where my xmonad binary happens to reside. I've changed my xsession script to run it out of a local filesystem instead and am no longer seeing this behavior. Zev On Wed, Feb 20, 2013 at 3:55 PM, Zev Weiss wrote:

Ah, forgot about that...nvidia, version 310.19 -- likely the culprit? (I don't think I have the know-how to examine much further than that on my own.) Unfortunately it's on a system I don't personally administrate, which complicates the matter of testing it with a different driver somewhat.

Zev

On Wed, Feb 20, 2013 at 2:12 PM, Don Stewart wrote:

...

I would look at your X11 video driver.

On Feb 20, 2013 8:11 PM, "Zev Weiss" wrote:

...

Hi,

I'm running xmonad-0.11 and getting outright crashes fairly frequently, often multiple times per week with my usage patterns. I can't pin it directly to any particularly specific action (like opening/closing a certain window), but it tends to happen upon returning to my machine after being away for a while with the screen locked (with gnome-screensaver, for what it's worth) -- commonly, I return to my workstation after being away from it overnight (or a weekend), and upon entering my password and returning to my desktop, xmonad catches SIGBUS and promptly dies. It has occasionally occurred under other circumstances, just during normal use (e.g., switching windows & workspaces), though the screen-unlocking situation is by far the most crash-prone.

I installed it with cabal & ghc from haskell-platform 2012.2.0.0:

[me@host: tmp]% cabal --version cabal-install version 0.14.0 using version 1.14.0 of the Cabal library [me@host: tmp]% ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.2

Libraries: utf8-string 0.3.7 X11 1.6.0.2 X11-xft 0.3.1 xmonad-contrib-0.11

Other potentially-relevant info: RHEL 6.3, x86_64 X.org 1.10.6, dual-head

I have a core file saved via gdb from when it catches the SIGBUS -- I don't think it has anything terribly revealing in it, but I'm slightly hesitant to post it publicly, so if it would be useful for debugging, let me know and I can send it directly (23MB bzipped, 5.8MB xz'd).

Please let me know if there's any other information I could provide that would be helpful.

Thanks, Zev Weiss

_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

On Tue, Feb 26, 2013 at 12:21:40PM -0500, Brandon Allbery wrote:

On Mon, Feb 25, 2013 at 5:10 PM, Zev Weiss wrote:

...

For the record, in case anyone else happens to encounter this -- it was pointed out to me by a helpful individual off-list that this is actually a known problem when running binaries mmaped out of AFS, where my xmonad binary happens to reside. I've changed my xsession script to run it out of a local filesystem instead and am no longer seeing this behavior.

Can you give me any more information about this? Simply running executables out of AFS does not have any known issues; if it did, Carnegie Mellon University (my previous employer) would have run headlong into it long since, and it would have been fixed by now.

This is a problem I have been annoyed by for a few years now and I've had limited success in tracking it down. The problem doesn't affect all binaries - seemingly just haskell binaries. It also gets worse with larger haskell binaries. The problem seems to be related to the state of the AFS cache somehow. Just after a reboot with a cold cache, I have to run ghc (some of my GHC installs are on AFS) 5+ times in a row to get it to do anything besides die with a SIGBUS. The same goes for pandoc. After the binary starts up properly the first time, it seems to be in cache and doesn't act up until it gets kicked out of cache. Here is an old cafe thread where I tried to track this down - not many other people reported the problem, but those who did seemed resigned to it: https://groups.google.com/forum/?fromgroups=#!searchin/haskell-cafe/tristan$... That post highlights a separate but seemingly related problem. There GHC fails when it hits some TH code and has to load a few libraries off of disk during compilation. I don't know exactly what the ghci linker does there, but it is prepping that code for execution and explodes if the libraries it is loading are not in cache. In those cases, I have to keep running 'cabal install' and ghc keeps making forward progress, loading a few more successfully each time. Eventually they are all in cache and it works. My guess is that the problem is some bad interaction between whatever the GHC RTS does for file IO and AFS, but it is hard to figure out where to start looking. I have never gotten a useful backtrace in any of these crashes. Most applications don't have any problems, so I imagine it has to be GHC somehow. That said, I've seen some similar crashes in non-Haskell code if a program is using shared libraries that live on AFS. if some application eats all of your memory and caches start getting evicted, sometimes those applications with AFS-based shared libraries explode in a similar way. Any insight would definitely be appreciated, since this annoys me a few times a day.