bug#19813: 24.4; emacs crashes on exit

bug#19813: 24.4; emacs crashes on exit

[Test User]

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

--text follows this line--

Note: the problem does not occur if you run `emacs -Q'.

To reproduce the problem:
1) Unzip emacs-24.4-bin-i686-pc-mingw32.zip.
On my system, I unzipped it in
c:/users/testuser448/Downloads/Open_Source/Binaries/emacs

2) Run `emacs'.

3) Select File -> Quit from the menu.
A message box is displayed saying:

GNU Emacs: The extensible self-documenting text editor has stopped
working

A problem caused the program to stop working correctly. Please
close the program.

-> Close the program
-> Debug the program

In gdb, emacs terminates without the dialog box appearing, and reports
that the process exited with code 03.

Other than that, emacs appears to be working properly. My previous
version (24.3) did not have this problem.



In GNU Emacs 24.4.1 (i686-pc-mingw32)
 of 2014-10-24 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.3.9600
(i.e., Windows 8.1, 64-bit)
Configured using:
 `configure --prefix=/c/usr'

Important settings:
  value of $LANG: ENJ
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  nxhtml-menu-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t = <backspace> - e m a c s - b u g
<return>

Recent messages:
Loading c:/mingw/local/lisp/nxhtml/nxhtml-loaddefs...done
Patching xhtml-loader.rnc
Wrote c:/MinGW/local/lisp/nxhtml/etc/schema/xhtml-loader.rnc
Loading c:/mingw/local/lisp/nxhtml/nxhtml/nxhtml-autoload...
nxhtml-autoload starting ... (hm, should maybe be renamed ...)
majmodpri-apply-priorities running ... (done)
Loading c:/mingw/local/lisp/nxhtml/nxhtml/nxhtml-autoload...done
Nxml/Nxhtml Autostart.el loaded in 0.2 seconds
Loading c:/mingw/local/lisp/nxhtml/autostart.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
c:/mingw/local/lisp/nxhtml/tests/ert hides
c:/Users/Testuser448/Downloads/Open_Source/Binaries/emacs/share/emacs/24.4/lisp/emacs-lisp/ert

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils nxhtml-autostart nxhtml-autoload
majmodpri nxhtml-menu web-autoload nxhtml-base time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment lisp-mode prog-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 nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)

Memory information:
((conses 8 84239 4988)
 (symbols 32 18357 0)
 (miscs 32 75 138)
 (strings 16 12769 3674)
 (string-bytes 1 406041)
 (vectors 8 9771)
 (vector-slots 4 386289 3440)
 (floats 8 59 326)
 (intervals 28 257 31)
 (buffers 508 12))

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

bug#19813: 24.4; emacs crashes on exit

[Eli Zaretskii]

> Date: Sun, 8 Feb 2015 00:35:19 -0500
> From: Test User <testuser448@gmail.com>
> 
> Note: the problem does not occur if you run `emacs -Q'.
> 
> To reproduce the problem:
> 1) Unzip emacs-24.4-bin-i686-pc-mingw32.zip.
> On my system, I unzipped it in
> c:/users/testuser448/Downloads/Open_Source/Binaries/emacs
> 
> 2) Run `emacs'.
> 
> 3) Select File -> Quit from the menu.
> A message box is displayed saying:
> 
> GNU Emacs: The extensible self-documenting text editor has stopped
> working

Thank you for your report.

Since the problem does not happen in "emacs -Q", there's some
customization on your ~/.emacs file that triggers it.  Could you
please bisect your .emacs until you find the smallest part of it that
still causes the problem, and then post here that part?  We need a
reproducible recipe to investigate the reasons for the abort.

bug#19813: 24.4; emacs crashes on exit

[Test User]

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

On Sun, Feb 8, 2015 at 11:06 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>
> Since the problem does not happen in "emacs -Q", there's some
> customization on your ~/.emacs file that triggers it.  Could you
> please bisect your .emacs until you find the smallest part of it that
> still causes the problem, and then post here that part?  We need a
> reproducible recipe to investigate the reasons for the abort.
>

I have just two lines in my .emacs file. I commented them both out but it
made no difference. I even renamed .emacs and .emacs.d but it still did
not help.

Regards,
Test User.

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

bug#19813: 24.4; emacs crashes on exit

[Eli Zaretskii]

> Date: Sun, 8 Feb 2015 11:59:06 -0500
> From: Test User <testuser448@gmail.com>
> 
>     Since the problem does not happen in "emacs -Q", there's some
>     customization on your ~/.emacs file that triggers it. Could you
>     please bisect your .emacs until you find the smallest part of it that
>     still causes the problem, and then post here that part? We need a
>     reproducible recipe to investigate the reasons for the abort.
>     
> 
> I have just two lines in my .emacs file. I commented them both out but it
> made no difference. I even renamed .emacs and .emacs.d but it still did
> not help.

What happens if you remove the file entirely, or rename it?

Where on your filesystem do you keep your .emacs, i.e. what is its
full Windows file name?

bug#19813: 24.4; emacs crashes on exit

[Test User]

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

On Sun, Feb 8, 2015 at 1:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 8 Feb 2015 11:59:06 -0500
> > From: Test User <testuser448@gmail.com>
> >
> >     Since the problem does not happen in "emacs -Q", there's some
> >     customization on your ~/.emacs file that triggers it. Could you
> >     please bisect your .emacs until you find the smallest part of it that
> >     still causes the problem, and then post here that part? We need a
> >     reproducible recipe to investigate the reasons for the abort.
> >
> >
> > I have just two lines in my .emacs file. I commented them both out but it
> > made no difference. I even renamed .emacs and .emacs.d but it still did
> > not help.
>
> What happens if you remove the file entirely, or rename it?
>

I said above that I renamed .emacs and also .emacs.d. but it did not help.


>
> Where on your filesystem do you keep your .emacs, i.e. what is its
> full Windows file name?
>

C:/Users/testuser448/.emacs. I set HOME=C:/Users/testuser448 and I have
confirmed using Process Monitor from SysInternals that emacs finds it there
when HOME is set, and did not find it when I renamed it. Alternative
locations
appear to be C:/ and %APPDATA%, where .emacs does not exist.

Alternatively if you give a command that will display a message I can
put it in .emacs.

If I set HOME=<blank>, it does not make a difference.

For what it is worth, the problem does not occur on my Windows XP
virtual machine, which never had emacs on it before. I am on Windows 8.1.

In my initial message, I said that if I run emacs.exe within gdb, gdb says
that
emacs exited with code 03. Do you know what that means?

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

bug#19813: 24.4; emacs crashes on exit

[Eli Zaretskii]

> Date: Sun, 8 Feb 2015 15:15:03 -0500
> From: Test User <testuser448@gmail.com>
> 
> C:/Users/testuser448/.emacs. I set HOME=C:/Users/testuser448 and I have
> confirmed using Process Monitor from SysInternals that emacs finds it there
> when HOME is set, and did not find it when I renamed it. Alternative locations
> appear to be C:/ and %APPDATA%, where .emacs does not exist.
> 
> Alternatively if you give a command that will display a message I can
> put it in .emacs.
> 
> If I set HOME=<blank>, it does not make a difference.
> 
> For what it is worth, the problem does not occur on my Windows XP
> virtual machine, which never had emacs on it before. I am on Windows 8.1.

I tried this on XP, on Windows 7, and on Windows 8.1, with the same
binary you are using, and I cannot reproduce this.  There's something
specific to your machine that triggers this.  The .emacs file is
probably not the reason, it's something that Emacs does at startup
that is disabled by -Q.

What about "emacs -q" -- does that reproduce the problem?

> In my initial message, I said that if I run emacs.exe within gdb, gdb says that
> emacs exited with code 03. Do you know what that means? 

That means Emacs called 'abort'.  But it doesn't add any useful
information, since the "program stopped working" dialog tells the
same.

What does the Windows Event Viewer say about these crashes (under
"Application")?

bug#19813: 24.4; emacs crashes on exit

[Test User]

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

On Sun, Feb 8, 2015 at 3:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>
> What about "emacs -q" -- does that reproduce the problem?
>
>
Yes, it crashes with `emacs -q'.


>
> What does the Windows Event Viewer say about these crashes (under
> "Application")?
>

Faulting application name: emacs.exe, version: 24.4.0.0, time stamp:
0x544a8d9a
Faulting module name: libgcc_s_dw2-1.dll, version: 0.0.0.0, time stamp:
0x507d56df
Exception code: 0x40000015
Fault offset: 0x00016f62
Faulting process id: 0xee4
Faulting application start time: 0x01d043e155516507
Faulting application path: C:\MinGW\local\bin\emacs.exe
Faulting module path: C:\MinGW\bin\libgcc_s_dw2-1.dll
Report Id: 9ab40c92-afd4-11e4-81d7-00a0d1ad0b0b
Faulting package full name:
Faulting package-relative application ID:

On my Windows 8 system:
16/10/2012  07:45           119,296 libgcc_s_dw2-1.dll

The dll does not contain any version information, but gcc --version
prints 4.7.2.

On my Windows XP system where it works:
05/10/2013  12:17 PM           112,142 libgcc_s_dw2-1.dll
gcc 4.8.1 is installed.

On my Windows 8 system, I renamed the DLL. Unexpectedly emacs
launched, and it exited normally. According to Process Monitor, emacs
failed to find this DLL anywhere else. I doubt that I have another copy
but I am searching the C: drive now.

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

bug#19813: 24.4; emacs crashes on exit

[Test User]

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

On Sun, Feb 8, 2015 at 4:25 PM, Test User <testuser448@gmail.com> wrote:


> On my Windows 8 system, I renamed the DLL. Unexpectedly emacs
> launched, and it exited normally. According to Process Monitor, emacs
> failed to find this DLL anywhere else. I doubt that I have another copy
> but I am searching the C: drive now.
>
>
I have *one* copy (not in my path) in a directory in which I had assembled
all the files required by a small program that I wrote, including this DLL
and
libstdc++. On XP, even though the DLL is in the PATH, it is not loaded when
emacs runs, according to Process Monitor.

The XP system contains only the files in emacs-24.4*.zip. I have added files
(usually extra modes) to my main emacs installation over the years, although
I would not be able to say what I have added. If there is another startup
file that is read besides .emacs, that may be answer.

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

bug#19813: 24.4; emacs crashes on exit

[Eli Zaretskii]

> Date: Sun, 8 Feb 2015 16:25:15 -0500
> From: Test User <testuser448@gmail.com>
> 
>     What does the Windows Event Viewer say about these crashes (under
>     "Application")?
>     
> 
> Faulting application name: emacs.exe, version: 24.4.0.0, time stamp: 0x544a8d9a
> Faulting module name: libgcc_s_dw2-1.dll, version: 0.0.0.0, time stamp:
> 0x507d56df
> Exception code: 0x40000015
> Fault offset: 0x00016f62
> Faulting process id: 0xee4
> Faulting application start time: 0x01d043e155516507
> Faulting application path: C:\MinGW\local\bin\emacs.exe
> Faulting module path: C:\MinGW\bin\libgcc_s_dw2-1.dll
> Report Id: 9ab40c92-afd4-11e4-81d7-00a0d1ad0b0b
> Faulting package full name: 
> Faulting package-relative application ID: 
> 
> On my Windows 8 system:
> 16/10/2012 07:45 119,296 libgcc_s_dw2-1.dll
> 
> The dll does not contain any version information, but gcc --version
> prints 4.7.2.

Then this is a known issue, see etc/PROBLEMS, and also bug 19181.  In
a nutshell, you have a DLL that Emacs loads that depends on
libgcc_s_dw2-1.dll.  Find that dependent DLL and install another
binary of that DLL which doesn't have this dependency.

bug#19813: 24.4; emacs crashes on exit

[Eli Zaretskii]

> Date: Sun, 8 Feb 2015 18:03:04 -0500
> From: Test User <testuser448@gmail.com>
> 
> I have *one* copy (not in my path) in a directory in which I had assembled
> all the files required by a small program that I wrote, including this DLL and
> libstdc++. On XP, even though the DLL is in the PATH, it is not loaded when
> emacs runs, according to Process Monitor.

The problem is not with libgcc_s_dw2-1.dll, the problem is with some
other DLL that loads it, typically zlib1.dll or some image library.

bug#19813: 24.4; emacs crashes on exit

[Test User]

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

On Sun, Feb 8, 2015 at 10:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 8 Feb 2015 18:03:04 -0500
> > From: Test User <testuser448@gmail.com>
> >
> > I have *one* copy (not in my path) in a directory in which I had
> assembled
> > all the files required by a small program that I wrote, including this
> DLL and
> > libstdc++. On XP, even though the DLL is in the PATH, it is not loaded
> when
> > emacs runs, according to Process Monitor.
>
> The problem is not with libgcc_s_dw2-1.dll, the problem is with some
> other DLL that loads it, typically zlib1.dll or some image library.
>

I built emacs with -shared-libgcc in LDFLAGS and the problem went away.
I have some questions about building emacs, but they will be in a post
to the user list.

Thanks. You can close the bug if you have not already done so.

On my main system (where the problem occurs), there is no zlib1.dll in
/mingw/bin. I built it myself, and it does *not* have a dependency on
libgcc_s_dw2-1.dll. On my virtual machine (where I did not have the
problem),
there is a zlib1.dll supplied by MinGW, and it *does* depend on
libgcc_s_dw2-1.dll.

The only DLL loaded when emacs runs that depends on libgcc_s_dw2-1.dll
is libharfbuzz-0.dll, which is not loaded with `emacs -Q'. For your
information,
other DLLs usually loaded but not with the -Q flag include (and are possibly
not limited to):

libcairo-2.dll
libcroco*.dll
libfontconfig-1.dll
libfreetype-6.dll
libffi*.dll
libpango*.dll
libgdk_pixbuf*.dll
libglib-2*.dll
libgio-2*.dll
libgmodule-2*.dll
libgobject-2*.dll
libiconv*.dll
libintl-8.dll
liblzma-5.dll
libpcre-1.dll
libpcreposix-0.dll
libpng*.dll
librsvg*.dll
libpixman*.dll
and maybe a few others.

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

bug#19813: 24.4; emacs crashes on exit

[Eli Zaretskii]

> Date: Mon, 9 Feb 2015 04:03:24 -0500
> From: Test User <testuser448@gmail.com>
> 
>     The problem is not with libgcc_s_dw2-1.dll, the problem is with some
>     other DLL that loads it, typically zlib1.dll or some image library.
> 
> I built emacs with -shared-libgcc in LDFLAGS and the problem went away.

That is one solution, but it is not the best one, IMO.  E.g., you
cannot move this binary to another machine without also copying
libgcc_s_dw2-1.dll with it.

The best solution is to replace the DLL(s) you have that depend on
libgcc_s_dw2-1.dll with DLLs that offer the same functionality, but do
not depend on libgcc_s_dw2-1.dll.  See below for a specific
recommendation.

> Thanks. You can close the bug if you have not already done so.

Done.

> On my main system (where the problem occurs), there is no zlib1.dll in
> /mingw/bin. I built it myself, and it does *not* have a dependency on libgcc_s_dw2-1.dll. On my virtual machine (where I did not have the problem),
> there is a zlib1.dll supplied by MinGW, and it *does* depend on
> libgcc_s_dw2-1.dll.
> 
> The only DLL loaded when emacs runs that depends on libgcc_s_dw2-1.dll
> is libharfbuzz-0.dll, which is not loaded with `emacs -Q'.

That figures: "emacs -Q" refrains from showing the splash-screen
image, which causes Emacs to load a suitable image library.  In your
case, that library is librsvg for showing the SVG variant of the
splash screen.  And the librsvg DLLs you have include
libharfbuzz-0.dll, which depends on libgcc_s_dw2-1.dll, and triggers
the problem.

In general, no MinGW DLLs distributed as binaries should depend on
libgcc_s_dw2-1.dll, for several reasons:

  . Each end-user machine that has GCC installed will have this DLL on
    PATH, which creates a small "DLL hell" when you install other
    versions of that DLL, possibly from other GCC versions

  . Loading libgcc_s_dw2-1.dll by some other DLL (as opposed to by the
    main program itself) triggers these crashes (due to a known bug in
    the machinery that supports C++ exceptions between DLLs)

  . For the person who uploads the precompiled binaries of the DLLs,
    the dependency on libgcc_s_dw2-1.dll is a terrible PITA, because
    GPL requires to provide its sources, i.e. the entire 80-MB source
    tarball of the full GCC package

You can find DLLs that are never dependent on libgcc_s_dw2-1.dll here:

  http://sourceforge.net/projects/ezwinports/files/?source=navbar

That collection includes librsvg, zlib, and all the other libraries
required by Emacs.  (Btw, the librsvg build there is much smaller than
the one you use, because it excludes every feature not useful on
Windows, like Fontconfig, Freetype, and Harfbuzz.)

bug#19813: 24.4; emacs crashes on exit

[Test User]

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

On Mon, Feb 9, 2015 at 10:41 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 9 Feb 2015 04:03:24 -0500
> > From: Test User <testuser448@gmail.com>
> >
> >     The problem is not with libgcc_s_dw2-1.dll, the problem is with some
> >     other DLL that loads it, typically zlib1.dll or some image library.
> >
> > I built emacs with -shared-libgcc in LDFLAGS and the problem went away.
>
> That is one solution, but it is not the best one, IMO.  E.g., you
> cannot move this binary to another machine without also copying
> libgcc_s_dw2-1.dll with it.


True. I mentioned in an earlier message that I had another copy of shared
libgcc
because I needed to take a program that I had written to another PC. I don't
see myself trying to take emacs with me, but your point is taken.


> The best solution is to replace the DLL(s) you have that depend on
> libgcc_s_dw2-1.dll with DLLs that offer the same functionality, but do
> not depend on libgcc_s_dw2-1.dll.  See below for a specific
> recommendation.
>


<snip>


>
> In general, no MinGW DLLs distributed as binaries should depend on
> libgcc_s_dw2-1.dll, for several reasons:
>

<good reasons snipped>

Does this simply mean that I should always build my libraries and programs
with -static-libgcc? Would that be in conflict with the issues discussed in
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Link-Options.html#Link-Options?
(See -shared-libgcc). Or maybe I need to read the code to know when I should
build with -static-libgcc and when I should accept the default?


>
> You can find DLLs that are never dependent on libgcc_s_dw2-1.dll here:
>
>   http://sourceforge.net/projects/ezwinports/files/?source=navbar
>
> That collection includes librsvg, zlib, and all the other libraries
> required by Emacs.  (Btw, the librsvg build there is much smaller than
> the one you use, because it excludes every feature not useful on
> Windows, like Fontconfig, Freetype, and Harfbuzz.)
>

It is impossible for me to know when a feature is "useful on Windows"
or not, so whenever I build software that was not born on Windows, I always
try to make it use as many of its optional dependencies as possible.
Now that I know, in this case maybe I can --disable-harfbuzz ,etc., or
build Harfbuzz with -static-libgcc.

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

bug#19813: 24.4; emacs crashes on exit

[Eli Zaretskii]

> Date: Mon, 9 Feb 2015 11:29:04 -0500
> From: Test User <testuser448@gmail.com>
> Cc: 19813-done@debbugs.gnu.org
> 
>     In general, no MinGW DLLs distributed as binaries should depend on
>     libgcc_s_dw2-1.dll, for several reasons:
>     
> 
> <good reasons snipped>
> 
> Does this simply mean that I should always build my libraries and programs
> with -static-libgcc?

Yes, sort of.  Not every library needs that, so what I do is build it
"as usual" first, then, if I discover it depends on
libgcc_s_dw2-1.dll, I reconfigure and rebuild so that the link command
includes -static-libgcc.

> Would that be in conflict with the issues discussed in 
> https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Link-Options.html#Link-Options?
> (See -shared-libgcc).

This is only an issue with C++ programs that throw and catch
exceptions across shared libraries.  If you only use these libraries
with C programs, you will never have any problems.  And even with C++
programs, since these libraries never throw any exceptions, I think
you are safe.

>     http://sourceforge.net/projects/ezwinports/files/?source=navbar
>     
>     That collection includes librsvg, zlib, and all the other libraries
>     required by Emacs. (Btw, the librsvg build there is much smaller than
>     the one you use, because it excludes every feature not useful on
>     Windows, like Fontconfig, Freetype, and Harfbuzz.)
> 
> It is impossible for me to know when a feature is "useful on Windows"
> or not

Of course, it's possible: the information about that is normally
available in some README or INSTALL file in the package, and in the
description of the 'configure' script options.  How do you think I
knew which features to configure and which not?  The first thing I do
when building a package is run "./configure --help" and read carefully
the description of each option that turns some feature on or off.  In
some cases, that description is not detailed enough, so I need to look
in the package documentation and/or sources to understand what it
does, and in rare cases ask the maintainers.

It's an effort, but it's an effort well spent.  Without it, you won't
even know whether some optional feature is supported on Windows or
not, and might waste a lot of time trying to have it compile and link.

> Now that I know, in this case maybe I can --disable-harfbuzz ,etc., or
> build Harfbuzz with -static-libgcc.

The main bloat comes from cairo.  My notes indicate that I configured
cairo like this:

  ./configure --prefix=... --disable-pthread --disable-fc --disable-ft

and pixman like this:

  ./configure --prefix=... --disable-ssse3

and gdk-pixbuf like this:

  ./configure --prefix=... --without-libjpeg --without-libtiff --with-included-loaders=yes