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: Acknowledgement (Win32 (Ver:24.2); Crashes when files from shared folders are accessed)

[Arvind Devarajan]

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

I just noticed that this does not happen if the files are accessed via 'mapped' drives. Happens only when UNC paths are used.


________________________________
From: GNU bug Tracking System
Sent: 11-10-2012 09:18
To: Arvind Devarajan
Subject: bug#12621: Acknowledgement (Win32 (Ver:24.2); Crashes when files from shared folders are accessed)

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@gnu.org

If you wish to submit further information on this problem, please
send it to 12621@debbugs.gnu.org.

Please do not send mail to help-debbugs@gnu.org unless you wish
to report a problem with the Bug-tracking system.

--
12621: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12621
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

[-- Attachment #2: Type: text/html, Size: 2222 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.

bug#12621: Emacs 24.1 crashing on Win7

[Arunas Ruksnaitis]

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

Just to confirm, this is a big problem for me, too.
My observations confirm the original report.
Stack trace, should it help, is here. I guess "lookup_account_sid" is passing an invalid lpSid?

#0  0x75c1511c in RPCRT4!NdrProxyFreeBuffer () from C:\Windows\syswow64\rpcrt4.dll
#1  0x76dcbb9e in UpdateTraceA () from C:\Windows\syswow64\advapi32.dll
#2  0x0087946c in ?? ()
#3  0x75c0e69d in RPCRT4!MesDecodeIncrementalHandleCreate () from C:\Windows\syswow64\rpcrt4.dll
#4  0x0087946c in ?? ()
#5  0x75c11eda in RpcErrorEndEnumeration () from C:\Windows\syswow64\rpcrt4.dll
#6  0x0087946c in ?? ()
#7  0x75c06bf0 in RPCRT4!NdrOleAllocate () from C:\Windows\syswow64\rpcrt4.dll
#8  0x0087946c in ?? ()
#9  0x75c125e1 in RpcErrorEndEnumeration () from C:\Windows\syswow64\rpcrt4.dll
#10 0x76dcc0a6 in UpdateTraceA () from C:\Windows\syswow64\advapi32.dll
#11 0x0087946c in ?? ()
#12 0x75c12557 in RpcErrorEndEnumeration () from C:\Windows\syswow64\rpcrt4.dll
#13 0x0087998c in ?? ()
#14 0x75c1253b in RpcErrorEndEnumeration () from C:\Windows\syswow64\rpcrt4.dll
#15 0x0087998c in ?? ()
#16 0x75c0e713 in RPCRT4!MesDecodeIncrementalHandleCreate () from C:\Windows\syswow64\rpcrt4.dll
#17 0x0087946c in ?? ()
#18 0x75c06bf0 in RPCRT4!NdrOleAllocate () from C:\Windows\syswow64\rpcrt4.dll
#19 0x0087946c in ?? ()
#20 0x75c13c1a in RPCRT4!I_RpcParseSecurity () from C:\Windows\syswow64\rpcrt4.dll
#21 0x76dcfa8e in LsaGetQuotasForAccount () from C:\Windows\syswow64\advapi32.dll
#22 0x75c00db7 in UuidFromStringA () from C:\Windows\syswow64\rpcrt4.dll
#23 0x0087946c in ?? ()
#24 0x75ca0104 in ?? ()
#25 0x76dd963e in LsaICLookupSidsWithCreds () from C:\Windows\syswow64\advapi32.dll
#26 0x76dcb9c8 in UpdateTraceA () from C:\Windows\syswow64\advapi32.dll
#27 0x76dcfa6a in LsaGetQuotasForAccount () from C:\Windows\syswow64\advapi32.dll
#28 0x76dd958c in LsaICLookupSidsWithCreds () from C:\Windows\syswow64\advapi32.dll
#29 0x0098c9a8 in ?? ()
#30 0x76dd9417 in LsaManageSidNameMapping () from C:\Windows\syswow64\advapi32.dll
#31 0x76df1c27 in LookupAccountNameW () from C:\Windows\syswow64\advapi32.dll
#32 0x76df1ec6 in LookupAccountSidW () from C:\Windows\syswow64\advapi32.dll
#33 0x01029e1b in lookup_account_sid@28 ()
#34 0x0102a12d in get_name_and_id ()
#35 0x0102a2a4 in get_file_owner_and_group ()
#36 0x0102c2c7 in stat ()
#37 0x0103be17 in Finsert_file_contents ()
#38 0x0100ee96 in Ffuncall ()
#39 0x0107139d in exec_byte_code ()

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

bug#12621: Emacs 24.1 crashing on Win7

[Eli Zaretskii]

> Date: Thu, 13 Dec 2012 10:22:42 +0000 (GMT)
> From: Arunas Ruksnaitis <aris020@yahoo.co.uk>
> 
> Just to confirm, this is a big problem for me, too.
> My observations confirm the original report.
> Stack trace, should it help, is here. I guess "lookup_account_sid" is passing an invalid lpSid?

No, I don't think the Sid can be invalid, because it is validated just
before the call that crashes, by calling IsValidSid:

  if (what == UID)
    result = get_security_descriptor_owner (psd, &sid, &dflt);
  else if (what == GID)
    result = get_security_descriptor_group (psd, &sid, &dflt);
  else
    result = 0;

  if (!result || !is_valid_sid (sid))  <<<<<<<<<<<<<<<<<<<<<<<<<<<
    use_dflt = 1;
  else if (!w32_cached_id (sid, id, nm))
    {
      /* If FNAME is a UNC, we need to lookup account on the
	 specified machine.  */
      if (IS_DIRECTORY_SEP (fname[0]) && IS_DIRECTORY_SEP (fname[1])
	  && fname[2] != '\0')
	{
	  const char *s;
	  char *p;

	  for (s = fname + 2, p = machine;
	       *s && !IS_DIRECTORY_SEP (*s); s++, p++)
	    *p = *s;
	  *p = '\0';
	  mp = machine;
	}

      if (!lookup_account_sid (mp, sid, name, &name_len,
			       domain, &domain_len, &ignore)
	  || name_len > UNLEN+1)

I actually suspect that the problem might be in the server name, the
first argument to lookup_account_sid.  If you can easily reproduce
this under GDB, can you show what is the value of 'fname' and of
'machine' in the above snippet?

bug#12621: Emacs 24.1 crashing on Win7

[Arunas Ruksnaitis]

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

Can reproduce easily. No joy with symbol values:

"print fname" or "print machine:
(gdb) down

#34 0x0102a12d in get_name_and_id ()
(gdb) print machine
No symbol "machine" in current context.
(gdb) print mp
No symbol "mp" in current context.
(gdb) print fname
No symbol "fname" in current context.
 
The "machine" part of UNC is actually not a machine but a DFS server. It does not have own shares but consolidates multiple fileservers in one view.

-Arunas


________________________________
 From: Eli Zaretskii <eliz@gnu.org>
To: Arunas Ruksnaitis <aris020@yahoo.co.uk> 
Cc: 12621@debbugs.gnu.org 
Sent: Thursday, 13 December 2012, 18:04
Subject: Re: bug#12621: Emacs 24.1 crashing on Win7
 
> Date: Thu, 13 Dec 2012 10:22:42 +0000 (GMT)
> From: Arunas Ruksnaitis <aris020@yahoo.co.uk>
> 
> Just to confirm, this is a big problem for me, too.
> My observations confirm the original report.
> Stack trace, should it help, is here. I guess "lookup_account_sid" is passing an invalid lpSid?

No, I don't think the Sid can be invalid, because it is validated just
before the call that crashes, by calling IsValidSid:

  if (what == UID)
    result = get_security_descriptor_owner (psd, &sid, &dflt);
  else if (what == GID)
    result = get_security_descriptor_group (psd, &sid, &dflt);
  else
    result = 0;

  if (!result || !is_valid_sid (sid))  <<<<<<<<<<<<<<<<<<<<<<<<<<<
    use_dflt = 1;
  else if (!w32_cached_id (sid, id, nm))
    {
      /* If FNAME is a UNC, we need to lookup account on the
     specified machine.  */
      if (IS_DIRECTORY_SEP (fname[0]) && IS_DIRECTORY_SEP (fname[1])
      && fname[2] != '\0')
    {
      const char *s;
      char *p;

      for (s = fname + 2, p = machine;
           *s && !IS_DIRECTORY_SEP (*s); s++, p++)
        *p = *s;
      *p = '\0';
      mp = machine;
    }

      if (!lookup_account_sid (mp, sid, name, &name_len,
                   domain, &domain_len, &ignore)
      || name_len > UNLEN+1)

I actually suspect that the problem might be in the server name, the
first argument to lookup_account_sid.  If you can easily reproduce
this under GDB, can you show what is the value of 'fname' and of
'machine' in the above snippet?

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

bug#12621: Emacs 24.1 crashing on Win7

[Arunas Ruksnaitis]

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

...and yes, it does not crash if I provide the physical server instead of DFS.
Takes ~30 sec to open the first file and DirEd still does not display the correct owner....but does not crash.
(setf w32-get-true-file-attributes nil) does not help - opening a file takes ~30 sec
 
-Arunas


________________________________
 From: Eli Zaretskii <eliz@gnu.org>
To: Arunas Ruksnaitis <aris020@yahoo.co.uk> 
Cc: 12621@debbugs.gnu.org 
Sent: Thursday, 13 December 2012, 18:04
Subject: Re: bug#12621: Emacs 24.1 crashing on Win7
 
> Date: Thu, 13 Dec 2012 10:22:42 +0000 (GMT)
> From: Arunas Ruksnaitis <aris020@yahoo.co.uk>
> 
> Just to confirm, this is a big problem for me, too.
> My observations confirm the original report.
> Stack trace, should it help, is here. I guess "lookup_account_sid" is passing an invalid lpSid?

No, I don't think the Sid can be invalid, because it is validated just
before the call that crashes, by calling IsValidSid:

  if (what == UID)
    result = get_security_descriptor_owner (psd, &sid, &dflt);
  else if (what == GID)
    result = get_security_descriptor_group (psd, &sid, &dflt);
  else
    result = 0;

  if (!result || !is_valid_sid (sid))  <<<<<<<<<<<<<<<<<<<<<<<<<<<
    use_dflt = 1;
  else if (!w32_cached_id (sid, id, nm))
    {
      /* If FNAME is a UNC, we need to lookup account on the
     specified machine.  */
      if (IS_DIRECTORY_SEP (fname[0]) && IS_DIRECTORY_SEP (fname[1])
      && fname[2] != '\0')
    {
      const char *s;
      char *p;

      for (s = fname + 2, p = machine;
           *s && !IS_DIRECTORY_SEP (*s); s++, p++)
        *p = *s;
      *p = '\0';
      mp = machine;
    }

      if (!lookup_account_sid (mp, sid, name, &name_len,
                   domain, &domain_len, &ignore)
      || name_len > UNLEN+1)

I actually suspect that the problem might be in the server name, the
first argument to lookup_account_sid.  If you can easily reproduce
this under GDB, can you show what is the value of 'fname' and of
'machine' in the above snippet?

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

bug#12621: Emacs 24.1 crashing on Win7

[Eli Zaretskii]

> Date: Thu, 13 Dec 2012 18:30:20 +0000 (GMT)
> From: Arunas Ruksnaitis <aris020@yahoo.co.uk>
> Cc: "12621@debbugs.gnu.org" <12621@debbugs.gnu.org>
> 
> Can reproduce easily. No joy with symbol values:
> 
> "print fname" or "print machine:
> (gdb) down
> 
> #34 0x0102a12d in get_name_and_id ()
> (gdb) print machine
> No symbol "machine" in current context.
> (gdb) print mp
> No symbol "mp" in current context.
> (gdb) print fname
> No symbol "fname" in current context.

Try higher frames.

Did you compile Emacs yourself?  Also, what version of GDB is that?

> The "machine" part of UNC is actually not a machine but a DFS server. It does not have own shares but consolidates multiple fileservers in one view.

Sorry, I lost you.  What is a "DFS server", and how does it modify the
meaning of a UNC?  Can you show the full file name being referenced
here?

Thanks.

bug#12621: Emacs 24.1 crashing on Win7

[Eli Zaretskii]

> Date: Thu, 13 Dec 2012 18:41:10 +0000 (GMT)
> From: Arunas Ruksnaitis <aris020@yahoo.co.uk>
> Cc: "12621@debbugs.gnu.org" <12621@debbugs.gnu.org>
> 
> ...and yes, it does not crash if I provide the physical server instead of DFS.

Can you show a command that crashes and an equivalent command that
doesn't?

> (setf w32-get-true-file-attributes nil) does not help - opening a file takes ~30 sec

That's because insert-file-contents binds it to t when it calls
'stat'.  I'll see what I can do about that.  Dired should be faster
with w32-get-true-file-attributes, though.

bug#12621: Emacs 24.1 crashing on Win7

[Eli Zaretskii]

> Date: Thu, 13 Dec 2012 21:05:37 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 12621@debbugs.gnu.org
> 
> Sorry, I lost you.  What is a "DFS server", and how does it modify the
> meaning of a UNC?  Can you show the full file name being referenced
> here?
> [...]
> Can you show a command that crashes and an equivalent command that
> doesn't?

Actually, scratch all that.  I think we should simply always pass NULL
as the first argument of LookupAccountSid.  If you compiled Emacs by
yourself, can you try such a modification there, and see if that
helps?  I'm interested to know not only whether the crashes go away
when you use NULL, but also whether the file owner and group
information is reported correctly.

Thanks.

bug#12621: Emacs 24.1 crashing on Win7

[Arūnas Rukšnaitis]

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

Yes, I agree,  lpSystemName should be always NULL.
The w32-get-true-file-attributes variable should be taken into account.
DFS: http://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft) 
<http://en.wikipedia.org/wiki/Distributed_File_System_%28Microsoft%29>
No, I did not compile eMacs myself. I would be interested in compiling 
x64 version, but I hear it is not trivial. Can you dropbox me your version?
Thanks for your help!
On 13/12/12 19:13, Eli Zaretskii wrote:
>> Date: Thu, 13 Dec 2012 21:05:37 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 12621@debbugs.gnu.org
>>
>> Sorry, I lost you.  What is a "DFS server", and how does it modify the
>> meaning of a UNC?  Can you show the full file name being referenced
>> here?
>> [...]
>> Can you show a command that crashes and an equivalent command that
>> doesn't?
> Actually, scratch all that.  I think we should simply always pass NULL
> as the first argument of LookupAccountSid.  If you compiled Emacs by
> yourself, can you try such a modification there, and see if that
> helps?  I'm interested to know not only whether the crashes go away
> when you use NULL, but also whether the file owner and group
> information is reported correctly.
>
> Thanks.


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

bug#12621: Emacs 24.1 crashing on Win7

[Eli Zaretskii]

> Date: Thu, 13 Dec 2012 21:09:09 +0000
> From: Arūnas Rukšnaitis <aris020@yahoo.co.uk>
> CC: 12621@debbugs.gnu.org
> 
> Yes, I agree,  lpSystemName should be always NULL.

OK, I made that change on the emacs-24 branch (revision 111035).
There should be a new pretest of Emacs 24.3 out of that branch soon,
and a precompiled Windows binary will follow.  Watch the announcements
on emacs-devel.

This change will be merged to the trunk soon, so the few people who
provide snapshots of the trunk will probably soon upload a binary with
this change.

When you do get hold of a new binary with the change, please run some
tests with files on the DFS, and please report any findings.

> The w32-get-true-file-attributes variable should be taken into account.

I will try to improve things in this respect (on the trunk).

> I would be interested in compiling x64 version, but I hear it is not
> trivial.

The x64 version can for now be built only with MSVC.  MinGW64 is not
yet supported.  Volunteers are welcome.

Thanks.

bug#12621: Emacs 24.1 crashing on Win7

[Eli Zaretskii]

> Date: Fri, 14 Dec 2012 11:16:09 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 12621@debbugs.gnu.org
> 
> > The w32-get-true-file-attributes variable should be taken into account.
> 
> I will try to improve things in this respect (on the trunk).

Now done in revision 111226 on the trunk.

bug#12621: Emacs 24.1 crashing on Lose7

[Richard Stallman]

Thanks for reporting the bug, but please don't refer to Windows as a
"win".

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#12621: Emacs 24.1 crashing on Lose7

[Arunas Ruksnaitis]

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

:) Who would be using Emacs if they think Windows win?
 -Arunas

________________________________
 From: Richard Stallman <rms@gnu.org>
To: Arunas Ruksnaitis <aris020@yahoo.co.uk> 
Cc: eliz@gnu.org; 12621@debbugs.gnu.org 
Sent: Friday, 14 December 2012, 15:22
Subject: Re: bug#12621: Emacs 24.1 crashing on Lose7
 
Thanks for reporting the bug, but please don't refer to Windows as a
"win".

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

bug#12621: Emacs 24.1 crashing on Windows 7

[Andy Moreton]

On Fri 14 Dec 2012, Richard Stallman wrote:

> Thanks for reporting the bug, but please don't refer to Windows as a
> "win".

This kind if puerile comment is decidedly unhelpful.

You are very insistent on using the term GNU/Linux to describe
distributions built on the Linux kernel. Please afford others the same
courtesy, and describe their products correctly.

    AndyM

bug#12621: Emacs 24.1 crashing on Windows 7

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Fri, 14 Dec 2012 23:36:51 -0100
> 
> You are very insistent on using the term GNU/Linux to describe
> distributions built on the Linux kernel. Please afford others the same
> courtesy, and describe their products correctly.

Well, "Win7" is not a correct description, it's a shorthand.

bug#12621: Emacs 24.1 crashing on Windows 7

[Richard Stallman]

    Well, "Win7" is not a correct description, it's a shorthand.

We ask people to call the combined system GNU/Linux to show respect
for our work.  But nobody is forced to show us (or anyone else)
respect.  People who despise us are free to call the system by some
nasty name, and even to deny us credit by calling it "Linux".

I don't think a piece of proprietary software, with known spyware, DRM
and back doors, deserves respect.  Nonetheless, I usually call it
"Windows".

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#12621: Emacs 24.1 crashing on Windows 7

[Eli Zaretskii]

> Date: Sat, 15 Dec 2012 14:46:46 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: andrewjmoreton@gmail.com, 12621@debbugs.gnu.org
> 
> I don't think a piece of proprietary software, with known spyware, DRM
> and back doors, deserves respect.

Well, actually, it does, for several technical achievements that I can
only dream of when I work on modern GNU/Linux systems.  But I won't
say a word more about that, because this is off-topic here.

bug#12621: Emacs 24.1 crashing on Windows 7

[Drew Adams]

> > I don't think a piece of proprietary software, with known 
> > spyware, DRM and back doors, deserves respect.
> 
> Well, actually, it does, for several technical achievements that I can
> only dream of when I work on modern GNU/Linux systems.  But I won't
> say a word more about that, because this is off-topic here.

Off-topic technically, perhaps, but not off-topic wrt the OP's feelings and
intention indicated in the bug report.

Aside from the question of whether MS deserves respect or whether MS Windows
deserves some respect as software, there is the neglected point that the OP made
in characterizing the anti-"win" campaign as "puerile".

I think that raises a reasonable question, and one that perhaps is not
completely independent of asking how effective such a campaign is or can be.

I would agree with the OP that it smacks of childishness, even if that is not
the intent.  It also seems a bit old-hat/been-there-done-that at this point.

It reminds me of those who still like to call users "lusers" or "losers".  Kind
of an infantile joke, and an old one.  A joke you might have laughed at the
first time you heard it back in 1968, but one you no longer find very funny.
Quite the opposite - users deserve respect, even, or especially, when they are
ignorant.

Of course, poking fun at things that are evil or regressive can sometimes be
effective and progressive, even sometimes when the poking fun is infantile.

But it's a good question for GNU to (re)consider perhaps at this point: what's
the point/effect of the anti-"win" campaign now?

bug#12621: Emacs 24.1 crashing on Windows 7

[Daniel Colascione]

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

On 12/15/12 11:46 AM, Richard Stallman wrote:
>     Well, "Win7" is not a correct description, it's a shorthand.
> 
> We ask people to call the combined system GNU/Linux to show respect
> for our work.  But nobody is forced to show us (or anyone else)
> respect.  People who despise us are free to call the system by some
> nasty name, and even to deny us credit by calling it "Linux".
> 
> I don't think a piece of proprietary software, with known spyware, DRM
> and back doors, deserves respect.  Nonetheless, I usually call it
> "Windows".

There's expressing an opinion about an OS, and then there's slander.
Yes, Windows has DRM, but so does practically everyone else. Windows
contains no "spyware" or "back doors". There are many valid reasons
to dislike Windows, but all you did was sling FUD.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

bug#12621: Emacs 24.1 crashing on Windows 7

[Richard Stallman]

    > I don't think a piece of proprietary software, with known spyware, DRM
    > and back doors, deserves respect.

    Well, actually, it does, for several technical achievements that I can
    only dream of when I work on modern GNU/Linux systems.

I think the ethical nature of a program is more important than its
technical advances; thus, while I might agree with your opinion of
those technical achievements (and I'd be interested if you told me
about them, off the list), I wouldn't grant respect to Windows or
Microsoft on account of them.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#12621: Emacs 24.1 crashing on Windows 7

[Richard Stallman]

You've made a false accusation when you call my criticisms of Windows
"FUD".  The references for these criticisms are in
http://www.gnu.org/philosophy/digital-inclusion-in-freedom.html.

You can't have had any evidence for your false accusation.  You must
have leaped to the conclusion.  This bespeaks hostility towards me.

You also try to excuse the DRM in Windows on the grounds that DRM is
so common.  That is bogus -- DRM is never excusable.  DRM is an
injustice to the user as well as an attack on free software.
This bespeaks opposition to our goals.

This is the second time you have attacked me on this list.  Your
technical contributions are useful, but they don't excuse your
hostility.  If you want to attack me, do it on gnu-misc-discuss or
some non-GNU forum -- not here, on a GNU Project working list.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#12621: Emacs 24.1 crashing on Windows 7

[Stefan Monnier]

>> Thanks for reporting the bug, but please don't refer to Windows as a
>> "win".
> This kind if puerile comment is decidedly unhelpful.

It's very far from puerile, it is on the contrary based on an
understanding of the power of choosing your words.


        Stefan

bug#12621: Emacs 24.1 crashing on Windows 7

[Drew Adams]

> >> Thanks for reporting the bug,

Should have stopped there, full stop.  Thank you, Andy.

> >> but please don't refer to Windows as a "win".
>
> > This kind if puerile comment is decidedly unhelpful.
> 
> It's very far from puerile, it is on the contrary based on an
> understanding of the power of choosing your words.

Power of choosing your words, indeed.  Please do not assume that you understand
this better than Andy or anyone else, just because you religiously ban "win32"
from your vocabulary.

Mouthing "win32" is hardly "referring to [MS] Windows as a win."  If Andy had in
fact referred to MS Windows as "a win" then you might have an argument.  He did
not, and you do not.

This "win32" thing is now nothing more than counting angels on pinheads.  It
makes as much sense as claiming that using the character `w' in an abbreviation
is tantamount to pledging allegiance to Bill Gates.  Or the devil.  Burn the
witch!  Burn the `w' books!

Words chosen well have power.  Chosen unwisely they can backfire.  Choose
wisely.

That, I think, was precisely Andy's point.  It's mine, at least.  The anti-"win"
crusade is not effective, almost by design.  And you should not, by now at
least, be surprised at that.

Choose wisely, especially if you are offering guidelines for political action
and not just a catechism.

Just one opinion.

bug#12621: Emacs 24.1 crashing on Windows 7

[Drew Adams]

> > >> Thanks for reporting the bug,
> 
> Should have stopped there, full stop.  Thank you, Andy.

(Sorry, I meant Arvind, who reported the bug.)

bug#12621: Emacs 24.1 crashing on Windows 7

[Juanma Barranquero]

On Sun, Dec 16, 2012 at 11:26 PM, Drew Adams <drew.adams@oracle.com> wrote:

> Mouthing "win32" is hardly "referring to [MS] Windows as a win."  [...]
>
> This "win32" thing is now nothing more than counting angels on pinheads.  It
> makes as much sense as claiming that using the character `w' in an abbreviation
> is tantamount to pledging allegiance to Bill Gates.  Or the devil.  Burn the
> witch!  Burn the `w' books!

Couldn't agree more.

    Juanma

bug#12621: Emacs 24.1 crashing on Windows 7

[Stephen Berman]

On Sun, 16 Dec 2012 14:26:11 -0800 "Drew Adams" <drew.adams@oracle.com> wrote:

> Mouthing "win32" is hardly "referring to [MS] Windows as a win."
[...]
> This "win32" thing is now nothing more than counting angels on pinheads.  It
> makes as much sense as claiming that using the character `w' in an abbreviation
> is tantamount to pledging allegiance to Bill Gates.  Or the devil.  Burn the
> witch!  Burn the `w' books!

I think it's not entirely implausible to regard "win32" as implicitly
conveying the positive connotations of "win".  On the one hand, it's not
the shortest abbrevation of (some variant of) "the 32 bit Microsoft
Windows platform"; that would be "w32", which is fairly common, but
AFAIK used at microsoft.com only with reference to externally named
viruses and worms.  The next shortest abbrevation "wi32" is quite rare,
as is the next longer one "wind32" (judging by cursory websearches);
both of these lack clearly positive English connotations in the context
of software, and "wind32" might even be regarded as negative.  On the
other hand, suppose the Windows 32 API had been largely due to a person
named Shitsuhara (which is the transliteration of a real Japanese
surname) and in honor of this had been dubbed by Microsoft the
"Shitsuhara Windows 32 API".  Do you think anyone who did not want to
show disrespect for Microsoft would use the abbrevation "shit32"?

Steve Berman

bug#12621: Emacs 24.1 crashing on Windows 7

[Bastien]

People can't agree on chosing words by their connotations,
because connotations are, by definition, what people cannot
agree on.  So let's stop looking at the finger and start
looking at the moon?

When someone suggests me what words I have to chose when 
I speak, I re-read 1984.  

Raising awareness on how marketing may affect our language
is good, but we can do so without enforcing the use of other 
marketing words -- at least if we believe language is a means
to an end, not an end in itself.

2 cts,

-- 
 Bastien

bug#12621: Emacs 24.1 crashing on Windows 7

[Juanma Barranquero]

On Mon, Dec 17, 2012 at 1:04 AM, Stephen Berman <stephen.berman@gmx.net> wrote:

> I think it's not entirely implausible to regard "win32" as implicitly
> conveying the positive connotations of "win".

It is not entirely implausible. But, it is real?

I mean, someone reads a reference to Win32 or Win7 or WinXP in our
docs, do they take it as "a form or praise", or just goes
unregistered, the same way that "newspaper" is not usually reanalized
by native speakers as news+paper? (I'm not saying they are not aware
of news+paper, I'm suggesting that newspaper is lexicalized as a
single word/concept and its constituent parts are not usually
consciously anaylized on their own.)  I'd bet that most native
speakers, at least these who have ever heard of Windows and happen to
read our docs or our list will take win32 and win7 and winxp just as
lexicalized tags for Windows-related stuff and do not waste a second
on its supposed "form of praise" meaning.

As an aside: I often wonder how frequent is to use "X is a win" to
praise something. I'm sure some (perhaps most?) native speakers will
say that it is fairly common, and that it's a widely understood idiom,
and I don't doubt it. But from my entirely subjective POV, I don't
really encounter it that frequently; most uses of win I've read are of
the form "it's a win-win", or "it's a win for X", which seem to fill
an entirely different semantic function.


On Sun, Dec 16, 2012 at 11:05 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> It's very far from puerile, it is on the contrary based on an
> understanding of the power of choosing your words.

The power of choosing your words is a two-edged sword.

Also, please tell me that the repeated use of MS-DOG in the docs isn't puerile.

  J

Re: bug#12621: Emacs 24.1 crashing on Windows 7

[Burton Samograd]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Mon, Dec 17, 2012 at 1:04 AM, Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> I think it's not entirely implausible to regard "win32" as implicitly
>> conveying the positive connotations of "win".
>
> It is not entirely implausible. But, it is real?

There was the package of rewritten unix utilities for Windows call UWIN
put out by AT&T/Bell Labs years ago, so I think that 'win' might be
taken literally in certain connotations, regretfully, along with the
true meaning as a shortening of Windows :)

--
Burton Samograd

bug#12621: Emacs 24.1 crashing on Windows 7

[Drew Adams]

> People can't agree on chosing words by their connotations,
> because connotations are, by definition, what people cannot
> agree on.  So let's stop looking at the finger and start
> looking at the moon?

Very well put.

Regards,

  Drew

bug#12621: Emacs 24.1 crashing on Windows 7

[Drew Adams]

> Very well put.

Apologies.  I meant to send that reply only to Bastien.

bug#12621: Emacs 24.1 crashing on Windows 7

[Dmitry Gutov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Thanks for reporting the bug, but please don't refer to Windows as a
>>> "win".
>> This kind if puerile comment is decidedly unhelpful.
>
> It's very far from puerile, it is on the contrary based on an
> understanding of the power of choosing your words.

When you're also choosing words for other people to use, you better hope
to have reasons that others won't find childish.

For the record, I've never construed "win32" to have the meaning of
"win" before I've seen this odd crusade. I'm a non-native speaker,
though.

--Dmitry

bug#12621: Emacs 24.1 crashing on Windows 7

[Dmitry Gutov]

Hello Mr. Stallman,

Richard Stallman <rms@gnu.org> writes:
> You've made a false accusation when you call my criticisms of Windows
> "FUD".  The references for these criticisms are in
> http://www.gnu.org/philosophy/digital-inclusion-in-freedom.html.
>
> You can't have had any evidence for your false accusation.  You must
> have leaped to the conclusion.  This bespeaks hostility towards me.

I think the burden of proof is on you here. You said that Windows
contains spyware, DRM and backdoors, and only presented an article that
discusses the DRM.

Even if you consider DRM a form of spyware (which is debatable), you
original phrasing implies that Windows contains some other kinds of
spyware and backdoors, too.

> You also try to excuse the DRM in Windows on the grounds that DRM is
> so common.  That is bogus -- DRM is never excusable.  DRM is an
> injustice to the user as well as an attack on free software.
> This bespeaks opposition to our goals.
>
> This is the second time you have attacked me on this list.  Your
> technical contributions are useful, but they don't excuse your
> hostility.  If you want to attack me, do it on gnu-misc-discuss or
> some non-GNU forum -- not here, on a GNU Project working list.

--Dmitry

bug#12621: Emacs 24.1 crashing on Windows 7

[Daniel Colascione]

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

On 12/16/2012 4:04 PM, Stephen Berman wrote:
> On Sun, 16 Dec 2012 14:26:11 -0800 "Drew Adams" <drew.adams@oracle.com> wrote:
> 
>> Mouthing "win32" is hardly "referring to [MS] Windows as a win."
> [...]
>> This "win32" thing is now nothing more than counting angels on pinheads.  It
>> makes as much sense as claiming that using the character `w' in an abbreviation
>> is tantamount to pledging allegiance to Bill Gates.  Or the devil.  Burn the
>> witch!  Burn the `w' books!
> 
> I think it's not entirely implausible to regard "win32" as implicitly
> conveying the positive connotations of "win".  On the one hand, it's not
> the shortest abbrevation of (some variant of) "the 32 bit Microsoft
> Windows platform"; that would be "w32", which is fairly common, but
> AFAIK used at microsoft.com only with reference to externally named
> viruses and worms.  The next shortest abbrevation "wi32" is quite rare,
> as is the next longer one "wind32" (judging by cursory websearches);

We can explain the dominance of "win32" phonetically, without reference to
semantics. First, say "w32" out loud. Note that it's pronounced "dub-a-you
thirty-two". Can we agree that it's a cumbersome word? Now try "wi32" and
"wind32" --- you'll notice that both involve moving the tongue from the palette
to the teeth in order to begin the "thir" in "thirty". They're easier to
pronounce than "w32", but still pretty unpleasant.

Now try "win32". The word is a joy to speak: at the end of the "n", the tongue
is in exactly the right position to begin pronouncing "thir". "Win32" just flows
naturally. I'm not surprised that "win32" is the dominant term. "Win64" is just
as easily to say.

(Also, note that you have to specifically enunciate to distinguish "wind32" from
"win32": the latter seems to happen by default.)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

bug#12621: Emacs 24.1 crashing on Windows 7

[Daniel Colascione]

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

On 12/16/2012 6:03 PM, Dmitry Gutov wrote:
> Hello Mr. Stallman,
> 
> Richard Stallman <rms@gnu.org> writes:
>> You've made a false accusation when you call my criticisms of Windows
>> "FUD".  The references for these criticisms are in
>> http://www.gnu.org/philosophy/digital-inclusion-in-freedom.html.
>>
>> You can't have had any evidence for your false accusation.  You must
>> have leaped to the conclusion.  This bespeaks hostility towards me.
> 
> I think the burden of proof is on you here. You said that Windows
> contains spyware, DRM and backdoors, and only presented an article that
> discusses the DRM.

To be fair, the "backdoor" to which RMS refers involves an incident in which
Windows Update updated itself even when users had specifically turned off
updates from the OS configuration facility for such things. I don't mean to
speak for RMS, but I believe he's suggesting that Windows still has these latent
capabilities. Nobody can prove otherwise.

The "spyware" claim refers to Windows Update sending a list of installed
programs along with its "do you have an update for me?" chat with the update server.

That said, Chrome also transmits usage statistics and (in its default
configuration) updates itself silently. rms, I don't see how you can claim
Windows contains "backdoors" and "spyware" without similarly accusing Chrome.
Many other programs do the same thing.

I prefer to live in a world where the vast majority of programs I use are not
morally reprehensible.

[1] http://support.google.com/chrome/bin/answer.py?hl=en&answer=96817
[2]
http://www.esecurityplanet.com/browser-security/google-silently-updates-chrome-as-mozilla-preps-.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

bug#12621: Emacs 24.1 crashing on Windows 7

[Dmitry Gutov]

On 17.12.2012 6:19, Daniel Colascione wrote:
> On 12/16/2012 6:03 PM, Dmitry Gutov wrote:
>> Hello Mr. Stallman,
>>
>> Richard Stallman <rms@gnu.org> writes:
>>> You've made a false accusation when you call my criticisms of Windows
>>> "FUD".  The references for these criticisms are in
>>> http://www.gnu.org/philosophy/digital-inclusion-in-freedom.html.
>>>
>>> You can't have had any evidence for your false accusation.  You must
>>> have leaped to the conclusion.  This bespeaks hostility towards me.
>>
>> I think the burden of proof is on you here. You said that Windows
>> contains spyware, DRM and backdoors, and only presented an article that
>> discusses the DRM.
>
> To be fair, the "backdoor" to which RMS refers involves an incident in which
> Windows Update updated itself even when users had specifically turned off
> updates from the OS configuration facility for such things. I don't mean to
> speak for RMS, but I believe he's suggesting that Windows still has these latent
> capabilities. Nobody can prove otherwise.
>
> The "spyware" claim refers to Windows Update sending a list of installed
> programs along with its "do you have an update for me?" chat with the update server.

I see, thanks for the explanation.

> That said, Chrome also transmits usage statistics and (in its default
> configuration) updates itself silently. rms, I don't see how you can claim
> Windows contains "backdoors" and "spyware" without similarly accusing Chrome.
> Many other programs do the same thing.
>
> I prefer to live in a world where the vast majority of programs I use are not
> morally reprehensible.
>
> [1] http://support.google.com/chrome/bin/answer.py?hl=en&answer=96817
> [2]
> http://www.esecurityplanet.com/browser-security/google-silently-updates-chrome-as-mozilla-preps-.html
>

--Dmitry

bug#12621: Emacs 24.1 crashing on Windows 7

[Richard Stallman]

      Do you think anyone who did not want to
    show disrespect for Microsoft would use the abbrevation "shit32"?

Don't forget the Stevens Hoboken Institute of Technology,
which people somehow don't reduce to an acronym.
And there was the String Handling Interpretive Translator,
which was generally referred to as "String".

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#12621: Emacs 24.1 crashing on Windows 7

[Richard Stallman]

A connotation is a meaning commonly associated with a
word, other than its surface meaning (the "denotation").
This is different from a personal association,
which exists in the mind of one person but perhaps
no one else.

Some people may be unaware of a connotation, but (to qualify for that
term) it must be well enough known so as to be objectively part of the
language as it is used.

Hackers at MIT used to use "win" frequently to express praise.
It may not be used so much nowadays, but it is used sometimes.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#12621: Emacs 24.1 crashing on Windows 7

[Richard Stallman]

    That said, Chrome also transmits usage statistics and (in its default
    configuration) updates itself silently. rms, I don't see how you can claim
    Windows contains "backdoors" and "spyware" without similarly accusing Chrome.

I do talk about this malicious functionality of Chrome sometimes in my
speeches.  I did not bring it up here because the topic was Windows.

    I prefer to live in a world where the vast majority of programs I use are not
    morally reprehensible.

Me too, and that's part of what we are fighting for.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#12621: Emacs 24.1 crashing on Windows 7

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> A connotation is a meaning commonly associated with a
> word, other than its surface meaning (the "denotation").
> This is different from a personal association,
> which exists in the mind of one person but perhaps
> no one else.

I don't think this is that simple.

If you want to learn about linguistics (and the specific problem of
connotation/denotation), I suggest this good read: "Languages of Art",
by Nelson Goodman.

Fighting for a cause requires some "pragmatic dogmatism", but if it is
not balanced by intellectual openness, then intellectual dogmatism can
impair the whole cause.

I doubt it is worth trying to ground the choice of "w32" over "win32"
on some flawed linguistic theory; "pragmatic dogmatism" can do its job
well enough here.

-- 
 Bastien

bug#12621: Emacs 24.1 crashing on Windows 7

[Richard Stallman]

    I doubt it is worth trying to ground the choice of "w32" over "win32"
    on some flawed linguistic theory;

This is not a theory, it is a personal observation.

If you don't see the point in avoiding the term "win",
please just leave it to me.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

bug#12621: Emacs 24.1 crashing on Windows 7

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> This is not a theory, it is a personal observation.

The way you expressed it suggested otherwise.

> If you don't see the point in avoiding the term "win",
> please just leave it to me.

I see this point.

My point was: there is no point in justifying those kinds of
decisions with observations on what is a "connotation", what
is a "meaning", etc. because such observations just call for
more arguments.  I hope you get this point :)

-- 
 Bastien

bug#12621: Emacs 24.1 crashing on Win7

[Glenn Morris]

Eli Zaretskii wrote:

> OK, I made that change on the emacs-24 branch (revision 111035).
> There should be a new pretest of Emacs 24.3 out of that branch soon,
> and a precompiled Windows binary will follow.  Watch the announcements
> on emacs-devel.
>
> This change will be merged to the trunk soon, so the few people who
> provide snapshots of the trunk will probably soon upload a binary with
> this change.
>
> When you do get hold of a new binary with the change, please run some
> tests with files on the DFS, and please report any findings.

There have been no further on-topic comments AFAICS after this.
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12621#62)
(Unfortunately the bug was taken over by unrelated discussion.)

Maybe this issue is also fixed, and can be closed?

bug#12621: Emacs 24.1 crashing on Win7

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 12621@debbugs.gnu.org
> Date: Tue, 19 Feb 2013 13:53:56 -0500
> 
> Eli Zaretskii wrote:
> 
> > OK, I made that change on the emacs-24 branch (revision 111035).
> > There should be a new pretest of Emacs 24.3 out of that branch soon,
> > and a precompiled Windows binary will follow.  Watch the announcements
> > on emacs-devel.
> >
> > This change will be merged to the trunk soon, so the few people who
> > provide snapshots of the trunk will probably soon upload a binary with
> > this change.
> >
> > When you do get hold of a new binary with the change, please run some
> > tests with files on the DFS, and please report any findings.
> 
> There have been no further on-topic comments AFAICS after this.
> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12621#62)
> (Unfortunately the bug was taken over by unrelated discussion.)
> 
> Maybe this issue is also fixed, and can be closed?

Closing.