bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Arvind Devarajan]

[-- Attachment #1: Type: text/plain, Size: 4043 bytes --]

{Precondition}
PC-Local: The PC in which emacs is running.
PC-Remote: The PC in which a file is created in a folder, that is shared.
PC-Local has a shortcut/mapping to the shared folder in PC-Remote. It
can hence access the file in PC-Remote via this shortcut/mapped drive.
 
{Action}
Start Emacs in PC-Local, and open the file in PC-Remote (either by C-x f
or just drag-and-drop)
 
{Observation}
Emacs crashes.
 
{Expected}
No such crash, and the file is editable/readable depending on the
permissions on the file.
 
{Emacs details}
In GNU Emacs 24.2.1 (i386-mingw-nt5.1.2600)
of 2012-08-29 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.6) --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-3.0.9/include'
 
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t
 
Major mode: Org
 
Minor modes in effect:
  auto-insert-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
 
Recent input:
M-x r e p o r t - <tab> <return>
 
Recent messages:
`epa-file' already enabled
Loading d:/vbox/shared/.emacs.d/custom.el (source)...
Loading delsel...done
Loading paren...done
Loading d:/vbox/shared/.emacs.d/custom.el (source)...done
Loading d:/vbox/shared/.emacs.d/extensions/org-outlook.el (source)...done
Loading d:/vbox/shared/.emacs.d/init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
OVERVIEW
CONTENTS...done
 
Load-path shadows:
None found.
 
Features:
(shadow sort gnus-util mail-extr emacsbug message rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils org-wl org-w3m org-vm org-rmail org-mhe org-mew org-irc
org-jsinfo org-infojs org-html org-exp ob-exp org-exp-blocks find-func
org-agenda org-info org-gnus org-docview org-bibtex bibtex org-bbdb
org-outlook org-protocol org byte-opt warnings bytecomp byte-compile
cconv macroexp advice help-fns advice-preload ob-emacs-lisp ob-tangle
ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys ob ob-eval
org-pcomplete pcomplete comint ansi-color ring org-list org-faces
org-compat org-entities org-macs noutline outline easy-mmode format-spec
regexp-opt cal-menu easymenu calendar cal-loaddefs autoinsert
org-install server paren delsel cus-start cus-load aes epa-file epa
derived epg epg-config cl time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process multi-tty emacs) 

[-- Attachment #2: Type: text/html, Size: 4601 bytes --]

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Eli Zaretskii]

> From: Arvind Devarajan <arvind.devarajan@outlook.com>
> Date: Thu, 11 Oct 2012 14:08:21 +0530
> 
> I just noticed that this does not happen if the files are accessed via 'mapped' drives. Happens only when UNC paths are used.

I cannot reproduce this here.  I tried on 2 different networks with 4
different machines, and couldn't reproduce the crash, both when a
shared directory is mapped to a drive letter and when using UNCs.  I
see the expected behavior: I can visit files in the shared remote
directory, and if the directory's sharing permissions allow only
read-only access, I get an error message when I try updating files in
it.

Does this happen in "emacs -Q"?  If not, please try to identify which
of your customizations could be related (i.e. if removed from .emacs,
the crashes disappear).

If the problem persists in "emacs -Q", perhaps you left out some
crucial detail of the recipe to reproduce the problem.  Please
describe the recipe in more detail, including how exactly you make a
directory shared, what permissions you define for its access, etc.

Alternatively, if you or someone else who reads this can reproduce the
problem under a debugger and send a backtrace, we could perhaps cut to
the chase much faster.  (If you want to give this a try, you will
probably need a development snapshot, because I believe the official
releases have their binaries stripped, so a debugger will give no
useful information.)

Thanks.

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Eli Zaretskii]

[Please keep the bug address on the CC list.]

> From: Arvind Devarajan <arvind.devarajan@outlook.com>
> Date: Mon, 15 Oct 2012 09:12:57 +0530
> 
> I did some more experiments this weekend, and I noticed the following:
> 1. This does not depend on my customizations
> 2. Interestingly, and I noticed this after your reply, that you were right in not able to reproduce this (blame me for this). I am surprised that it happens only when I access a shared folder that actually exists on a Linux system - it is shared via Samba.

This is important info, thanks.

> 3. When emacs crashed, I clicked the 'more info' link that windows crash-handler shows. It gave this info: ModName: rpcrt4.dll, ModVer: 5.1.2600.6022 (only relavant info shown).
> 
> Since I am more a Linux user, and have no experience on setting up a windows debug environment, I am not in a position to give you call stack. I shall attempt this over this week if you say the above info is not sufficient.

Unfortunately, it isn't sufficient.

First, please right-click on "My Computer", select "Manage", then
expand "Event Viewer" in the left pane (by clicking on the "+" sign to
its left), then click "Application".  Now find in the right pane the
log entry for the crash, double-click on that line, and click the
copy to clipboard button on the right near the top, below the two
buttons with arrows.  Finally, paste from the clipboard to your mailer
and post everything here.  This might at least give us the address
where Emacs crashed.

However, I think that this, too, will be insufficient, because the
address will be within rpcrt4.dll, which is not part of Emacs.  So
please do install a Windows port of GDB from here:

  http://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/GDB-7.5/gdb-7.5-1-mingw32-bin.tar.lzma/download

and then run it under GDB.  When it crashes, please post here the
backtrace you get.

It is advisable to do this with the development snapshot, available
from here:

   http://alpha.gnu.org/gnu/emacs/windows/

This is because snapshot binaries are not stripped of the debug info,
so you will be able to produce a more meaningful information with GDB.

TIA

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Eli Zaretskii]

Please also try setting w32-get-true-file-attributes to t before you
type "C-x C-f" to open a remote file.  Does that crash as well?

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Arvind Devarajan]

[-- Attachment #1: Type: text/plain, Size: 4336 bytes --]


Thanks for reply. I got something interesting:
1) Problem does not occur in the development snapshot
2) I anyway collected the backtrace via MinGW gdb. I can just take the development snapshot, but I think it might be interesting for you to know the reason:

(gdb) bt

#0  0x77e82fed in RPCRT4!I_RpcNegotiateTransferSyntax ()

   from C:\WINNT\system32\rpcrt4.dll

#1  0x77e7a741 in RPCRT4!NdrAllocate () from C:\WINNT\system32\rpcrt4.dll

#2  0x77e7f64c in RPCRT4!NdrConformantStructBufferSize ()

   from C:\WINNT\system32\rpcrt4.dll

#3  0x77e7ae23 in RPCRT4!NdrpMemoryIncrement ()

   from C:\WINNT\system32\rpcrt4.dll

#4  0x77e89a57 in RpcBindingSetAuthInfoExW ()

   from C:\WINNT\system32\rpcrt4.dll

#5  0x77e899d2 in RpcBindingSetAuthInfoExW ()

   from C:\WINNT\system32\rpcrt4.dll

#6  0x77e89c5c in RpcBindingSetAuthInfoExW ()

   from C:\WINNT\system32\rpcrt4.dll

#7  0x77e7cc59 in RPCRT4!NdrConformantArrayBufferSize ()

   from C:\WINNT\system32\rpcrt4.dll

#8  0x77e7ae23 in RPCRT4!NdrpMemoryIncrement ()

   from C:\WINNT\system32\rpcrt4.dll

#9  0x77e86d08 in RPCRT4!NdrComplexStructFree ()

   from C:\WINNT\system32\rpcrt4.dll

#10 0x77e718cc in SimpleTypeMemorySize () from C:\WINNT\system32\rpcrt4.dll

#11 0x00819518 in ?? ()

#12 0x77ef55cc in RPCRT4!CStdStubBuffer_CountRefs ()

   from C:\WINNT\system32\rpcrt4.dll

#13 0x77de5ab8 in LsaICLookupSids () from C:\WINNT\system32\advapi32.dll

#14 0x77ddf4b0 in GetSidLengthRequired () from C:\WINNT\system32\advapi32.dll

#15 0x77de5a67 in LsaICLookupSids () from C:\WINNT\system32\advapi32.dll

#16 0x0086d600 in ?? ()

#17 0x77de58f6 in LsaLookupSids () from C:\WINNT\system32\advapi32.dll

#18 0x77de57a7 in LookupAccountSidW () from C:\WINNT\system32\advapi32.dll

#19 0x77e0d99b in LookupAccountSidA () from C:\WINNT\system32\advapi32.dll

#20 0x01029dfb in lookup_account_sid@28 ()

#21 0x0102a10d in get_name_and_id ()

#22 0x0102a284 in get_file_owner_and_group ()

#23 0x0102c2a7 in stat ()

#24 0x0103bdf7 in Finsert_file_contents ()

#25 0x0100ee96 in Ffuncall ()

#26 0x0107139d in exec_byte_code ()

#27 0x01071f9a in Fbyte_code ()

#28 0x0100e48d in eval_sub ()

#29 0x0101111b in internal_lisp_condition_case ()

#30 0x01070ae5 in exec_byte_code ()

#31 0x0100e9ec in funcall_lambda ()

#32 0x0100ed43 in Ffuncall ()

#33 0x0107139d in exec_byte_code ()

#34 0x0100e9ec in funcall_lambda ()

#35 0x0100ed43 in Ffuncall ()

#36 0x0107139d in exec_byte_code ()

#37 0x0100e9ec in funcall_lambda ()

#38 0x0100ed43 in Ffuncall ()

#39 0x0107139d in exec_byte_code ()

#40 0x0100e9ec in funcall_lambda ()

#41 0x0100ed43 in Ffuncall ()

#42 0x0107139d in exec_byte_code ()

#43 0x0100e9ec in funcall_lambda ()

#44 0x0100ed43 in Ffuncall ()

#45 0x0107139d in exec_byte_code ()

#46 0x01071f9a in Fbyte_code ()

#47 0x0100e48d in eval_sub ()

#48 0x0100d4fb in internal_catch ()

#49 0x01070b2b in exec_byte_code ()

#50 0x0100e9ec in funcall_lambda ()

#51 0x0100ed43 in Ffuncall ()

#52 0x0107139d in exec_byte_code ()

#53 0x0100e9ec in funcall_lambda ()

#54 0x0100ed43 in Ffuncall ()

#55 0x0100f1fe in call1 ()

#56 0x0104c4cd in mapcar1 ()

#57 0x0104f6db in Fmapc ()

#58 0x0100eef0 in Ffuncall ()

#59 0x0107139d in exec_byte_code ()

#60 0x0100e9ec in funcall_lambda ()

#61 0x0100ed43 in Ffuncall ()

#62 0x010728ec in Fcall_interactively ()

#63 0x0100eed9 in Ffuncall ()

#64 0x0100f1a0 in call3 ()

#65 0x010259e5 in command_loop_1 ()

#66 0x0100d5b1 in internal_condition_case ()

#67 0x0101cf14 in command_loop_2 ()

#68 0x0100d4fb in internal_catch ()

#69 0x0101dc8c in recursive_edit_1 ()

#70 0x0101df14 in Frecursive_edit ()

#71 0x011a1c47 in main ()

A debugging session is active.



                Inferior 1 [process 7112] will be killed.



Quit anyway? (y or n)



________________________________
From: Eli Zaretskii
Sent: 16-10-2012 01:26
To: arvind.devarajan@outlook.com
Cc: 12621@debbugs.gnu.org
Subject: Re: bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

Please also try setting w32-get-true-file-attributes to t before you
type "C-x C-f" to open a remote file.  Does that crash as well?

[-- Attachment #2: Type: text/html, Size: 6444 bytes --]

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Eli Zaretskii]

> From: Arvind Devarajan <arvind.devarajan@outlook.com>
> Date: Tue, 16 Oct 2012 19:09:42 +0530
> CC: "12621@debbugs.gnu.org" <12621@debbugs.gnu.org>
> 
> 1) Problem does not occur in the development snapshot

That's good news, thanks.

> 2) I anyway collected the backtrace via MinGW gdb. I can just take the development snapshot, but I think it might be interesting for you to know the reason:

This explains quite a lot.  I still don't fully understand why the
system call crashed so deeply inside the RPC DLL, but maybe now it's
not as important to understand that, because the next Emacs release
will probably work OK, since it's based on the code in the development
snapshot.

One thing to try in v24.2 is set w32-get-true-file-attributes to a nil
value before opening the file.  This should bypass the call to
LookupAccountSid, the API whose call crashed.

For the record, what do you see if you type "C-x d" to invoke Dired on
the directory whose files crash Emacs 24.2?  I'm mainly interested in
the owner and the group shown by Dired for those files.  Please try
this in both versions of Emacs (v24.2 is likely to crash, but I hope
the development snapshot will not; if it does, please try to produce a
backtrace form it).

Thanks.

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Arvind Devarajan]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

Sorry for the late reply...
I see that dired does not crash, unless a file is selected for opening after the dired listed the files.

Secondly, I see that emacs crashes even with w32-get-true-file-attributes is set to nil.
________________________________
From: Eli Zaretskii
Sent: 16-10-2012 23:03
To: Arvind Devarajan
Cc: 12621@debbugs.gnu.org
Subject: Re: bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

> From: Arvind Devarajan <arvind.devarajan@outlook.com>
> Date: Tue, 16 Oct 2012 19:09:42 +0530
> CC: "12621@debbugs.gnu.org" <12621@debbugs.gnu.org>
>
> 1) Problem does not occur in the development snapshot

That's good news, thanks.

> 2) I anyway collected the backtrace via MinGW gdb. I can just take the development snapshot, but I think it might be interesting for you to know the reason:

This explains quite a lot.  I still don't fully understand why the
system call crashed so deeply inside the RPC DLL, but maybe now it's
not as important to understand that, because the next Emacs release
will probably work OK, since it's based on the code in the development
snapshot.

One thing to try in v24.2 is set w32-get-true-file-attributes to a nil
value before opening the file.  This should bypass the call to
LookupAccountSid, the API whose call crashed.

For the record, what do you see if you type "C-x d" to invoke Dired on
the directory whose files crash Emacs 24.2?  I'm mainly interested in
the owner and the group shown by Dired for those files.  Please try
this in both versions of Emacs (v24.2 is likely to crash, but I hope
the development snapshot will not; if it does, please try to produce a
backtrace form it).

Thanks.

[-- Attachment #2: Type: text/html, Size: 3052 bytes --]

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Eli Zaretskii]

> From: Arvind Devarajan <arvind.devarajan@outlook.com>
> Date: Mon, 22 Oct 2012 15:49:36 +0530
> CC: "12621@debbugs.gnu.org" <12621@debbugs.gnu.org>
> 
> Sorry for the late reply...

No problem.

> Secondly, I see that emacs crashes even with w32-get-true-file-attributes is set to nil.

That's strange.  Can you show a GDB backtrace in this case, please?
When w32-get-true-file-attributes is nil, Emacs is not supposed to
call the LookupAccountSid API, which was the one that led to the crash
in your previous backtrace.

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Arvind Devarajan]

[-- Attachment #1: Type: text/plain, Size: 5302 bytes --]

Here’s the call stack (and also see below the callstack for the result of C-h v w32-get-true-file-attributes):

#0  0x77e82fed in RPCRT4!I_RpcNegotiateTransferSyntax ()
   from C:\WINNT\system32\rpcrt4.dll
#1  0x77e7a741 in RPCRT4!NdrAllocate () from C:\WINNT\system32\rpcrt4.dll
#2  0x77e7f64c in RPCRT4!NdrConformantStructBufferSize ()
   from C:\WINNT\system32\rpcrt4.dll
#3  0x77e7ae23 in RPCRT4!NdrpMemoryIncrement ()
   from C:\WINNT\system32\rpcrt4.dll
#4  0x77e89a57 in RpcBindingSetAuthInfoExW ()
   from C:\WINNT\system32\rpcrt4.dll
#5  0x77e899d2 in RpcBindingSetAuthInfoExW ()
   from C:\WINNT\system32\rpcrt4.dll
#6  0x77e89c5c in RpcBindingSetAuthInfoExW ()
   from C:\WINNT\system32\rpcrt4.dll
#7  0x77e7cc59 in RPCRT4!NdrConformantArrayBufferSize ()
   from C:\WINNT\system32\rpcrt4.dll
#8  0x77e7ae23 in RPCRT4!NdrpMemoryIncrement ()
   from C:\WINNT\system32\rpcrt4.dll
#9  0x77e86d08 in RPCRT4!NdrComplexStructFree ()
   from C:\WINNT\system32\rpcrt4.dll
#10 0x77e718cc in SimpleTypeMemorySize () from C:\WINNT\system32\rpcrt4.dll
#11 0x00819518 in ?? ()
#12 0x77ef55cc in RPCRT4!CStdStubBuffer_CountRefs ()
   from C:\WINNT\system32\rpcrt4.dll
#13 0x77de5ab8 in LsaICLookupSids () from C:\WINNT\system32\advapi32.dll
#14 0x77ddf4b0 in GetSidLengthRequired () from C:\WINNT\system32\advapi32.dll
#15 0x77de5a67 in LsaICLookupSids () from C:\WINNT\system32\advapi32.dll
#16 0x0086d7a8 in ?? ()
#17 0x77de58f6 in LsaLookupSids () from C:\WINNT\system32\advapi32.dll
#18 0x77de57a7 in LookupAccountSidW () from C:\WINNT\system32\advapi32.dll
#19 0x77e0d99b in LookupAccountSidA () from C:\WINNT\system32\advapi32.dll
#20 0x01029dfb in lookup_account_sid@28 ()
#21 0x0102a10d in get_name_and_id ()
#22 0x0102a284 in get_file_owner_and_group ()
#23 0x0102c2a7 in stat ()
#24 0x0103bdf7 in Finsert_file_contents ()
#25 0x0100ee96 in Ffuncall ()
#26 0x0107139d in exec_byte_code ()
#27 0x01071f9a in Fbyte_code ()
#28 0x0100e48d in eval_sub ()
#29 0x0101111b in internal_lisp_condition_case ()
#30 0x01070ae5 in exec_byte_code ()
#31 0x0100e9ec in funcall_lambda ()
#32 0x0100ed43 in Ffuncall ()
#33 0x0107139d in exec_byte_code ()
#34 0x0100e9ec in funcall_lambda ()
#35 0x0100ed43 in Ffuncall ()
#36 0x0107139d in exec_byte_code ()
#37 0x0100e9ec in funcall_lambda ()
#38 0x0100ed43 in Ffuncall ()
#39 0x0107139d in exec_byte_code ()
#40 0x0100e9ec in funcall_lambda ()
#41 0x0100ed43 in Ffuncall ()
#42 0x0107139d in exec_byte_code ()
#43 0x0100e9ec in funcall_lambda ()
#44 0x0100ed43 in Ffuncall ()
#45 0x0107139d in exec_byte_code ()
#46 0x01071f9a in Fbyte_code ()
#47 0x0100e48d in eval_sub ()
#48 0x0100d4fb in internal_catch ()
#49 0x01070b2b in exec_byte_code ()
#50 0x0100e9ec in funcall_lambda ()
#51 0x0100ed43 in Ffuncall ()
#52 0x0107139d in exec_byte_code ()
#53 0x0100e9ec in funcall_lambda ()
#54 0x0100ed43 in Ffuncall ()
#55 0x0100f1fe in call1 ()
#56 0x0104c4cd in mapcar1 ()
#57 0x0104f6db in Fmapc ()
#58 0x0100eef0 in Ffuncall ()
#59 0x0107139d in exec_byte_code ()
#60 0x0100e9ec in funcall_lambda ()
#61 0x0100ed43 in Ffuncall ()
#62 0x010728ec in Fcall_interactively ()
#63 0x0100eed9 in Ffuncall ()
#64 0x0100f1a0 in call3 ()
#65 0x010259e5 in command_loop_1 ()
#66 0x0100d5b1 in internal_condition_case ()
#67 0x0101cf14 in command_loop_2 ()
#68 0x0100d4fb in internal_catch ()
#69 0x0101dc8c in recursive_edit_1 ()
#70 0x0101df14 in Frecursive_edit ()
#71 0x011a1c47 in main ()
A debugging session is active.

        Inferior 1 [process 5440] will be killed.

Quit anyway? (y or n)

---
Result of C-h v w32-get-true-file-attributes
---
w32-get-true-file-attributes is a variable defined in `C source code'.
Its value is nil

Documentation:
Non-nil means determine accurate file attributes in `file-attributes'.
This option controls whether to issue additional system calls to determine
accurate link counts, file type, and ownership information.  It is more
useful for files on NTFS volumes, where hard links and file security are
supported, than on volumes of the FAT family.

Without these system calls, link count will always be reported as 1 and file
ownership will be attributed to the current user.
The default value `local' means only issue these system calls for files
on local fixed drives.  A value of nil means never issue them.
Any other non-nil value means do this even on remote and removable drives
where the performance impact may be noticeable even on modern hardware.
________________________________
From: Eli Zaretskii
Sent: 22-10-2012 22:44
To: Arvind Devarajan
Cc: 12621@debbugs.gnu.org
Subject: Re: bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

> From: Arvind Devarajan <arvind.devarajan@outlook.com>
> Date: Mon, 22 Oct 2012 15:49:36 +0530
> CC: "12621@debbugs.gnu.org" <12621@debbugs.gnu.org>
>
> Sorry for the late reply...

No problem.

> Secondly, I see that emacs crashes even with w32-get-true-file-attributes is set to nil.

That's strange.  Can you show a GDB backtrace in this case, please?
When w32-get-true-file-attributes is nil, Emacs is not supposed to
call the LookupAccountSid API, which was the one that led to the crash
in your previous backtrace.

[-- Attachment #2: Type: text/html, Size: 7168 bytes --]

bug#12621: Win32 (Ver:24.2); Crashes when files from shared folders are accessed

[Eli Zaretskii]

> From: Arvind Devarajan <arvind.devarajan@outlook.com>
> Date: Tue, 23 Oct 2012 17:46:54 +0530
> CC: "12621@debbugs.gnu.org" <12621@debbugs.gnu.org>
> 
> Here’s the call stack (and also see below the callstack for the result of C-h v w32-get-true-file-attributes):


> #19 0x77e0d99b in LookupAccountSidA () from C:\WINNT\system32\advapi32.dll
> #20 0x01029dfb in lookup_account_sid@28 ()
> #21 0x0102a10d in get_name_and_id ()
> #22 0x0102a284 in get_file_owner_and_group ()
> #23 0x0102c2a7 in stat ()
> #24 0x0103bdf7 in Finsert_file_contents ()

OK, I see what I missed now: insert-file-contents forcibly binds
w32-get-true-file-attributes to t.  Hmm, I will see what I can do with
this (although I still don't understand why this crashes).

Thanks.