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

[emacs]

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 <emacs@kosowsky.org> wrote: 
 >  >  >  > 
 >  >  >  > > Ted Zlatanov wrote at about 10:22:03 -0400 on Monday, October 21, 
 > 2013:
 >  >  >  > >> On Fri, 18 Oct 2013 14:29:04 -0400 "" <emacs@kosowsky.org> 
 > 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...