bug#10535: 23.3; starttls-negotiate-gnutls erases random buffer

[Glenn Morris]

Walter C. Pelissero wrote:

> starttls-negotiate-gnutls obliterates the contents of the second
> buffer in the buffers list.
>
> For instance a form like this may expose the bug:
>
> (jabber-starttls-connect '(:fsm jabber-connection :state :connecting 
> :state-data (:send-function jabber-ssl-send :username "me" :server "jabme.de" 
> :password "secret" :registerp nil :connection-type starttls :encrypted nil 
> :network-server nil :port nil) :sleep 3 :deferred nil) "jabber.host" nil nil)
>
> I've noticed that the local variable `buffer' in
> starttls-negotiate-gnutls may contain a killed buffer, which I guessed
> it might be the source of the problem.

I didn't try to reproduce this (not having jabber installed), but
I don't see how that could be the source of any such issue. Eg:

(with-temp-buffer
  (setq foo (current-buffer)))

(with-current-buffer foo
  (insert "hi"))

does not insert "hi" in a random buffer, but stops with "(error
"Selecting deleted buffer")"

>  the following patch seems to fix the problem at least in starttls.
> The patch, despite it's length

(diff -w can be useful)

> , just checks that the buffer is still alive.

> !     (if (and buffer (buffer-live-p buffer))
> !     (with-current-buffer buffer

As shown above, a buffer that is not live should already cause an error,
so I don't see how adding a buffer-live-p test can help.

> In fact the following code erases the content of any writable buffer
> happening to be second in the buffers list:
>
> (let ((buffer (generate-new-buffer "foobar")))
>    (with-current-buffer buffer (kill-buffer buffer) (erase-buffer)))
>
> Although I don't know if the behaviour above is to be expected,

It is expected (and is not related to anything starttls-negotiate-gnutls
is doing AFAICS). The Elisp manual section on "Killing Buffers" cautions
about such usage.