I've been noticing that the following form may erase the second buffer
in the buffers list:
(jabber-starttls-connect '(:fsm jabber-connection :state :connecting :state-data (:send-function jabber-ssl-send :username "*****" :server "jabme.de" :resource "******" :password "*******" :registerp nil :connection-type starttls :encrypted nil :network-server nil :port nil) :deferred nil) "jabme.de" nil nil)
[the connection does fail due to circumstances beyond jabber.el]
As far as I can tell the problem is not always reproducible but it
happens often enough. Sometimes you need to wait a little longer.
I have erroneously tracked the bug back to starttls-negotiate-gnutls.
Please see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10535
It turns out that it's unlikely that starttls-negotiate-gnutls could
operate on a killed buffer as with-current-buffer checks against this.
Yet the debugger in at least one occasion showed me that the local
variable `buffer' could be a killed buffer.
Now, to avoid jumping again to a wrong conclusion, hereafter are my
- The bug is hit even within emacs -Q.
- This form does erase any writable buffer happening to be second in the
buffers list (or the first not visible).
(let ((buffer (generate-new-buffer "foobar")))
(with-current-buffer buffer (kill-buffer buffer) (erase-buffer)))
- I've set jabber-debug-keep-process-buffers to T and repeated
several times the test with jabber-starttls-connect without being
able to see the problem reoccur.
I don't know jabber.el enough to make guesses about asynchronous
killings and whatnot. I'll leave it to you.
Get latest updates about Open Source Projects, Conferences and News.