bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#719: Crash opening UNC file


From: john naegle
Subject: bug#719: Crash opening UNC file
Date: Fri, 15 Aug 2008 09:20:12 -0400

On a hunch, I commented everything out in my .emacs file and tried to
re-open the file.  I was able to open it without a crash, so I
systematically added things back until I could reproduce the crash.
The culprit turned out to be this line: (require 'rails).

Here are the answers to your questions if you want to pursue this
further.  Let me know if you would like my .emacs file.

Trying to open //server/software/file.txt also crashed.

Here is everything I was able to get out of GDB, it didn't seem that
helpful to me:

Let me know if you want me to try anything else.

This debugging session was started by:

#1) Launching C:\Program Files\emacs-22.2\bin\runemacs.exe
#2) find-file \\server\software\file.txt
#3) Emacs crash dialog presented
#4) gdb -p <pid>

$ gdb -p 2616
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Attaching to process 2616

[Switching to thread 2616.0x870]
(gdb) info threads
* 3 thread 2616.0x870  0x77f9193d in ntdll!DbgUiConnectToDbg ()
  2 thread 2616.0x984  0x77e585c7 in USER32!GetMenuItemRect ()
  1 thread 2616.0xaac  0x77e58b53 in WaitMessage ()

(gdb) bt full
#0  0x77f9193d in ntdll!DbgUiConnectToDbg ()
No symbol table info available.
#1  0x7c57fecd in KERNEL32!DebugActiveProcess ()
No symbol table info available.
#2  0x7c57b3bc in lstrcmpiW ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

(gdb) thread 2
[Switching to thread 2 (thread 2616.0x984)]#0  0x77e585c7 in USER32!GetMenuItemR
ect ()
(gdb) bt full
#0  0x77e585c7 in USER32!GetMenuItemRect ()
No symbol table info available.
#1  0x77e1698f in USER32!GetMessageA ()
No symbol table info available.
#2  0x01139207 in ?? ()
No symbol table info available.

(gdb) thread 1
[Switching to thread 1 (thread 2616.0xaac)]#0  0x77e58b53 in WaitMessage ()
(gdb) bt full
#0  0x77e58b53 in WaitMessage ()
No symbol table info available.
#1  0x77e33630 in USER32!MessageBoxA ()
No symbol table info available.
#2  0x77e44327 in USER32!CheckRadioButton ()
No symbol table info available.
#3  0x001008bc in ?? ()
No symbol table info available.


On Fri, Aug 15, 2008 at 3:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 14 Aug 2008 11:00:59 -0400
>> From: "john naegle" <john.naegle@gmail.com>
>> Cc:
>>
>> Whenever I try to open a file on a share on another computer, emacs crashes.
>
> Thank you for your report.
>
>> For instance, trying to open the file: "\\server\software\file.txt"
>> causes a crash.  This happens if I use find-file, drag a file onto
>> emacs, or double click to open a file on a hidden network share.
>>
>> If I double-escape all the backslashes, I still get the crash, eg:
>> emacs \\\\server\\software\\file.txt
>
> Does it work with forward slashes, like this:
>
>   //server/software/file.txt
>
> ?
>
>> [Switching to thread 3636.0x8d4]
>> (gdb) bt full
>> #0  0x77f9193d in ntdll!DbgUiConnectToDbg ()
>>    from /cygdrive/c/WINNT/system32/NTDLL.DLL
>> No symbol table info available.
>> #1  0x7c57fecd in KERNEL32!DebugActiveProcess ()
>>    from /cygdrive/c/WINNT/system32/KERNEL32.DLL
>> No symbol table info available.
>> #2  0x7c57b3bc in lstrcmpiW () from /cygdrive/c/WINNT/system32/KERNEL32.DLL
>> No symbol table info available.
>> #3  0x00000000 in ?? ()
>> No symbol table info available.
>
> This backtrace is not useful.  I think you are in the wrong thread.
>
> Could you please type "info threads" and then switch to each one of
> them (with "thread N", where N is the thread number displayed in the
> 1st column of what "info threads" presents), and find the main thread,
> where the backtrace goes up to the `main' function?  That's the
> backtrace we want to see.
>
> TIA
>







reply via email to

[Prev in Thread] Current Thread [Next in Thread]