From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely, bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely Date: Fri, 25 Oct 2013 17:09:13 +0300 Message-ID: <83iowlh27q.fsf@gnu.org> References: <21089.32240.198931.971000@consult.pretender> <87fvrun1pw.fsf@flea.lifelogs.com> <21093.32992.278229.646703@consult.pretender> <877gd5mo5x.fsf@flea.lifelogs.com> <21094.39055.449629.706850@consult.pretender> <21094.40085.664080.69561@consult.pretender> <21094.52645.645440.977584@consult.pretender> <21094.64459.131668.849138@consult.pretender> <21095.19949.639350.970770@consult.pretender> <83wql4hvam.fsf@gnu.org> <21096.920.835718.562924@consult.pretender> <83hac7j2a2.fsf@gnu.org> <21097.58066.940940.323995@consult.pretender> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1382710218 24006 80.91.229.3 (25 Oct 2013 14:10:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Oct 2013 14:10:18 +0000 (UTC) Cc: tzz@lifelogs.com, 15648@debbugs.gnu.org To: emacs@kosowsky.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 25 16:10:22 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VZi5h-0005VE-6l for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Oct 2013 16:10:17 +0200 Original-Received: from localhost ([::1]:59492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZi5g-00067f-LT for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Oct 2013 10:10:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZi5Y-000655-7R for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 10:10:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZi5T-0002P6-8r for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 10:10:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZi5T-0002Os-5X for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 10:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VZi5S-0005Ip-EL for bug-gnu-emacs@gnu.org; Fri, 25 Oct 2013 10:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Oct 2013 14:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15648-submit@debbugs.gnu.org id=B15648.138271017320335 (code B ref 15648); Fri, 25 Oct 2013 14:10:02 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 25 Oct 2013 14:09:33 +0000 Original-Received: from localhost ([127.0.0.1]:43508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZi4y-0005Hv-N0 for submit@debbugs.gnu.org; Fri, 25 Oct 2013 10:09:33 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:36205) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VZi4v-0005HZ-3C for 15648@debbugs.gnu.org; Fri, 25 Oct 2013 10:09:30 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MV800M0099DIC00@a-mtaout20.012.net.il> for 15648@debbugs.gnu.org; Fri, 25 Oct 2013 17:09:22 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MV800MLJ9ZMC5A0@a-mtaout20.012.net.il>; Fri, 25 Oct 2013 17:09:22 +0300 (IDT) In-reply-to: <21097.58066.940940.323995@consult.pretender> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79636 Archived-At: > From: > Date: Thu, 24 Oct 2013 23:17:38 -0400 > Cc: emacs@kosowsky.org, tzz@lifelogs.com, 15648@debbugs.gnu.org > > Thread 1 (Thread 124728.0x31b44): > #0 0x6d099192 in _gnutls_record_buffer_get_size () > from C:\kosowsky\bin\libgnutls-28.dll > #1 0x6d0995c8 in gnutls_record_check_pending () > from C:\kosowsky\bin\libgnutls-28.dll > #2 0x01015e15 in wait_reading_process_output () > #3 0x0088e7d8 in ?? () > (gdb) Thanks, this tells everything, I think. Ted, could you please help me out a bit here? I think I understand what is going on: we are passing a NULL session to gnutls_record_check_pending. What happens next is predictable: gnutls_record_check_pending calls _gnutls_record_buffer_get_size, which does this: return session->internals.record_buffer.byte_length; I.e., it dereferences a NULL pointer. However, to find the best place where to fix this in Emacs, could you please help me understand in more detail what happens in this case? I imagine that gnutls-boot is called with the parameters that specify a certificate file that GnuTLS cannot access. But why isn't this caught inside gnutls-boot, and how come we allow a NULL gnutls_state be plugged into the process object? This fragment from gnutls-boot: GNUTLS_LOG (1, max_log_level, "gnutls_init"); ret = fn_gnutls_init (&state, GNUTLS_CLIENT); XPROCESS (proc)->gnutls_state = state; if (ret < GNUTLS_E_SUCCESS) return gnutls_make_error (ret); ought to fail. The bug report cites this error message: GnuTLS error: #, -64 Is that error the result of the above error checking? If so, perhaps the problem is that we leave the process object marked as a GnuTLS process, but with a NULL state? Should we remove the mark, or maybe delete the process object in gnutls-negotiate? Thanks.