From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: 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: Wed, 23 Oct 2013 00:17:49 -0400 Message-ID: <21095.19949.639350.970770@consult.pretender> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1382501956 11675 80.91.229.3 (23 Oct 2013 04:19:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2013 04:19:16 +0000 (UTC) Cc: Ted Zlatanov , 15648@debbugs.gnu.org To: Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 23 06:19:16 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 1VYpud-000244-Uh for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Oct 2013 06:19:16 +0200 Original-Received: from localhost ([::1]:47591 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYpud-0003GQ-Ed for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Oct 2013 00:19:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYpuV-0003GI-LB for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 00:19:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYpuQ-00027P-5Z for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 00:19:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYpuQ-00027L-19 for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 00:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VYpuP-0006il-LV for bug-gnu-emacs@gnu.org; Wed, 23 Oct 2013 00:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Oct 2013 04:19:01 +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: moreinfo Original-Received: via spool by 15648-submit@debbugs.gnu.org id=B15648.138250190725792 (code B ref 15648); Wed, 23 Oct 2013 04:19:01 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 23 Oct 2013 04:18:27 +0000 Original-Received: from localhost ([127.0.0.1]:36614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VYptp-0006hv-Vg for submit@debbugs.gnu.org; Wed, 23 Oct 2013 00:18:26 -0400 Original-Received: from vms173007pub.verizon.net ([206.46.173.7]:41267) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VYptm-0006hd-Gk for 15648@debbugs.gnu.org; Wed, 23 Oct 2013 00:18:23 -0400 Original-Received: from consult.pretender ([unknown] [72.93.211.25]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MV30056MT9QUR40@vms173007.mailsrvcs.net> for 15648@debbugs.gnu.org; Tue, 22 Oct 2013 23:18:01 -0500 (CDT) Original-Received: from consult.pretender (consult.pretender [127.0.0.1]) by consult.pretender (8.14.4/8.14.4) with ESMTP id r9N4HnHU015289; Wed, 23 Oct 2013 00:17:50 -0400 In-reply-to: <21094.64459.131668.849138@consult.pretender> X-Mailer: VM 8.2.0b under 23.1.1 (i386-redhat-linux-gnu) 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:79521 Archived-At: emacs@kosowsky.org wrote at about 18:27:23 -0400 on Tuesday, October 22, 2013: > emacs@kosowsky.org wrote at about 15:10:29 -0400 on Tuesday, October 22, 2013: > > emacs@kosowsky.org wrote at about 11:41:09 -0400 on Tuesday, October 22, 2013: > > > emacs@kosowsky.org wrote at about 11:23:59 -0400 on Tuesday, October 22, 2013: > > > > Ted Zlatanov wrote at about 09:27:06 -0400 on Tuesday, October 22, 2013: > > > > > On Mon, 21 Oct 2013 15:30:40 -0400 wrote: > > > > > > > > > > > Ted Zlatanov wrote at about 10:22:03 -0400 on Monday, October 21, 2013: > > > > > >> On Fri, 18 Oct 2013 14:29:04 -0400 "" wrote: > > > > > >> > > > > > >> > Fault Module Name: libgnutls-28.dll > > > > > >> ... > > > > > >> > That being said, I downloaded 24.3 from the gnu site and tried it with > > > > > >> > the latest gnutls-3.0.9 dll's from the suggested > > > > > >> > http://sourceforge.net/projects/ezwinports/files/ site. > > > > > >> > > > > > >> > And SAME crash of emacs! > > > > > >> > > > > > >> Could you please try with the latest 3.x from > > > > > >> ftp://ftp.gnutls.org/gcrypt/gnutls/w32/ ? > > > > > >> > > > > > > Same crash with 3.2.4 as with 3.0.9 > > > > > > > > > > Sorry, I don't know how you can be sure of the library loaded in > > > > > Windows. Did you put the DLL in the same directory? > > > > > > > > The dll's are in a directory that lies within my system PATH. > > > > I know they are loaded because (gnutls-available-p) only proves true > > > > when I have all the related dll's in the PATH. > > > > > > > > > > > > > > >> The `gnutls-boot' function is pretty inoffensive so let's make sure the > > > > > >> basics are covered before we dig into the C code. > > > > > > > > > > Are you able to debug the Emacs executable? I don't know if the build > > > > > you're using includes the necessary symbols, but a backtrace with at > > > > > least function names would be extremely helpful to figure this out. > > > > > > > > I just used edebug... for the trace I submitted... > > > > > > > > > > Does the problem occur to any server or just the one you listed? You > > > > > can test with > > > > > > > > > > (open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps") > > > > > > > > > > > > > This gave the same crash! > > > > > > > > > It's strange that there's been no other reports of this issue. Do you > > > > > have access to any other systems where you can test? > > > > > > > > Could it have anything to do with 64-bit Win7? > > > > Could there be any conflicts with cygwin x86_64 that I have installed > > > > (though I purposely didn't install cygwin gnutls) -- but could other > > > > dll's be in conflict? > > > > > > OK - I answered my own question. > > > There seems to be an incompatibility with the cygwin-mount library... > > > > In particular, the problem seems to be with the called cygwin mount > > program (/bin/mount.exe). Replacing it with /bin/true.exe prevents the > > crash. > > > > I wonder whether this is a dll incompatibility with cygwin.dll or in > > particular the x86_64 version... > > I did some more troubleshooting... actually, I don't think it is a > cygwin.dll problem nor is it a problem with the cygwin program > mount.exe. > > > The problem seems to be with the lisp code in cygwin-mount-activate in > terms of how it changes file-name-handler-alist, > substitute-in-file-name, and expand-file-name. > > I say this because gnutls causes the crash after > (cygwin-mount-activate) is run. But if you wait to run > (cygwin-mount-deactivate), then it won't crash. So the problem isn't > with whether mount.exe has been run (I also double checked this by > manually running mount.exe via call-process). Rather, it has something > to do with the file name substitutions set up. > > So, while the physical crash may be somewhere in the lisp code. The > issue is with how the cygwin file name handler lisp code interacts with the > gnutls code... Oops I spoke too soon. Cygwin-mount works just fine and properly parses the file names in the guntls code. Rather, the problem is in how the C-code handles the Cygwin/Linux style paths enumerated in the Lisp variable: (defcustom gnutls-trustfiles '( "/etc/ssl/certs/ca-certificates.crt" ; Debian, Ubuntu, Gentoo and Arch Linux "/etc/pki/tls/certs/ca-bundle.crt" ; Fedora and RHEL "/etc/ssl/ca-bundle.pem" ; Suse "/usr/ssl/certs/ca-bundle.crt" ; Cygwin ) If I set the final element to the Windows style path equivalent: "C:/cygwin/usr/ssl/certs/ca-bundle.crt" then gnutls works fine without crashing. So, the problem clearly is with *nix-style paths Stepping through the *Lisp* code shows that the file paths are all properly parsed when cygwin-mount is loaded/activated. Indeed, file-exists-p properly recognizes the cygwin path "/usr/ssl/certs/ca-bundle.crt" and returns nil on the other paths that don't exist in a standard Cygwin setup. Note that if cygwin-mount is not loaded/activated, then "/usr/ssl/certs/ca-bundle.crt" (along with the other list elements) fails the file-exists-p test in gnutls-negotiate so that 'trustfiles' gets set to nil which explains why it doesn't crash in the case when cygwin-mount is not used since trivially 'trustfiles' has no paths associated with it. So, basically, we have the following Catch-22. If cygwin-mount is not loaded/activated, then the cert location for Cygwin is never found. If cygwin-mount is activated then it causes a crash. The result being that in Windows, no certs are ever loaded when using the default definition of gnutls-trustfiles Presumably the problem is that the C-code doesn't know how to deal with a Cygwin (*nix) style path that has been properly recognized by the Lisp code (via cygwin-mount). It seems like there are two potential solutions: 1. Use Windows-style paths in the definition of gnutls-trustfiles (this should work in Linux too, since "C:/usr/ssl/certs/ca-bundle.crt" will generally fail the file-exists-p test) 2. Add cygwin-mount functionality to the C-code so that it can parse cygwin (Unix) style paths. In any case, I imagine the C-code crashes because it sees a Unix-style path while expecting a Windows style path... that being said the C-code should be better behaved than that... at a minimum the code should check to make sure the certificate file path is well-formed and exists.