David Bjergaard <dbjerga...@gmail.com> writes: Hi -- I dont believe it was a commit to stumpwm that started this crash to happen, I actually suspect some set of ubuntu updates that happened in mid-February.
Here is why I conjecture the above 1. StumpWM was working fine, then suddenly the crash started happening i.e. it wasn't a stumpwm update that started this. 2. Crashes started happening mid-Feb 2017, and I was able to reproduce the crash by both going backwards in stumpwm builds --- including the now ancient stumpwm available via apt-get -- all the way to Git@head. 3. As mentioned, stumpwm does not have the issue on my desktop workstation. 4. The crash triggers only if one attaches a function to *message-hook* Hope this is useful. I'll follow the GitHub Issues page. > Hi Raman, > > I respect your choice to use a browser that doesn't use javascript, but I have > to warn you that it may make resolving this issue more difficult. I have > opened > an issue for you here: > > https://github.com/stumpwm/stumpwm/issues/343 > > We will track changes there so if you can at least monitor that page for > updates > to your bug that would be great. > > The next step in narrowing this down is to use git to track down the commit > that > caused the break. Failing that, two things stick out to me as odd: > 1. the "Error opening /dev/tty" is strange, I can't find anywhere in the > backtrace for "echo" that needs a pseuod-terminal > 2. The obno-popup-notifier is unfamiliar to me, I haven't seen those types of > errors before. Did Ubuntu recently change the notification handler? > > Next steps: > Is it possible to get a backtrace when the crash happens? > If not, please set up the debugging output to a file and see what is in the > log > when the crash happens. > > Revert the commits until you find a version of stumpwm that doesn't crash > using > your recipe. > > David > > ra...@google.com writes: > >> I just rebuilt against GitHub@head and still reproduce a reliable >> crash -- this crash started happening about mid-February >> >> Basically Stumpwm crashes if I do something like this: [12:18] >> >> (setq *message-hook* (list #'(lambda nil (echo "foo")))) >> >> I reduced the crash to the above minimal example: in my actual use >> case, I used to have a function on that hook that spoke the message >> to >> . [12:19] >> >> incidentally, the same configuration is working fine on my desktop >> running Trusty -- but a 3.x kernel >> >> Looks like the above crashes all of X [12:20] >> >> fatal error encountered in SBCL pid 2614(tid 140737353893696): [12:21] >> >> %PRIMITIVE HALT called; the party is over. >> >> >> >> >> >> Error opening /dev/tty: No such device or address >> >> >> >> (obno-popup-notifier:2534): Gdk-WARNING **: obno-popup-notifier: Fatal >> IO error 11 (Resource temporarily unavailable) on X server :0. >> >> >> >> xterm: fatal IO error 11 (Resource temporarily unavailable) or >> KillClient on X server ":0" >> >> g_dbus_connection_real_closed: Remote peer vanished with error: >> Underlying GIOStream returned 0 bytes on an async read >> (g-io-error-quark, 0). Exiting. >> >> 12:20:44 raman-glaptop2 ~ $ >> >> stumpwm version from stumpish: > >> 1.0.0-88-g7d63123 Compiled On Sun Apr >> 02 2017 10:53:41 [12:23] >> >> is there somewhere I should email the above? [12:31] >> <alezost> >> Raman: you can report at >> <https://github.com/stumpwm/stumpwm/issues/new> >> [12:33] >> >> HMM, if that requires use of a JS-powered browser, it's going to be >> painful. Can I email in an issue? [12:34] >> ERC> >> HMM, if that requires use of a JS-powered browser, it's going to be >> painful. Can I email in an issue? >> -- -- _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
