stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] Crash:StumpWM on Ubuntu Trusty


From: raman
Subject: Re: [STUMP] Crash:StumpWM on Ubuntu Trusty
Date: Mon, 03 Apr 2017 08:53:22 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

David Bjergaard <address@hidden> 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 address@hidden

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
>  
> address@hidden writes:
>
>>  I just rebuilt against address@hidden 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?
>> -- 

-- 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]