bug#14333: 24.3.50; Emacs hangs when trying to exit

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

Hello,

At work, I use Emacs in some Windows 2003 server machines, which I
connect to via remote desktop.  Usually, my Emacs sessions in those
machines last for several days.

Well, lately (during the last months or so - I can't be more precise),
I've noticed that, whenever I try to close one of such Emacs session
(C-x C-c), Emacs hangs (after showing the message about saving
bookmarks) and I have to kill the process with the task manager.

Probably this information alone is insufficient for investigating the
problem, but I let you know anyway.  If there is something I could do
to provide more info, let me know.

TIA

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.2.3790)
 of 2013-04-15 on LEG570
Bzr revision: 112297
christopher@ch.ristopher.com-20130415170100-a4yp56eot413dq44
Windowing system distributor `Microsoft Corp.', version 5.2.3790
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/emacs/libs/libXpm-3.5.10/include -IC:/emacs/libs/libXpm-3.5.10/src
 -IC:/emacs/libs/libpng-dev_1.4.3-1_win32/include
 -IC:/emacs/libs/zlib-dev_1.2.5-2_win32/include
 -IC:/emacs/libs/giflib-4.1.4-1-lib/include
 -IC:/emacs/libs/jpeg-6b-4-lib/include
 -IC:/emacs/libs/tiff-3.8.2-1-lib/include
 -IC:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -IC:/emacs/libs/gnutls-3.1.10-w32/include
 -IC:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'

--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Thu, 2 May 2013 09:09:14 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> At work, I use Emacs in some Windows 2003 server machines, which I
> connect to via remote desktop.  Usually, my Emacs sessions in those
> machines last for several days.
> 
> Well, lately (during the last months or so - I can't be more precise),
> I've noticed that, whenever I try to close one of such Emacs session
> (C-x C-c), Emacs hangs (after showing the message about saving
> bookmarks) and I have to kill the process with the task manager.
> 
> Probably this information alone is insufficient for investigating the
> problem, but I let you know anyway.  If there is something I could do
> to provide more info, let me know.

When it hangs, attach GDB to it and provide backtrace from all the
threads ("thread apply all bt").

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

> When it hangs, attach GDB to it and provide backtrace from all the
> threads ("thread apply all bt").

I've tried to do it, but when I do "gdb -p EMACS-PID", gdb doesn't
allow me to input any command:

C:\>gdb -p 1844
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
[...]
Attaching to process 1844
[New Thread 1844.0xd80]
[New Thread 1844.0xc00]
[New Thread 1844.0x4f0]
[New Thread 1844.0xbb4]

I'm trying to exit gdb by typing "C-c", but it just makes another "New
Thread" message appear, but gdb is still running and it doesn't give
me chance for type any command.

What am I doing wrong?

--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 8 May 2013 09:51:38 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> C:\>gdb -p 1844
> GNU gdb (GDB) 7.5
> Copyright (C) 2012 Free Software Foundation, Inc.
> [...]
> Attaching to process 1844
> [New Thread 1844.0xd80]
> [New Thread 1844.0xc00]
> [New Thread 1844.0x4f0]
> [New Thread 1844.0xbb4]
> 
> I'm trying to exit gdb by typing "C-c", but it just makes another "New
> Thread" message appear, but gdb is still running and it doesn't give
> me chance for type any command.
> 
> What am I doing wrong?

I don't think it's you, I think GDB is for some reason unable to
attach to that Emacs process, so it just waits for the attach to
finish.

Does it help to press F12 with focus in the Emacs frame, while GDB
tries to attach?

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

> Does it help to press F12 with focus in the Emacs frame, while GDB
> tries to attach?

I've tried it, and the effect is that, each time I type F12 on the
Emacs frame (which it is not redrawn anymore) another "New Thread"
message appears in the gdb console.

--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> Does it help to press F12 with focus in the Emacs frame, while GDB
>> tries to attach?
>
> I've tried it, and the effect is that, each time I type F12 on the
> Emacs frame (which it is not redrawn anymore) another "New Thread"
> message appears in the gdb console.

So, it seems it is not possible to attach gdb to the hanged Emacs
session.   Is there another way of tracking down the problem?

For example, I could add some sentences at the C level, which write
information to some log file.  If this is a good idea, just send me
the patch I should apply.

TIA

--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Thu, 9 May 2013 11:09:11 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> So, it seems it is not possible to attach gdb to the hanged Emacs
> session.   Is there another way of tracking down the problem?

I hope so.  See below.

> For example, I could add some sentences at the C level, which write
> information to some log file.  If this is a good idea, just send me
> the patch I should apply.

I don't know yet what to write and where.  We need more information
about the problem.

I can think about 2 methods to gain more info:

 1) Attach GDB before you exit Emacs, while Emacs still runs.
    Hopefully, it will attach cleanly.  Then:

     (gdb) break shut_down_emacs
     (gdb) continue

    Now exit Emacs as usual.  GDB will kick in and stop Emacs inside
    shut_down_emacs.  Step through that function (with "next") and see
    which call doesn't return.  Then try the same again in another
    session, but now step into the function that didn't return, and
    step through that, again looking for some sub-function that
    doesn't return.  Etc., etc., until you find which system call
    doesn't return, or maybe some Emacs code that infloops for some
    reason.

 2) Download and install the latest version of Process Explorer from
    SysInternals.

    Start Process Explorer and find the line showing the running Emacs
    (before you exit it).  Right-click on that line, and select
    "Properties".  In the window that pops up, click on the "Threads"
    tab.  You should see several threads that belong to Emacs.

    Now exit Emacs.  Every thread that exits should have its line
    highlighted by a red background.  Normally, they all exit, so they
    all become red.  I suspect that in your case, some of them will
    not exit.  If so, click on the line of that thread, and tell what
    is its State as shown below the thread list.

    Next, click the entry of the thread that didn't exit, and push the
    "Stack" button below the thread list.  This should pop up another
    window with the call stack addresses.  Press "Copy All" and then
    paste into some file.  Repeat this for every thread that did not
    exit.

    Now start GDB on the Emacs binary:

       gdb emacs.exe

    and translate the call stack addresses into source lines like
    this:

      (gdb) list *0xNNNNNNN

    where NNNNNNN is the address you see in the call stack after
    "emacs+", to which you need to add 0x1000000.  For example, if you
    see emacs+0x19f93, type

      (gdb) list *0x1019f93

    This should show a small number of source lines around the line
    that corresponds to the address.  The top-most address of the form
    emacs+0xNNNN that you find in the call stack of each thread that
    didn't exit is the most important one -- it tells where that
    thread is stuck.

    Alternatively, you can use addr2line to convert addresses to
    source line numbers; once again, you will need to add 0x1000000 to
    each address displayed by the Process Explorer.

I hope at least one of these 2 methods will allow us to determine why
Emacs hangs.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

Hi Eli, I chose your method "2" in the previous mail, and here are the results:

In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
 of 2013-05-14 on LEG570
Bzr revision: 112585 rgm@gnu.org-20130514192935-6xmxlfwotrehrz0b
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/emacs/libs/libXpm-3.5.10/include -IC:/emacs/libs/libXpm-3.5.10/src
 -IC:/emacs/libs/libpng-dev_1.4.3-1_win32/include
 -IC:/emacs/libs/zlib-dev_1.2.5-2_win32/include
 -IC:/emacs/libs/giflib-4.1.4-1-lib/include
 -IC:/emacs/libs/jpeg-6b-4-lib/include
 -IC:/emacs/libs/tiff-3.8.2-1-lib/include
 -IC:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -IC:/emacs/libs/gnutls-3.1.10-w32/include
 -IC:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'


* Thread ID: 6712.
* State: Wait:UserRequest
* Stack:
    wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
    wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
    wow64.dll!Wow64SystemServiceEx+0x1ce
    wow64.dll!Wow64LdrpInitialize+0x429
    ntdll.dll!RtlIsDosDeviceName_U+0x24c87
    ntdll.dll!LdrInitializeThunk+0xe
    ntdll.dll!ZwWaitForMultipleObjects+0x15
    kernel32.dll!BaseThreadInitThunk+0x12
    ntdll.dll!RtlInitializeExceptionChain+0x63
    ntdll.dll!RtlInitializeExceptionChain+0x36

* Thread ID: 6376.
* State: Wait:UserRequest
* Stack:
    wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
    wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
    wow64.dll!Wow64SystemServiceEx+0x1ce
    wow64.dll!Wow64LdrpInitialize+0x429
    ntdll.dll!RtlUniform+0x6e6
    ntdll.dll!RtlCreateTagHeap+0xa7
    ntdll.dll!LdrInitializeThunk+0xe
    ntdll.dll!ZwWaitForSingleObject+0x15
    ntdll.dll!RtlIntegerToUnicodeString+0x20b
    ntdll.dll!LdrUnloadDll+0x2a
    emacs.exe+0x8ff4f
    emacs.exe+0x92a89
    emacs.exe+0x3148
    emacs.exe+0x3017
    emacs.exe+0x14a70
    emacs.exe+0xe513a
    emacs.exe+0x15970
    emacs.exe+0x14e8b
    emacs.exe+0xe513a
    emacs.exe+0x15970
    emacs.exe+0x14e8b
    emacs.exe+0xeab8e
    emacs.exe+0x14b49
    emacs.exe+0xe513a
    emacs.exe+0x15515
    emacs.exe+0x14e8b
    emacs.exe+0x1422d
    emacs.exe+0x2482a
    emacs.exe+0x10c3d
    emacs.exe+0x23818
    emacs.exe+0x1069a
    emacs.exe+0x237d2
    emacs.exe+0x22d8c
    emacs.exe+0x230b9
    emacs.exe+0x29c8
    emacs.exe+0x10fd
    kernel32.dll!BaseThreadInitThunk+0x12
    ntdll.dll!RtlInitializeExceptionChain+0x63
    ntdll.dll!RtlInitializeExceptionChain+0x36
* Emacs stack translation:
    0x108ff4f is in term_winsock (w32.c:6008).
    0x1092a89 is in term_ntproc (w32.c:7455).
    0x1003148 is in shut_down_emacs (emacs.c:1942).
    0x1003017 is in Fkill_emacs (emacs.c:1847).
    0x1014a70 is in Ffuncall (eval.c:2674).
    0x10e513a is in exec_byte_code (bytecode.c:900).
    0x1015970 is in funcall_lambda (eval.c:2906).
    0x1014e8b is in Ffuncall (eval.c:2723).
    0x10e513a is in exec_byte_code (bytecode.c:900).
    0x1015970 is in funcall_lambda (eval.c:2906).
    0x1014e8b is in Ffuncall (eval.c:2723).
    0x10eab8e is in Fcall_interactively (callint.c:839).
    0x1014b49 is in Ffuncall (eval.c:2681).
    0x10e513a is in exec_byte_code (bytecode.c:900).
    0x1015515 is in funcall_lambda (eval.c:2840).
    0x1014e8b is in Ffuncall (eval.c:2723).
    0x101422d is in call1 (eval.c:2468).
    0x102482a is in command_loop_1 (keyboard.c:1586).
    0x1010c3d is in internal_condition_case (eval.c:1193).
    0x1023818 is in command_loop_2 (keyboard.c:1167).
    0x101069a is in internal_catch (eval.c:964).
    0x10237d2 is in command_loop (keyboard.c:1147).
    0x1022d8c is in recursive_edit_1 (keyboard.c:779).
    0x10230b9 is in Frecursive_edit (keyboard.c:844).
    0x10029c8 is in main (emacs.c:1533).
    No source file for address 0x10010fd.

(note-FWIW: this is the only thread that shows some CPU consumption)
* Thread ID: 6276.
* State: Wait:WrUserRequest
* Stack:
    wow64win.dll+0x3fe3a
    wow64win.dll+0x1aea8
    wow64.dll!Wow64SystemServiceEx+0xd7
    wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
    wow64.dll!Wow64SystemServiceEx+0x1ce
    wow64.dll!Wow64LdrpInitialize+0x429
    ntdll.dll!RtlIsDosDeviceName_U+0x24c87
    ntdll.dll!LdrInitializeThunk+0xe
    USER32.dll!DispatchMessageW+0x5c
    emacs.exe+0x14db55
    emacs.exe+0x14dd93
    kernel32.dll!BaseThreadInitThunk+0x12
    ntdll.dll!RtlInitializeExceptionChain+0x63
    ntdll.dll!RtlInitializeExceptionChain+0x36
* Emacs stack translation:
    0x114db55 is in w32_msg_pump (w32fns.c:2417).
    0x114dd93 is in w32_msg_worker@4 (w32fns.c:2645).

* Thread ID: 5516.
* State: Wait:UserRequest
* Stack:
    wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
    wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
    wow64.dll!Wow64SystemServiceEx+0x1ce
    wow64.dll!Wow64LdrpInitialize+0x429
    ntdll.dll!RtlIsDosDeviceName_U+0x24c87
    ntdll.dll!LdrInitializeThunk+0xe
    ntdll.dll!ZwWaitForSingleObject+0x15
    kernel32.dll!WaitForSingleObjectEx+0x43
    kernel32.dll!WaitForSingleObject+0x12
    emacs.exe+0x91a12
    emacs.exe+0x5503d
    kernel32.dll!BaseThreadInitThunk+0x12
    ntdll.dll!RtlInitializeExceptionChain+0x63
    ntdll.dll!RtlInitializeExceptionChain+0x36
* Emacs stack translation:
    0x1091a12 is in _sys_wait_accept (w32.c:6982).
    0x105503d is in reader_thread (w32proc.c:1017).



--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 15 May 2013 18:47:26 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> Hi Eli, I chose your method "2" in the previous mail, and here are the results:

Thanks.

> * Emacs stack translation:
>     0x108ff4f is in term_winsock (w32.c:6008).

This is the main thread that is stuck here:

      if (pfn_WSACleanup () == 0 ||   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	  pfn_WSAGetLastError () == WSAENETDOWN)
	{
	  if (FreeLibrary (winsock_lib))
	  winsock_lib = NULL;
	  return TRUE;
	}

And it looks like it is stuck because the reader thread that listens
to some network connection is waiting for input:

>     0x1091a12 is in _sys_wait_accept (w32.c:6982).
>     0x105503d is in reader_thread (w32proc.c:1017).

here:

  if (rc != SOCKET_ERROR)
    {
      rc = WaitForSingleObject (hEv, INFINITE);  <<<<<<<<<<<<<<<<<<<<<<<<<
      pfn_WSAEventSelect (SOCK_HANDLE (fd), NULL, 0);
      if (rc == WAIT_OBJECT_0)
	cp->status = STATUS_READ_SUCCEEDED;
    }

Does this mean that if you start Emacs with "emacs -Q" and immediately
try to exit, Emacs shuts down cleanly?

Anyway, I will try to come up with some code that will unstuck this.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

> Does this mean that if you start Emacs with "emacs -Q" and immediately
> try to exit, Emacs shuts down cleanly?

Yes.  I still don't know what (user) action triggers this problem, but
it is not too easy to trigger.

Normally, the sessions that get stuck have lasted several days, but
the one that I reported today is a one-day session, in which I think I
didn't visit a single file, and certainly I didn't visit a network
file.  I used that session for copy-pasting text from other programs
into an Emacs buffer and tweak the text there.

Strange... I'll do some experiments tomorrow, and if I find some
repeatable recipe I'll let you know.

Thanks.

--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 15 May 2013 21:11:42 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> Normally, the sessions that get stuck have lasted several days, but
> the one that I reported today is a one-day session, in which I think I
> didn't visit a single file, and certainly I didn't visit a network
> file.

The code involved in this is not about network _files_, it's about
network _connections_, like using the url package or Tramp or FTP.  It
could also be related to the Emacs server and using emacsclient.  So
maybe trying to shut down the Emacs server manually before exiting
Emacs might prevent the lockup.

Try typing "netstat -nbo" at the cmd prompt, it should show you what
network connections belong to Emacs.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 15 May 2013 23:42:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14333@debbugs.gnu.org
> 
> The code involved in this is not about network _files_, it's about
> network _connections_, like using the url package or Tramp or FTP.  It
> could also be related to the Emacs server and using emacsclient.  So
> maybe trying to shut down the Emacs server manually before exiting
> Emacs might prevent the lockup.

Grepping through Lisp files, it looks like these features are the ones
that use server sockets which could be involved in this issue:

  Emacs server (server.el)
  ERC
  Gnus
  Tramp (unlikely, since it only uses server connections for some rare cases)
  org-irc.el

If you use any of these, they are the potential culprits.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> The code involved in this is not about network _files_, it's about
>> network _connections_, like using the url package or Tramp or FTP.  It
>> could also be related to the Emacs server and using emacsclient.  So
>> maybe trying to shut down the Emacs server manually before exiting
>> Emacs might prevent the lockup.
>
> Grepping through Lisp files, it looks like these features are the ones
> that use server sockets which could be involved in this issue:
>
>   Emacs server (server.el)
>   ERC
>   Gnus
>   Tramp (unlikely, since it only uses server connections for some rare cases)
>   org-irc.el
>
> If you use any of these, they are the potential culprits.

Of those, the only feature I think I use is Emacs server, because I
have `(server-start)' in my init file.

And FWIW, the hanged session I reported yesterday didn't have any
client session connected to that server session (I rarely start client
sessions).

--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Thu, 16 May 2013 09:18:16 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> > Grepping through Lisp files, it looks like these features are the ones
> > that use server sockets which could be involved in this issue:
> >
> >   Emacs server (server.el)
> >   ERC
> >   Gnus
> >   Tramp (unlikely, since it only uses server connections for some rare cases)
> >   org-irc.el
> >
> > If you use any of these, they are the potential culprits.
> 
> Of those, the only feature I think I use is Emacs server, because I
> have `(server-start)' in my init file.

That's what I thought.  So, if you start "emacs -Q" and then manually
start the server, does Emacs hang when exiting right after that?

> And FWIW, the hanged session I reported yesterday didn't have any
> client session connected to that server session (I rarely start client
> sessions).

That's expected, because this code near the place where the main
thread was stuck:

  if (winsock_lib != NULL && winsock_inuse == 0)
    {
      /* Not sure what would cause WSAENETDOWN, or even if it can happen
	 after WSAStartup returns successfully, but it seems reasonable
	 to allow unloading winsock anyway in that case. */
      if (pfn_WSACleanup () == 0 ||
	  pfn_WSAGetLastError () == WSAENETDOWN)
	{

clearly shows that winsock_inuse must be zero, which means we already
closed all the socket connections.  The question is, why the reader
thread of one of these connections is still waiting?

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> Of those, the only feature I think I use is Emacs server, because I
>> have `(server-start)' in my init file.
>
> That's what I thought.  So, if you start "emacs -Q" and then manually
> start the server, does Emacs hang when exiting right after that?

It doesn't, nor it hangs if I start Emacs without "-Q" and then I try
to close it.

As I said, it is not too easy to trigger the problem.  I've trying
some experiments this morning, but I'm not able to get a hanged
session on purpose.

--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Thu, 16 May 2013 09:44:53 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> >> Of those, the only feature I think I use is Emacs server, because I
> >> have `(server-start)' in my init file.
> >
> > That's what I thought.  So, if you start "emacs -Q" and then manually
> > start the server, does Emacs hang when exiting right after that?
> 
> It doesn't, nor it hangs if I start Emacs without "-Q" and then I try
> to close it.

Which probably means we have some race condition somewhere...

> As I said, it is not too easy to trigger the problem.  I've trying
> some experiments this morning, but I'm not able to get a hanged
> session on purpose.

When this happens next time, see if you can kill the thread whose call
stack is this:

  * Stack:
      wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
      wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
      wow64.dll!Wow64SystemServiceEx+0x1ce
      wow64.dll!Wow64LdrpInitialize+0x429
      ntdll.dll!RtlIsDosDeviceName_U+0x24c87
      ntdll.dll!LdrInitializeThunk+0xe
      ntdll.dll!ZwWaitForSingleObject+0x15
      kernel32.dll!WaitForSingleObjectEx+0x43
      kernel32.dll!WaitForSingleObject+0x12
      emacs.exe+0x91a12
      emacs.exe+0x5503d
      kernel32.dll!BaseThreadInitThunk+0x12
      ntdll.dll!RtlInitializeExceptionChain+0x63
      ntdll.dll!RtlInitializeExceptionChain+0x36
  * Emacs stack translation:
      0x1091a12 is in _sys_wait_accept (w32.c:6982).
      0x105503d is in reader_thread (w32proc.c:1017).

(IOW, the thread that waits inside _sys_wait_accept), by pushing the
"Kill" button in the Process Explorer's "Threads" display.  If you
succeed in killing the thread (it should get a red background and
perhaps disappear from the display), please see if doing so makes
Emacs exit by itself right after that.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

I've got another hung session, with a newer version of Emacs:


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-05-17 on LEG570
Bzr revision: 112622 eliz@gnu.org-20130517093654-eu3txjz42z99r29y
Windowing system distributor `Microsoft Corp.', version 5.2.3790
Configured using:
 `configure --prefix=/c/usr --enable-checking CFLAGS='-O0 -g3'
 CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/usr/include''

But the call stacks I've got with Process Explorer are different (and
strange), because I see no frames inside Emacs, in any of the threads:

* ID: 584
* State: Wait:UserRequest
* Stack:
    ntoskrnl.exe+0x20908
    ntoskrnl.exe+0x1fb2e
    ntoskrnl.exe+0x10e63e
    ntoskrnl.exe+0x234cb
    ntdll.dll+0x285ec
    ntdll.dll+0x3d281
    ntdll.dll+0x2f20c
    ntdll.dll+0x2f336
    ntdll.dll+0x2f2a3


* ID: 3216
* State: Wait:UserRequest
* Stack:
    ntoskrnl.exe+0x20908
    ntoskrnl.exe+0x1fb2e
    ntoskrnl.exe+0x10e63e
    ntoskrnl.exe+0x234cb
    ntdll.dll+0x285ec
    ntdll.dll+0x3d281
    ntdll.dll+0x2f20c
    ntdll.dll+0x2f336
    ntdll.dll+0x2f2a3
    ntdll.dll+0x28536



* ID: 3696
* State: Wait:UserRequest
* Stack:
    ntoskrnl.exe+0x20908
    ntoskrnl.exe+0x28919
    ntoskrnl.exe+0x19b78d
    ntoskrnl.exe+0x4060c
    ntoskrnl.exe+0x448db
    ntoskrnl.exe+0x1fb2e
    ntoskrnl.exe+0x10e63e
    ntoskrnl.exe+0x234cb
    ntdll.dll+0x285ec
    ntdll.dll+0x3d281
    ntdll.dll+0x2ee3b
    ntdll.dll+0x2ec9f
    ntdll.dll+0x284c5


FWIW, this is the output of `netstat -nbo':


  Conexiones activas

    Proto  Direcci¢n local          Direcci¢n remota        Estado           PID
    TCP    10.161.6.97:1054       10.161.6.3:445         ESTABLISHED     4
    [Sistema]

    TCP    10.161.6.97:2977       10.161.6.6:445         ESTABLISHED     4
    [Sistema]

    TCP    10.161.6.97:3072       10.161.6.6:22          ESTABLISHED     3908
    [putty.exe]

    TCP    10.161.6.97:3389       170.251.78.119:59440   ESTABLISHED     2576
    TermService
    [svchost.exe]

    TCP    10.161.6.97:3681       10.161.19.11:445       ESTABLISHED     4
    [Sistema]

    TCP    10.161.6.97:3686       10.161.6.2:389         ESTABLISHED     820
    Schedule
    [svchost.exe]

    TCP    127.0.0.1:1041         127.0.0.1:42510        ESTABLISHED     1316
    [InoTask.exe]

    TCP    127.0.0.1:42510        127.0.0.1:1041         ESTABLISHED     1264
    [InoRpc.exe]

    TCP    10.161.6.97:2221       10.161.6.2:389         CLOSE_WAIT      820
    AppMgmt
    [svchost.exe]

    TCP    10.161.6.97:2305       10.161.6.2:389         CLOSE_WAIT      820
    AppMgmt
    [svchost.exe]

    TCP    10.161.6.97:2467       10.161.6.2:389         CLOSE_WAIT      820
    AppMgmt
    [svchost.exe]

    TCP    10.161.6.97:2685       10.161.6.2:389         CLOSE_WAIT      820
    Schedule
    [svchost.exe]

    TCP    10.161.6.97:2756       10.161.6.2:389         CLOSE_WAIT      820
    Schedule
    [svchost.exe]

    TCP    10.161.6.97:2867       10.161.6.2:389         CLOSE_WAIT      820
    Schedule
    [svchost.exe]

    TCP    10.161.6.97:2982       10.161.6.2:389         CLOSE_WAIT      820
    Schedule
    [svchost.exe]



--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Tue, 21 May 2013 09:01:01 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> I've got another hung session, with a newer version of Emacs:
> 
> 
> In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
>  of 2013-05-17 on LEG570
> Bzr revision: 112622 eliz@gnu.org-20130517093654-eu3txjz42z99r29y
> Windowing system distributor `Microsoft Corp.', version 5.2.3790
> Configured using:
>  `configure --prefix=/c/usr --enable-checking CFLAGS='-O0 -g3'
>  CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/usr/include''
> 
> But the call stacks I've got with Process Explorer are different (and
> strange), because I see no frames inside Emacs, in any of the threads:

Sorry, I cannot do anything with this information.  I don't have
sources of ntoskrnl and of ntdll.

If Emacs no gets stuck in threads that we didn't launch from our Emacs
application code, then perhaps this is not an Emacs problem at all.

> FWIW, this is the output of `netstat -nbo':

Thanks.  The only ones that might be relevant are those that connect
to localhost:

>     TCP    127.0.0.1:1041         127.0.0.1:42510        ESTABLISHED     1316
>     [InoTask.exe]
> 
>     TCP    127.0.0.1:42510        127.0.0.1:1041         ESTABLISHED     1264
>     [InoRpc.exe]

But I know nothing about these processes.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> But the call stacks I've got with Process Explorer are different (and
>> strange), because I see no frames inside Emacs, in any of the threads:
>
> Sorry, I cannot do anything with this information.  I don't have
> sources of ntoskrnl and of ntdll.
>
> If Emacs no gets stuck in threads that we didn't launch from our Emacs
> application code, then perhaps this is not an Emacs problem at all.

Perhaps, yes.

However, I've observed these hung sessions in two environments quite
different: one is a remote machine running Windows 2003 server (which
I connect to via remote desktop), and the other is my local machine,
which is running Windows 7.

That makes me think that is more probable that the bug is in Emacs
than somewhere else.

>> FWIW, this is the output of `netstat -nbo':
>
> Thanks.  The only ones that might be relevant are those that connect
> to localhost:
>
>>     TCP    127.0.0.1:1041         127.0.0.1:42510        ESTABLISHED     1316
>>     [InoTask.exe]
>>
>>     TCP    127.0.0.1:42510        127.0.0.1:1041         ESTABLISHED     1264
>>     [InoRpc.exe]
>
> But I know nothing about these processes.

Me neither, sorry.

If I get a hung session with "normal" call stacks (having Emacs
frames), I'll try what you told me:  Kill the thread that waits inside
_sys_wait_accept and see if Emacs closes after that.

Thanks.

--
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

FWIW, I've just got another hung session when trying to exit.  The
details are below.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-22 on LEG570
Bzr revision: 113971 monnier@iro.umontreal.ca-20130822040645-0fc4fi87eir72jnb
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --enable-checking CFLAGS='-O0 -g3'
 CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/usr/include''

TID: 2360
State: Wait:UserRequest
Stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
kernel32.dll!WaitForSingleObjectEx+0x43
kernel32.dll!WaitForSingleObject+0x12
emacs.exe+0x20e927 is in _sys_wait_accept (src/w32.c:7062)
emacs.exe+0x214b2f is in reader_thread (src/w32proc.c:1017)
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 3924
State: Wait:UserRequest
Stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!RtlCreateTagHeap+0xa7
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrUnloadDll+0x2a
emacs.exe+0x20cde0 is in term_winsock (src/w32.c:6081).
emacs.exe+0x20f891 is in term_ntproc (src/w32.c:7535).
emacs.exe+0xdb515 is in shut_down_emacs (src/emacs.c:1985).
emacs.exe+0xdb3f9 is in Fkill_emacs (src/emacs.c:1886).
emacs.exe+0x16c3b3 is in Ffuncall (src/eval.c:2853).
emacs.exe+0x1aca5d is in exec_byte_code (src/bytecode.c:905).
emacs.exe+0x16cb95 is in funcall_lambda (src/eval.c:3021).
emacs.exe+0x16c5ef is in Ffuncall (src/eval.c:2902).
emacs.exe+0x1aca5d is in exec_byte_code (src/bytecode.c:905).
emacs.exe+0x16cb95 is in funcall_lambda (src/eval.c:3021).
emacs.exe+0x16c5ef is in Ffuncall (src/eval.c:2902).
emacs.exe+0x165f8b is in Fcall_interactively (src/callint.c:836).
emacs.exe+0x16c408 is in Ffuncall (src/eval.c:2860).
emacs.exe+0x1aca5d is in exec_byte_code (src/bytecode.c:905).
emacs.exe+0x16cb95 is in funcall_lambda (src/eval.c:3021).
emacs.exe+0x16c5ef is in Ffuncall (src/eval.c:2902).
emacs.exe+0x16be9e is in call1 (src/eval.c:2652).
emacs.exe+0xddd2b is in command_loop_1 (src/keyboard.c:1568).
emacs.exe+0x16921c is in internal_condition_case (src/eval.c:1339).
emacs.exe+0xdd1ba is in command_loop_2 (src/keyboard.c:1161).
emacs.exe+0x168b36 is in internal_catch (src/eval.c:1113).
emacs.exe+0xdd172 is in command_loop (src/keyboard.c:1141).
emacs.exe+0xdc929 is in recursive_edit_1 (src/keyboard.c:779).
emacs.exe+0xdcae5 No source file for address 0x1dcae5.
emacs.exe+0xdadb2 is in main (src/emacs.c:1572).
emacs.exe+0x10fd No source file for address 0x10010fd.
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 7296
State: Wait:UserRequest
Stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForMultipleObjects+0x15
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 7316
State: Wait:WrUserRequest
Stack:
wow64win.dll+0x3fe3a
wow64win.dll+0x1aea8
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
USER32.dll!DispatchMessageW+0x5c
emacs.exe+0x1dbcce is in w32_msg_pump (src/w32fns.c:2441).
emacs.exe+0x1dbf0c is in w32_msg_worker@4 (src/w32fns.c:2669).
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 7760
State: Wait:UserRequest
Stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
kernel32.dll!WaitForSingleObjectEx+0x43
kernel32.dll!WaitForSingleObject+0x12
emacs.exe+0x214bed is in reader_thread (src/w32proc.c:1049).
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36



-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Thu, 29 Aug 2013 09:22:59 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> FWIW, I've just got another hung session when trying to exit.  The
> details are below.

I installed what should hopefully fix this.  Please see if things are
better after trunk revision 114068.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

> I installed what should hopefully fix this.  Please see if things are
> better after trunk revision 114068.

Thank you!

I'm already using that version of the program.

Since these hangs used to appear only sporadically, I think we can
close this bug now, and if I ever see the hanging again, I would open
the bug again.


-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Fri, 30 Aug 2013 08:30:39 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> Since these hangs used to appear only sporadically, I think we can
> close this bug now

Done.

Thanks.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

> I installed what should hopefully fix this.  Please see if things are
> better after trunk revision 114068.

Mmmm I'm sorry to report that I just got another hung session even
with that fix applied.


TID: 3436
State: Wait:UserRequest
Stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForMultipleObjects+0x15
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 5784
State: Wait:WrUserRequest
Stack:
wow64win.dll+0x3fe3a
wow64win.dll+0x1aea8
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
USER32.dll!DispatchMessageW+0x5c
emacs.exe+0x1db662 - w32_msg_pump at w32fns.c:2441
emacs.exe+0x1db8a0 - w32_msg_worker@4 at w32fns.c:2669
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 7624
State: Wait:UserRequest
Stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!RtlCreateTagHeap+0xa7
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrGetDllHandleEx+0x29b
ntdll.dll!LdrGetDllHandle+0x18
ntdll.dll!RtlImageNtHeader+0x73a
ntdll.dll!RtlFreeHeap+0x7e
emacs.exe+0x137e   - ??:0
emacs.exe+0xdb4ce  - ?? at cygming-crtbegin.c:0
emacs.exe+0x16be6c - shut_down_emacs at emacs.c:1916
emacs.exe+0x1ac525 - Ffuncall at eval.c:2855
emacs.exe+0x16c64e - exec_byte_code at bytecode.c:905
emacs.exe+0x16c0a8 - funcall_lambda at eval.c:3023
emacs.exe+0x1ac525 - Ffuncall at eval.c:2904
emacs.exe+0x16c64e - exec_byte_code at bytecode.c:905
emacs.exe+0x16c0a8 - funcall_lambda at eval.c:3023
emacs.exe+0x165a23 - Ffuncall at eval.c:2904
emacs.exe+0x16bec1 - Fcall_interactively at callint.c:836
emacs.exe+0x1ac525 - Ffuncall at eval.c:2862
emacs.exe+0x16c64e - exec_byte_code at bytecode.c:905
emacs.exe+0x16c0a8 - funcall_lambda at eval.c:3023
emacs.exe+0x16b957 - Ffuncall at eval.c:2904
emacs.exe+0xddd7f  - call1 at eval.c:2654
emacs.exe+0x168cb4 - command_loop_1 at keyboard.c:1568
emacs.exe+0xdd20e  - internal_condition_case at eval.c:1339
emacs.exe+0x1685ce - command_loop_2 at keyboard.c:1161
emacs.exe+0xdd1c6  - internal_catch at eval.c:1113
emacs.exe+0xdc97d  - command_loop at keyboard.c:1141
emacs.exe+0xdcb39  - recursive_edit_1 at keyboard.c:779
emacs.exe+0xdae06  - Frecursive_edit at keyboard.c:844
emacs.exe+0x10fd   - main at emacs.c:1572
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-29 on LEG570
Bzr revision: 114068 eliz@gnu.org-20130829153204-jlpxfqh9tozhll33
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' 'CPPFLAGS=-DGLYPH_DEBUG=1
 -I/c/usr/include''


-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 11 Sep 2013 10:44:26 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> > I installed what should hopefully fix this.  Please see if things are
> > better after trunk revision 114068.
> 
> Mmmm I'm sorry to report that I just got another hung session even
> with that fix applied.

This is a different problem, at least judging by the call stack.  And
I have no idea what is going on here, especially since this:

  ntdll.dll!RtlFreeHeap+0x7e
  emacs.exe+0x137e   - ??:0
  emacs.exe+0xdb4ce  - ?? at cygming-crtbegin.c:0
  emacs.exe+0x16be6c - shut_down_emacs at emacs.c:1916

doesn't make any sense, as line 1916 of emacs.c is the opening brace
of shut_down_emacs, so it cannot call anything.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

> This is a different problem, at least judging by the call stack.  And
> I have no idea what is going on here, especially since this:
>
>   ntdll.dll!RtlFreeHeap+0x7e
>   emacs.exe+0x137e   - ??:0
>   emacs.exe+0xdb4ce  - ?? at cygming-crtbegin.c:0
>   emacs.exe+0x16be6c - shut_down_emacs at emacs.c:1916
>
> doesn't make any sense, as line 1916 of emacs.c is the opening brace
> of shut_down_emacs, so it cannot call anything.

I see.  I wonder if my translation of those memory addresses was correct.

This time I've done such translation by putting the hexadecimal values
in a file, adding "0x1000000" to each one, and feeding the resulting
file to "addr2line".

-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 11 Sep 2013 16:20:41 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> > This is a different problem, at least judging by the call stack.  And
> > I have no idea what is going on here, especially since this:
> >
> >   ntdll.dll!RtlFreeHeap+0x7e
> >   emacs.exe+0x137e   - ??:0
> >   emacs.exe+0xdb4ce  - ?? at cygming-crtbegin.c:0
> >   emacs.exe+0x16be6c - shut_down_emacs at emacs.c:1916
> >
> > doesn't make any sense, as line 1916 of emacs.c is the opening brace
> > of shut_down_emacs, so it cannot call anything.
> 
> I see.  I wonder if my translation of those memory addresses was correct.
> 
> This time I've done such translation by putting the hexadecimal values
> in a file, adding "0x1000000" to each one, and feeding the resulting
> file to "addr2line".

Sounds OK to me, but perhaps do it both ways and compare the results.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

I've just got another hung session.  Details below.

--------------

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-09-30 on MW7G474MYRXUPA
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Important settings:
  value of $LANG: ESN
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

--------------

TID: 4432
State: Wait:UserRequest
Stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrShutdownThread+0x50
ntdll.dll!RtlExitUserThread+0x2a
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 7332
State: Wait:UserRequest
Stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!RtlCreateTagHeap+0xa7
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrUnloadDll+0x2a
emacs.exe+0x20d8ac term_winsock at w32.c:6099
emacs.exe+0x21038e term_ntproc at w32.c:7558
emacs.exe+0xdf02e shut_down_emacs at emacs.c:1992
emacs.exe+0xdef12 Fkill_emacs at emacs.c:1893
emacs.exe+0x16d684 Ffuncall at eval.c:2856
emacs.exe+0x1adbf9 exec_byte_code at bytecode.c:905
emacs.exe+0x16de66 funcall_lambda at eval.c:3024
emacs.exe+0x16d8c0 Ffuncall at eval.c:2905
emacs.exe+0x1adbf9 exec_byte_code at bytecode.c:905
emacs.exe+0x16de66 funcall_lambda at eval.c:3024
emacs.exe+0x16d8c0 Ffuncall at eval.c:2905
emacs.exe+0x16723b Fcall_interactively at callint.c:836
emacs.exe+0x16d6d9 Ffuncall at eval.c:2863
emacs.exe+0x1adbf9 exec_byte_code at bytecode.c:905
emacs.exe+0x16de66 funcall_lambda at eval.c:3024
emacs.exe+0x16d8c0 Ffuncall at eval.c:2905
emacs.exe+0x16d16f call1 at eval.c:2655
emacs.exe+0xe17b2 command_loop_1 at keyboard.c:1567
emacs.exe+0x16a4cc internal_condition_case at eval.c:1339
emacs.exe+0xe0c41 command_loop_2 at keyboard.c:1160
emacs.exe+0x169de6 internal_catch at eval.c:1113
emacs.exe+0xe0bf9 command_loop at keyboard.c:1140
emacs.exe+0xe03b0 recursive_edit_1 at keyboard.c:778
emacs.exe+0xe056c Frecursive_edit at keyboard.c:843
emacs.exe+0xde8cb main at emacs.c:1579
emacs.exe+0x10b9 __mingw_CRTStartup at crt1.c:244
emacs.exe+0x1284 WinMainCRTStartup at crt1.c:274
emacs.exe+0x1ab668 _start at unexw32.c:118
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 8356
State: Wait:WrUserRequest
Stack:
wow64win.dll+0x3fe3a
wow64win.dll+0x1aea8
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
USER32.dll!DispatchMessageW+0x5c
emacs.exe+0x1dc9d2 w32_msg_pump at w32fns.c:2436
emacs.exe+0x1dcc10 w32_msg_worker@4 at w32fns.c:2664
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 8696
State: Wait:UserRequest
Stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForMultipleObjects+0x15
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36


-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

FWIW, here is another updated backtrace of a hung session I've got
with a recent binary (though it seems to be analogous to the last
backtrace I sent).

TID: 2568
State: Wait:UserRequest
<stack>
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!MD5Final+0x21e83
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrUnloadDll+0x2a
emacs.exe+0x21244e term_winsock at w32.c:6130
emacs.exe+0x2156d3 term_ntproc at w32.c:7852
emacs.exe+0xe3396 shut_down_emacs at emacs.c:2009
emacs.exe+0xe327a Fkill_emacs at emacs.c:1910
emacs.exe+0x1727f0 Ffuncall at eval.c:2805
emacs.exe+0x1b2b73 exec_byte_code at bytecode.c:919
emacs.exe+0x172fd2 funcall_lambda at eval.c:2973
emacs.exe+0x172a2c Ffuncall at eval.c:2854
emacs.exe+0x1b2b73 exec_byte_code at bytecode.c:919
emacs.exe+0x172fd2 funcall_lambda at eval.c:2973
emacs.exe+0x172a2c Ffuncall at eval.c:2854
emacs.exe+0x16bf87 Fcall_interactively at callint.c:836
emacs.exe+0x172845 Ffuncall at eval.c:2812
emacs.exe+0x1b2b73 exec_byte_code at bytecode.c:919
emacs.exe+0x172fd2 funcall_lambda at eval.c:2973
emacs.exe+0x172a2c Ffuncall at eval.c:2854
emacs.exe+0x1722db call1 at eval.c:2604
emacs.exe+0xe5a68 command_loop_1 at keyboard.c:1559
emacs.exe+0x16f6ec internal_condition_case at eval.c:1344
emacs.exe+0xe50bc command_loop_2 at keyboard.c:1169
emacs.exe+0x16ec99 internal_catch at eval.c:1108
emacs.exe+0xe5074 command_loop at keyboard.c:1149
emacs.exe+0xe480c recursive_edit_1 at keyboard.c:776
emacs.exe+0xe49c8 Frecursive_edit at keyboard.c:841
emacs.exe+0xe2c33 main at emacs.c:1596
emacs.exe+0x10b9 __mingw_CRTStartup at crt1.c:244
emacs.exe+0x1284 WinMainCRTStartup at crt1.c:274
emacs.exe+0x1b0580 _start at unexw32.c:118
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
</stack>

TID: 3944
State: Wait:WrUserRequest
<stack>
wow64win.dll+0x3fe3a
wow64win.dll+0x1aea8
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!TpAlpcRegisterCompletionList+0x7f8b
ntdll.dll!LdrInitializeThunk+0xe
USER32.dll!DispatchMessageW+0x5c
emacs.exe+0x1e1de5 w32_msg_pump at w32fns.c:2436
emacs.exe+0x1e2023 w32_msg_worker@4 at w32fns.c:2664
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
</stack>

TID: 5988
State: Wait:UserRequest
<stack>
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!TpAlpcRegisterCompletionList+0x7f8b
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrShutdownThread+0x50
ntdll.dll!RtlExitUserThread+0x2a
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
</stack>

TID: 6132
State: Wait:UserRequest
<stack>
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!TpAlpcRegisterCompletionList+0x7f8b
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForMultipleObjects+0x15
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
</stack>



-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 13 Nov 2013 17:40:58 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> FWIW, here is another updated backtrace of a hung session I've got
> with a recent binary (though it seems to be analogous to the last
> backtrace I sent).

Thanks.

Since time passes and nothing happens with this bug, how about if you
try bisecting on this bug, in order to find the guilty commit?  E.g.,
start with Emacs 24.3 as released and see if the problem happens there
as well.  That way, at least we will collect some more data, which
might prove useful.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

> Since time passes and nothing happens with this bug, how about if you
> try bisecting on this bug, in order to find the guilty commit?  E.g.,
> start with Emacs 24.3 as released and see if the problem happens there
> as well.  That way, at least we will collect some more data, which
> might prove useful.

The problem is that the bug only appears from time to time.  So we
would have to use an older Emacs from a fair amount of time to be
reasonably sure that the bug is not there...  :(

IOW: the bisecting technique would require a lot of time of me using
older versions of Emacs.... :(((

I'd rather prefer keep killing the hung sessions...  :)

(BTW: thanks again for your work)

-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 13 Nov 2013 18:00:39 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> > Since time passes and nothing happens with this bug, how about if you
> > try bisecting on this bug, in order to find the guilty commit?  E.g.,
> > start with Emacs 24.3 as released and see if the problem happens there
> > as well.  That way, at least we will collect some more data, which
> > might prove useful.
> 
> The problem is that the bug only appears from time to time.  So we
> would have to use an older Emacs from a fair amount of time to be
> reasonably sure that the bug is not there...  :(
> 
> IOW: the bisecting technique would require a lot of time of me using
> older versions of Emacs.... :(((

We are in no hurry.

> I'd rather prefer keep killing the hung sessions...  :)

Then I guess we could as well close this bug, as it will never be
fixed.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> IOW: the bisecting technique would require a lot of time of me using
>> older versions of Emacs.... :(((
>
> We are in no hurry.

Yes, I would be in a hurry, because I don't want to be using and old
version of Emacs.

>> I'd rather prefer keep killing the hung sessions...  :)
>
> Then I guess we could as well close this bug, as it will never be
> fixed.

Perhaps today we don't see a way of tracking down the problem, but
that might change.  In any case, I don't see the reason for closing
this bug now, since it isn't fixed, but do it if you deem it
appropriate.

-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 13 Nov 2013 21:50:24 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> > Then I guess we could as well close this bug, as it will never be
> > fixed.
> 
> Perhaps today we don't see a way of tracking down the problem, but
> that might change.  In any case, I don't see the reason for closing
> this bug now, since it isn't fixed, but do it if you deem it
> appropriate.

I don't want to close the bug, I want to solve it.  But for that, I
need some help, and if that's not available even from those who
reported the bug in the first place and evidently suffer from it
enough to annoy them, then too bad.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

(oops, I clicked "reply" instead of "reply all".  Re-sending to the bug list)

>>> Perhaps today we don't see a way of tracking down the problem, but
>>> that might change.  In any case, I don't see the reason for closing
>>> this bug now, since it isn't fixed, but do it if you deem it
>>> appropriate.
>>
>> I don't want to close the bug, I want to solve it.  But for that, I
>> need some help, and if that's not available even from those who
>> reported the bug in the first place and evidently suffer from it
>> enough to annoy them, then too bad.
>
> As you know, I'm willing to help, just not at any price.  And having
> to start using and older version of Emacs is... too bad for me.
>
> Perhaps in the future we'll find a better way of investigating this.
>
> Thanks.



-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Wed, 13 Nov 2013 22:12:22 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> As you know, I'm willing to help, just not at any price.

I don't understand this: can't you run an _additional_ session of
Emacs, in parallel to the one you want to use?  Then, if there are
features that you sorely miss in the old version, you can have them in
the new, running on the same machine.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

Hi Eli,

Today I've got another hung session, and I've succeeded to attach gdb
to such session.

Below is the output of "thread apply all bt".

I'll keep the session open, in case you need me to print some value.

-----------------------

(gdb) thread apply all bt

Thread 5 (Thread 8680.0x1394):
#0  0x778a000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7792f8ee in ntdll!DbgUiRemoteBreakin ()
   from C:\Windows\SysWOW64\ntdll.dll
#2  0x0222a623 in ?? ()
#3  0x76da336a in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\syswow64\kernel32.dll
#4  0x778cbf32 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#5  0x778cbf05 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 4 (Thread 8680.0x2080):
#0  0x778af8d1 in ntdll!ZwWaitForSingleObject ()
   from C:\Windows\SysWOW64\ntdll.dll
#1  0x778af8d1 in ntdll!ZwWaitForSingleObject ()
   from C:\Windows\SysWOW64\ntdll.dll
#2  0x778cb4b4 in ntdll!RtlIntegerToUnicodeString ()
   from C:\Windows\SysWOW64\ntdll.dll
#3  0x778cb398 in ntdll!RtlIntegerToUnicodeString ()
   from C:\Windows\SysWOW64\ntdll.dll
#4  0x778e650d in ntdll!LdrShutdownThread ()
   from C:\Windows\SysWOW64\ntdll.dll
#5  0x779920c0 in ntdll!NlsAnsiCodePage () from C:\Windows\SysWOW64\ntdll.dll
#6  0x1de5a6d3 in ?? ()
#7  0x00000000 in ?? ()

Thread 3 (Thread 8680.0x193c):
#0  0x76fd78d7 in USER32!DispatchMessageW ()
   from C:\Windows\syswow64\user32.dll
#1  0x011e1de5 in w32_msg_pump (msg_buf=0x6eabff28)
    at ../../repo/src/w32fns.c:2436
#2  0x011e2023 in w32_msg_worker@4 (arg=0x0) at ../../repo/src/w32fns.c:2662
#3  0x76da336a in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\syswow64\kernel32.dll
#4  0x778cbf32 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#5  0x778cbf05 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 2 (Thread 8680.0x1120):
#0  0x778b015d in ntdll!ZwWaitForMultipleObjects ()
   from C:\Windows\SysWOW64\ntdll.dll
#1  0x778b015d in ntdll!ZwWaitForMultipleObjects ()
   from C:\Windows\SysWOW64\ntdll.dll
#2  0x778cc6c5 in ntdll!RtlRegisterThreadWithCsrss ()
   from C:\Windows\SysWOW64\ntdll.dll
#3  0x76da336a in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\syswow64\kernel32.dll
#4  0x778cbf32 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#5  0x778cbf05 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 1 (Thread 8680.0x146c):
#0  0x778af8d1 in ntdll!ZwWaitForSingleObject ()
   from C:\Windows\SysWOW64\ntdll.dll
#1  0x778af8d1 in ntdll!ZwWaitForSingleObject ()
   from C:\Windows\SysWOW64\ntdll.dll
#2  0x778cb4b4 in ntdll!RtlIntegerToUnicodeString ()
   from C:\Windows\SysWOW64\ntdll.dll
#3  0x778cb398 in ntdll!RtlIntegerToUnicodeString ()
   from C:\Windows\SysWOW64\ntdll.dll
#4  0x778d3ab8 in ntdll!LdrUnloadDll () from C:\Windows\SysWOW64\ntdll.dll
#5  0x779920c0 in ntdll!NlsAnsiCodePage () from C:\Windows\SysWOW64\ntdll.dll
#6  0x72f5b477 in DSA_GetSize ()
   from C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
#7  0x771f2d1f in KERNELBASE!FreeLibrary ()
   from C:\Windows\syswow64\KernelBase.dll
#8  0x0532c1ad in NSPStartup () from C:\Windows\System32\mswsock.dll
#9  0x0532c207 in NSPStartup () from C:\Windows\System32\mswsock.dll
#10 0x7554af4c in WahEnumerateHandleContexts ()
   from C:\Windows\syswow64\ws2_32.dll
#11 0x7554ae54 in WahEnumerateHandleContexts ()
   from C:\Windows\syswow64\ws2_32.dll
#12 0x7554659e in WSACloseEvent () from C:\Windows\syswow64\ws2_32.dll
#13 0x00000000 in ?? ()



-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Tue, 19 Nov 2013 18:13:20 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> Today I've got another hung session, and I've succeeded to attach gdb
> to such session.
> 
> Below is the output of "thread apply all bt".

Thanks.

Can you try adding this line:

    Sleep (1000);

in term_winsock, right after the call to release_listen_threads, and
see if that helps?

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Tue, 19 Nov 2013 19:36:53 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14333@debbugs.gnu.org
> 
> Can you try adding this line:
> 
>     Sleep (1000);

Actually, let's try with something that should be abundantly enough:

	Sleep (20000);

(that's 20-sec wait).  It will let Emacs wait for 20 sec during exit,
but the question is, does it solve the hang?  If it does, I will come
up with a more clever wait procedure.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> Can you try adding this line:
>>
>>     Sleep (1000);
>
> Actually, let's try with something that should be abundantly enough:
>
>         Sleep (20000);
>
> (that's 20-sec wait).  It will let Emacs wait for 20 sec during exit,
> but the question is, does it solve the hang?  If it does, I will come
> up with a more clever wait procedure.

I patched my emacs that way, and I've used this for two days, but
sadly I've just got another hung session:

(gdb) thread apply all bt

Thread 5 (Thread 4388.0x1ff8):
#0  0x778d000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7795f8ee in ntdll!DbgUiRemoteBreakin () from C:\Windows\SysWOW64\ntdll.dll
#2  0x1d9bdd74 in ?? ()
#3  0x00000000 in ?? ()

Thread 4 (Thread 4388.0xcd4):
#0  0x778df8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
#1  0x778df8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
#2  0x778fb4b4 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
#3  0x778fb398 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
#4  0x7791650d in ntdll!LdrShutdownThread () from C:\Windows\SysWOW64\ntdll.dll
#5  0x779c20c0 in ntdll!NlsAnsiCodePage () from C:\Windows\SysWOW64\ntdll.dll
#6  0x1f56dd84 in ?? ()
#7  0x00000000 in ?? ()

Thread 3 (Thread 4388.0x154c):
#0  0x764e78d7 in USER32!DispatchMessageW () from C:\Windows\syswow64\user32.dll
#1  0x011e1de5 in w32_msg_pump (msg_buf=0x6933ff28) at
../../repo/src/w32fns.c:2436
#2  0x011e2023 in w32_msg_worker@4 (arg=0x0) at ../../repo/src/w32fns.c:2662
#3  0x7733336a in KERNEL32!BaseThreadInitThunk () from
C:\Windows\syswow64\kernel32.dll
#4  0x778fbf32 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#5  0x778fbf05 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 2 (Thread 4388.0x1e44):
#0  0x778e015d in ntdll!ZwWaitForMultipleObjects () from
C:\Windows\SysWOW64\ntdll.dll
#1  0x778e015d in ntdll!ZwWaitForMultipleObjects () from
C:\Windows\SysWOW64\ntdll.dll
#2  0x778fc6c5 in ntdll!RtlRegisterThreadWithCsrss () from
C:\Windows\SysWOW64\ntdll.dll
#3  0x7733336a in KERNEL32!BaseThreadInitThunk () from
C:\Windows\syswow64\kernel32.dll
#4  0x778fbf32 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#5  0x778fbf05 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 1 (Thread 4388.0x16b8):
#0  0x778df8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
#1  0x778df8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
#2  0x778fb4b4 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
#3  0x778fb398 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
#4  0x77903ab8 in ntdll!LdrUnloadDll () from C:\Windows\SysWOW64\ntdll.dll
#5  0x779c20c0 in ntdll!NlsAnsiCodePage () from C:\Windows\SysWOW64\ntdll.dll
#6  0x77f3cf20 in ?? ()
#7  0x698c0878 in ?? ()
#8  0x767e2d1f in KERNELBASE!FreeLibrary () from
C:\Windows\syswow64\KernelBase.dll
#9  0x6fe4c1ad in NSPStartup () from C:\Windows\System32\mswsock.dll
#10 0x6fe4c207 in NSPStartup () from C:\Windows\System32\mswsock.dll
#11 0x771eaf4c in WahEnumerateHandleContexts () from
C:\Windows\syswow64\ws2_32.dll
#12 0x771eae54 in WahEnumerateHandleContexts () from
C:\Windows\syswow64\ws2_32.dll
#13 0x771e659e in WSACloseEvent () from C:\Windows\syswow64\ws2_32.dll
#14 0x00000000 in ?? ()

-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Thu, 21 Nov 2013 18:10:30 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 14333@debbugs.gnu.org
> 
> >> Can you try adding this line:
> >>
> >>     Sleep (1000);
> >
> > Actually, let's try with something that should be abundantly enough:
> >
> >         Sleep (20000);
> >
> > (that's 20-sec wait).  It will let Emacs wait for 20 sec during exit,
> > but the question is, does it solve the hang?  If it does, I will come
> > up with a more clever wait procedure.
> 
> I patched my emacs that way, and I've used this for two days, but
> sadly I've just got another hung session:

Too bad.  This means the fact that WSACloseEvent was on the stack in
your previous report has nothing to do with the problem, and we are
back to square one.

Thanks.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

I still keep getting hung sessions while trying to exit.  For example
just now, with a recent version of Emacs under MS-Windows:

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-06-15 on LEG570
Repository revision: 117347 rgm@gnu.org-20140615175930-x692pxm647xqo0et
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'.

I've been able to attach gdb to the hung process, and get a full
backtrace (see below).

I will leave the session open, in case you need me to print some values.

(gdb) thread apply all bt full

Thread 5 (Thread 4356.0x1b1c):
#0  0x7720000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#1  0x7728f8ee in ntdll!DbgUiRemoteBreakin () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#2  0x7ea7cdd7 in ?? ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 4 (Thread 4356.0x17b0):
#0  0x7720f8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#1  0x7720f8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#2  0x7722b4b4 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#3  0x7722b398 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#4  0x7724650d in ntdll!LdrShutdownThread () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#5  0x772f20c0 in ntdll!NlsAnsiCodePage () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#6  0x7213cd27 in ?? ()
No symbol table info available.
#7  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 4356.0x1798):
#0  0x758778d7 in USER32!DispatchMessageW () from C:\Windows\syswow64\user32.dll
No symbol table info available.
#1  0x011f62d6 in w32_msg_pump (msg_buf=0x73dff28) at
c:/msys/home/Dani/emacs/trunk/src/w32fns.c:2449
        msg = {hwnd = 0x50ad8, message = 275, wParam = 1, lParam = 0,
time = 34482460, pt = {x = 223,
            y = 444}}
        result = 0
        focus_window = 0x403
#2  0x011f6514 in w32_msg_worker@4 (arg=0x0) at
c:/msys/home/Dani/emacs/trunk/src/w32fns.c:2675
        msg = {hwnd = 0x0, message = 0, wParam = 0, lParam = 0, time =
0, pt = {x = 0, y = 0}}
        dummy_buf = {next = 0x0, w32msg = {msg = {hwnd = 0x0, message
= 0, wParam = 0, lParam = 0,
              time = 0, pt = {x = 0, y = 0}}, dwModifiers = 0, rect =
{left = 0, top = 0, right = 0,
              bottom = 0}}, result = 0, completed = 0}
#3  0x751b338a in KERNEL32!BaseThreadInitThunk () from
C:\Windows\syswow64\kernel32.dll
No symbol table info available.
#4  0x7722bf32 in ntdll!RtlInitializeExceptionChain () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#5  0x7722bf05 in ntdll!RtlInitializeExceptionChain () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 4356.0xacc):
#0  0x7721015d in ntdll!ZwWaitForMultipleObjects () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#1  0x7721015d in ntdll!ZwWaitForMultipleObjects () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#2  0x7722c6c5 in ntdll!RtlRegisterThreadWithCsrss () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#3  0x751b338a in KERNEL32!BaseThreadInitThunk () from
C:\Windows\syswow64\kernel32.dll
No symbol table info available.
#4  0x7722bf32 in ntdll!RtlInitializeExceptionChain () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#5  0x7722bf05 in ntdll!RtlInitializeExceptionChain () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 4356.0x1e00):
#0  0x7720f8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#1  0x7720f8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#2  0x7722b4b4 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#3  0x7722b398 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#4  0x77233ab8 in ntdll!LdrUnloadDll () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#5  0x772f20c0 in ntdll!NlsAnsiCodePage () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#6  0x772fdb73 in ?? ()
No symbol table info available.
#7  0x087c0878 in ?? ()
No symbol table info available.
#8  0x76a62d2c in KERNELBASE!FreeLibrary () from
C:\Windows\syswow64\KernelBase.dll
No symbol table info available.
#9  0x6e52c1ad in NSPStartup () from C:\Windows\System32\mswsock.dll
No symbol table info available.
#10 0x6e52c207 in NSPStartup () from C:\Windows\System32\mswsock.dll
No symbol table info available.
#11 0x76aaaf4c in WahEnumerateHandleContexts () from
C:\Windows\syswow64\ws2_32.dll
No symbol table info available.
#12 0x76aaae54 in WahEnumerateHandleContexts () from
C:\Windows\syswow64\ws2_32.dll
No symbol table info available.
#13 0x76aa659e in WSACloseEvent () from C:\Windows\syswow64\ws2_32.dll
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.


-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

On Mon, Jun 30, 2014 at 6:33 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> I still keep getting hung sessions while trying to exit.  For example
> just now, with a recent version of Emacs under MS-Windows:

I guess that the backtrace I sent 10 days ago is not useful.

Perhaps a better approach to find out what's going on here is to make
some local changes in the version I'm running to write useful
information to some file.  If that's a good idea, just send me the
patch and I will report back the information.

-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Thu, 10 Jul 2014 13:44:02 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> Perhaps a better approach to find out what's going on here is to make
> some local changes in the version I'm running to write useful
> information to some file.  If that's a good idea, just send me the
> patch and I will report back the information.

If you are asking me, then I simply don't know what information to
print.  Sorry.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> Perhaps a better approach to find out what's going on here is to make
>> some local changes in the version I'm running to write useful
>> information to some file.  If that's a good idea, just send me the
>> patch and I will report back the information.
>
> If you are asking me, then I simply don't know what information to
> print.  Sorry.

Ok, thanks.

Do you have some suggestion for tracking down this problem?

-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Thu, 10 Jul 2014 17:13:22 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: "14333@debbugs.gnu.org" <14333@debbugs.gnu.org>
> 
> Do you have some suggestion for tracking down this problem?

If you comment out the call to term_winsock in term_ntproc, does the
problem go away?

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> Do you have some suggestion for tracking down this problem?
>
> If you comment out the call to term_winsock in term_ntproc, does the
> problem go away?

Since the problem is not reproducible at will (at least I've not found
a recipe), all I can do is build a version with that change and try it
for a while.

I'll do it.  Thank you.

-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Thu, 10 Jul 2014 21:24:09 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: "14333@debbugs.gnu.org" <14333@debbugs.gnu.org>
> 
> >> Do you have some suggestion for tracking down this problem?
> >
> > If you comment out the call to term_winsock in term_ntproc, does the
> > problem go away?
> 
> Since the problem is not reproducible at will (at least I've not found
> a recipe), all I can do is build a version with that change and try it
> for a while.

That's the idea, yes.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> > If you comment out the call to term_winsock in term_ntproc, does the
>> > problem go away?

I've just got a hung session with a binary built with the above change
(on top of the last pre-release 24.3.92.1).

The backtrace looks similar to the ones already reported:

(gdb) thread apply all bt full

Thread 5 (Thread 6336.0xf00):
#0  0x7725000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#1  0x772df8ee in ntdll!DbgUiRemoteBreakin () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#2  0x186efa2c in ?? ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 4 (Thread 6336.0x17c0):
#0  0x7725f8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#1  0x7725f8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#2  0x7727b4b4 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#3  0x7727b398 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#4  0x7729650d in ntdll!LdrShutdownThread () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#5  0x773420c0 in ntdll!NlsAnsiCodePage () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#6  0x77ccfadc in ?? ()
No symbol table info available.
#7  0x00000000 in ?? ()
No symbol table info available.

Thread 3 (Thread 6336.0x8d4):
#0  0x75b078d7 in USER32!DispatchMessageW () from C:\Windows\syswow64\user32.dll
No symbol table info available.
#1  0x011f5a6c in w32_msg_pump (msg_buf=0x6edcff28) at w32fns.c:2450
        msg = {hwnd = 0x10376, message = 275, wParam = 1, lParam = 0,
time = 13634003, pt = {x = 373,
            y = 537}}
        result = 0
        focus_window = 0x403
#2  0x011f5caa in w32_msg_worker@4 (arg=0x0) at w32fns.c:2676
        msg = {hwnd = 0x0, message = 0, wParam = 0, lParam = 0, time =
0, pt = {x = 0, y = 0}}
        dummy_buf = {next = 0x0, w32msg = {msg = {hwnd = 0x0, message
= 0, wParam = 0, lParam = 0,
              time = 0, pt = {x = 0, y = 0}}, dwModifiers = 0, rect =
{left = 0, top = 0, right = 0,
              bottom = 0}}, result = 0, completed = 0}
#3  0x74a9338a in KERNEL32!BaseThreadInitThunk () from
C:\Windows\syswow64\kernel32.dll
No symbol table info available.
#4  0x7727bf32 in ntdll!RtlInitializeExceptionChain () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#5  0x7727bf05 in ntdll!RtlInitializeExceptionChain () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 6336.0xad4):
#0  0x7726015d in ntdll!ZwWaitForMultipleObjects () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#1  0x7726015d in ntdll!ZwWaitForMultipleObjects () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#2  0x7727c6c5 in ntdll!RtlRegisterThreadWithCsrss () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#3  0x74a9338a in KERNEL32!BaseThreadInitThunk () from
C:\Windows\syswow64\kernel32.dll
No symbol table info available.
#4  0x7727bf32 in ntdll!RtlInitializeExceptionChain () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#5  0x7727bf05 in ntdll!RtlInitializeExceptionChain () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 6336.0x18c4):
#0  0x7725f8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#1  0x7725f8d1 in ntdll!ZwWaitForSingleObject () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#2  0x7727b4b4 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#3  0x7727b398 in ntdll!RtlIntegerToUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#4  0x7726ffd3 in ntdll!LdrGetDllHandleEx () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#5  0x773420c0 in ntdll!NlsAnsiCodePage () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#6  0x77bae01c in ?? ()
No symbol table info available.
#7  0x00000001 in ?? ()
No symbol table info available.
#8  0x7726fd17 in ntdll!RtlValidateUnicodeString () from
C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#9  0x7726fd2f in ntdll!LdrGetDllHandle () from C:\Windows\SysWOW64\ntdll.dll
No symbol table info available.
#10 0x761e1a43 in KERNELBASE!GetModuleFileNameW () from
C:\Windows\syswow64\KernelBase.dll
No symbol table info available.
#11 0x00000001 in ?? ()
No symbol table info available.
#12 0x00000000 in ?? ()
No symbol table info available.


-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Mon, 14 Jul 2014 12:15:11 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: "14333@debbugs.gnu.org" <14333@debbugs.gnu.org>
> 
> >> > If you comment out the call to term_winsock in term_ntproc, does the
> >> > problem go away?
> 
> I've just got a hung session with a binary built with the above change
> (on top of the last pre-release 24.3.92.1).
> 
> The backtrace looks similar to the ones already reported:

Actually, it's not similar, it's quite different.

However, I suspect that GDB lies to us about the backtrace, and at the
very least conceals part of the stack frames.  Could you please
produce the stack traces from Process Explorer, as you did in the
past?

Thanks.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>> The backtrace looks similar to the ones already reported:
>
> Actually, it's not similar, it's quite different.
>
> However, I suspect that GDB lies to us about the backtrace, and at the
> very least conceals part of the stack frames.  Could you please
> produce the stack traces from Process Explorer, as you did in the
> past?

See below.  These stack traces come from the pre-release version
24.3.92, with just the change you told me:

> If you comment out the call to term_winsock in term_ntproc, does the
> problem go away?


TID: 888
State: Wait:WrUserRequest
<stack>
wow64win.dll+0x3fe3a
wow64win.dll+0x1aeac
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!TpAlpcRegisterCompletionList+0x7f8b
ntdll.dll!LdrInitializeThunk+0xe
USER32.dll!DispatchMessageW+0x5c
emacs.exe+0x1f5a6c: w32_msg_pump at w32fns.c:2450
emacs.exe+0x1f5caa: w32_msg_worker@4 at w32fns.c:2678
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
</stack>

TID: 3012
State: Wait:UserRequest
<stack>
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!TpAlpcRegisterCompletionList+0x7f8b
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForMultipleObjects+0x15
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
</stack>

TID: 6792
State: Wait:UserRequest
<stack>
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!MD5Final+0x21e83
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrGetDllHandleEx+0x29b
ntdll.dll!LdrGetDllHandle+0x18
ntdll.dll!RtlDetermineDosPathNameType_U+0x1fa
KERNELBASE.dll!GetModuleFileNameW+0x3bd
KERNELBASE.dll!GetModuleHandleW+0x29
KERNELBASE.dll!GetModuleHandleA+0x34
emacs.exe+0x135a: ?? at cygming-crtbegin.c:0
emacs.exe+0xf60bf: shut_down_emacs at emacs.c:1991
emacs.exe+0xf1ad0: SUBRP at lisp.h:2471
emacs.exe+0xf0375: XSUBR at lisp.h:914
emacs.exe+0x18546f: Ffuncall at eval.c:2815
emacs.exe+0x1c6094: exec_byte_code at bytecode.c:916
emacs.exe+0x185c51: funcall_lambda at eval.c:2983
emacs.exe+0x1856ab: Ffuncall at eval.c:2864
emacs.exe+0x1c6094: exec_byte_code at bytecode.c:916
emacs.exe+0x185c51: funcall_lambda at eval.c:2983
emacs.exe+0x1856ab: Ffuncall at eval.c:2864
emacs.exe+0x17ec53: Fcall_interactively at callint.c:836
emacs.exe+0x1854c4: Ffuncall at eval.c:2822
emacs.exe+0x1c6094: exec_byte_code at bytecode.c:916
emacs.exe+0x185c51: funcall_lambda at eval.c:2983
emacs.exe+0x1856ab: Ffuncall at eval.c:2864
emacs.exe+0x184f5a: call1 at eval.c:2614
emacs.exe+0xf8899: command_loop_1 at keyboard.c:1567
emacs.exe+0x1823cf: internal_condition_case at eval.c:1354
emacs.exe+0xf7eea: command_loop_2 at keyboard.c:1177
emacs.exe+0x18197c: internal_catch at eval.c:1118
emacs.exe+0xf7ea2: command_loop at keyboard.c:1157
emacs.exe+0xf7638: recursive_edit_1 at keyboard.c:777
emacs.exe+0xf77f4: Frecursive_edit at keyboard.c:849
emacs.exe+0xf59f7: main at emacs.c:1648
emacs.exe+0x10b9: __mingw_CRTStartup at crt1.c:244
emacs.exe+0x1284: WinMainCRTStartup at crt1.c:274
emacs.exe+0x1c3a64: _start at unexw32.c:125
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
</stack>

TID: 6956
State: Wait:UserRequest
<stack>
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!TpAlpcRegisterCompletionList+0x7f8b
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrShutdownThread+0x50
ntdll.dll!RtlExitUserThread+0x2a
kernel32.dll!BaseThreadInitThunk+0x19
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
</stack>



-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Mon, 21 Jul 2014 14:35:01 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: "14333@debbugs.gnu.org" <14333@debbugs.gnu.org>
> 
> > However, I suspect that GDB lies to us about the backtrace, and at the
> > very least conceals part of the stack frames.  Could you please
> > produce the stack traces from Process Explorer, as you did in the
> > past?
> 
> See below.  These stack traces come from the pre-release version
> 24.3.92, with just the change you told me:
> 
> > If you comment out the call to term_winsock in term_ntproc, does the
> > problem go away?

Thanks.

Which optional DLLs do you usually have loaded into Emacs at this
stage, and are any of them dependent on libgcc_s_dw2-1.dll?

(Let me know if you need help in determining which DLLs are
dynamically loaded by Emacs by using Process Explorer.)

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

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

> Which optional DLLs do you usually have loaded into Emacs at this
> stage, and are any of them dependent on libgcc_s_dw2-1.dll?
>
> (Let me know if you need help in determining which DLLs are
> dynamically loaded by Emacs by using Process Explorer.)

After googling about this, I think I've managed to get the information
(Menu: View > Lower Pane View > DLLs).

I'm attaching the list of DLLs that appear in the lower pane when I
select the "emacs.exe" process in the upper pane.  As you can see,
"libgcc_s_dw2-1.dll" is not listed there, but I don't know whether
some of those DLLs depend ultimately on "libgcc_s_dw2-1.dll" (I'd say
no, but I'm not sure).  Is there a way to get the full dependency
tree?

Also, note that I've extracted this information from a normal (not
hung) session, because I killed the last hung session.  Do you need me
to report this information from a hung session?

-- 
Dani Moncayo

[-- Attachment #2: emacs.exe.txt.zip --]
[-- Type: application/zip, Size: 1551 bytes --]

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Tue, 22 Jul 2014 08:39:36 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: "14333@debbugs.gnu.org" <14333@debbugs.gnu.org>
> 
> After googling about this, I think I've managed to get the information
> (Menu: View > Lower Pane View > DLLs).

Right.

> I'm attaching the list of DLLs that appear in the lower pane when I
> select the "emacs.exe" process in the upper pane.

Thanks, I will have a look.

> As you can see, "libgcc_s_dw2-1.dll" is not listed there, but I
> don't know whether some of those DLLs depend ultimately on
> "libgcc_s_dw2-1.dll" (I'd say no, but I'm not sure).  Is there a way
> to get the full dependency tree?

I think every DLL that is loaded should be listed.

> Also, note that I've extracted this information from a normal (not
> hung) session, because I killed the last hung session.  Do you need me
> to report this information from a hung session?

Yes, please.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

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

>> I'm attaching the list of DLLs that appear in the lower pane when I
>> select the "emacs.exe" process in the upper pane.
>
> Thanks, I will have a look.
>
>> Also, note that I've extracted this information from a normal (not
>> hung) session, because I killed the last hung session.  Do you need me
>> to report this information from a hung session?
>
> Yes, please.

I'm attaching again the list of DLLs taken from a hung session.

-- 
Dani Moncayo

[-- Attachment #2: emacs.exe.txt --]
[-- Type: text/plain, Size: 4694 bytes --]

Process	CPU	Private Bytes	Working Set	PID	Description	Company Name
(...other processes...)
emacs.exe		13.852 K	12.884 K	7400	GNU Emacs: The extensible self-documenting text editor	Free Software Foundation

Process: emacs.exe Pid: 7400

Name	Description	Company Name	Path
advapi32.dll	Advanced Windows 32 Base API	Microsoft Corporation	C:\Windows\SysWOW64\advapi32.dll
apisetschema.dll	ApiSet Schema DLL	Microsoft Corporation	C:\Windows\System32\apisetschema.dll
comctl32.dll	User Experience Controls Library	Microsoft Corporation	C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
comdlg32.dll	Common Dialogs DLL	Microsoft Corporation	C:\Windows\SysWOW64\comdlg32.dll
cryptbase.dll	Base cryptographic API DLL	Microsoft Corporation	C:\Windows\SysWOW64\cryptbase.dll
dnsapi.dll	DNS Client API DLL	Microsoft Corporation	C:\Windows\SysWOW64\dnsapi.dll
dwmapi.dll	Microsoft Desktop Window Manager API	Microsoft Corporation	C:\Windows\SysWOW64\dwmapi.dll
emacs.exe	GNU Emacs: The extensible self-documenting text editor	Free Software Foundation	C:\msys\home\d.moncayo.melgar\emacs\emacs-24.3.93\src\emacs.exe
FWPUCLNT.DLL	FWP/IPsec User-Mode API	Microsoft Corporation	C:\Windows\SysWOW64\FWPUCLNT.DLL
gdi32.dll	GDI Client DLL	Microsoft Corporation	C:\Windows\SysWOW64\gdi32.dll
imm32.dll	Multi-User Windows IMM32 API Client DLL	Microsoft Corporation	C:\Windows\SysWOW64\imm32.dll
kernel32.dll	Windows NT BASE API Client DLL	Microsoft Corporation	C:\Windows\SysWOW64\kernel32.dll
KernelBase.dll	Windows NT BASE API Client DLL	Microsoft Corporation	C:\Windows\SysWOW64\KernelBase.dll
locale.nls			C:\Windows\System32\locale.nls
lpk.dll	Language Pack	Microsoft Corporation	C:\Windows\SysWOW64\lpk.dll
mpr.dll	Multiple Provider Router DLL	Microsoft Corporation	C:\Windows\SysWOW64\mpr.dll
msctf.dll	MSCTF Server DLL	Microsoft Corporation	C:\Windows\SysWOW64\msctf.dll
msvcrt.dll	Windows NT CRT DLL	Microsoft Corporation	C:\Windows\SysWOW64\msvcrt.dll
mswsock.dll	Microsoft Windows Sockets 2.0 Service Provider	Microsoft Corporation	C:\Windows\SysWOW64\mswsock.dll
NapiNSP.dll	E-mail Naming Shim Provider	Microsoft Corporation	C:\Windows\SysWOW64\NapiNSP.dll
nlaapi.dll	Network Location Awareness 2	Microsoft Corporation	C:\Windows\SysWOW64\nlaapi.dll
nsi.dll	NSI User-mode interface DLL	Microsoft Corporation	C:\Windows\SysWOW64\nsi.dll
ntdll.dll	NT Layer DLL	Microsoft Corporation	C:\Windows\System32\ntdll.dll
ntdll.dll	NT Layer DLL	Microsoft Corporation	C:\Windows\SysWOW64\ntdll.dll
ntmarta.dll	Windows NT MARTA provider	Microsoft Corporation	C:\Windows\SysWOW64\ntmarta.dll
ole32.dll	Microsoft OLE for Windows	Microsoft Corporation	C:\Windows\SysWOW64\ole32.dll
pnrpnsp.dll	PNRP Name Space Provider	Microsoft Corporation	C:\Windows\SysWOW64\pnrpnsp.dll
rasadhlp.dll	Remote Access AutoDial Helper	Microsoft Corporation	C:\Windows\SysWOW64\rasadhlp.dll
rpcrt4.dll	Remote Procedure Call Runtime	Microsoft Corporation	C:\Windows\SysWOW64\rpcrt4.dll
sechost.dll	Host for SCM/SDDL/LSA Lookup APIs	Microsoft Corporation	C:\Windows\SysWOW64\sechost.dll
shell32.dll	Windows Shell Common Dll	Microsoft Corporation	C:\Windows\SysWOW64\shell32.dll
shlwapi.dll	Shell Light-weight Utility Library	Microsoft Corporation	C:\Windows\SysWOW64\shlwapi.dll
SortDefault.nls			C:\Windows\Globalization\Sorting\SortDefault.nls
sspicli.dll	Security Support Provider Interface	Microsoft Corporation	C:\Windows\SysWOW64\sspicli.dll
StaticCache.dat			C:\Windows\Fonts\StaticCache.dat
sysfer.dll	Symantec CMC Firewall sysfer	Symantec Corporation	C:\Windows\SysWOW64\sysfer.dll
user32.dll	Multi-User Windows USER API Client DLL	Microsoft Corporation	C:\Windows\SysWOW64\user32.dll
usp10.dll	Uniscribe Unicode script processor	Microsoft Corporation	C:\Windows\SysWOW64\usp10.dll
uxtheme.dll	Microsoft UxTheme Library	Microsoft Corporation	C:\Windows\SysWOW64\uxtheme.dll
winrnr.dll	LDAP RnR Provider DLL	Microsoft Corporation	C:\Windows\SysWOW64\winrnr.dll
winspool.drv	Windows Spooler Driver	Microsoft Corporation	C:\Windows\SysWOW64\winspool.drv
Wldap32.dll	Win32 LDAP API DLL	Microsoft Corporation	C:\Windows\SysWOW64\Wldap32.dll
wow64.dll	Win32 Emulation on NT64	Microsoft Corporation	C:\Windows\System32\wow64.dll
wow64cpu.dll	AMD64 Wow64 CPU 	Microsoft Corporation	C:\Windows\System32\wow64cpu.dll
wow64win.dll	Wow64 Console and Win32 API Logging	Microsoft Corporation	C:\Windows\System32\wow64win.dll
ws2_32.dll	Windows Socket 2.0 32-Bit DLL	Microsoft Corporation	C:\Windows\SysWOW64\ws2_32.dll
WSHTCPIP.DLL	Winsock2 Helper DLL (TL/IPv4)	Microsoft Corporation	C:\Windows\SysWOW64\WSHTCPIP.DLL

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Tue, 2 Sep 2014 15:18:22 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: "14333@debbugs.gnu.org" <14333@debbugs.gnu.org>
> 
> >> I'm attaching the list of DLLs that appear in the lower pane when I
> >> select the "emacs.exe" process in the upper pane.
> >
> > Thanks, I will have a look.
> >
> >> Also, note that I've extracted this information from a normal (not
> >> hung) session, because I killed the last hung session.  Do you need me
> >> to report this information from a hung session?
> >
> > Yes, please.
> 
> I'm attaching again the list of DLLs taken from a hung session.

Thanks.  I see nothing suspicious here.

Does this happen only when you exit Emacs that runs via the remote
desktop?  If you experience these hangs when running Emacs locally,
could you perhaps show a couple of instances of stack traces of all
the threads when Emacs hangs in a local session?

Otherwise, I'm beginning to think that this is something peculiar to
an rdesktop session.

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

> Does this happen only when you exit Emacs that runs via the remote
> desktop?

I've seen hungs on both local and remote machines (accessed via remote
desktop).  The two list of DLLs that I've submitted are from a local
machine (my office desktop PC, running Windows 7, fwiw).

>  If you experience these hangs when running Emacs locally,
> could you perhaps show a couple of instances of stack traces of all
> the threads when Emacs hangs in a local session?

I will the next time I get a hung session.

Thank you for your time.

-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

>>  If you experience these hangs when running Emacs locally,
>> could you perhaps show a couple of instances of stack traces of all
>> the threads when Emacs hangs in a local session?
>
> I will the next time I get a hung session.

...and here is the stack traces:

On 2014/09/11, with this binary:

  In GNU Emacs 24.3.93.1 (i686-pc-mingw32)
   of 2014-08-25 on MW7G474MYRXUPA
  Windowing system distributor `Microsoft Corp.', version 6.1.7601
  Configured using:
   `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

This is the official 24.3.93 pre-release, plus the patch you told me
(comment out the call to term_winsock in term_ntproc).

The program hung while trying to exit (C-x C-c).

Here is some info about the Emacs threads at that moment, retrieved
using Process Explorer:

TID: 824
STATE: Wait:UserRequest
CALL STACK:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!TpAlpcRegisterCompletionList+0x7f8b
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrShutdownThread+0x50
ntdll.dll!RtlExitUserThread+0x2a
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 3988
STATE: Wait:WrUserRequest
CALL STACK:
wow64win.dll+0x3fe3a
wow64win.dll+0x1aeac
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!TpAlpcRegisterCompletionList+0x7f8b
ntdll.dll!LdrInitializeThunk+0xe
USER32.dll!DispatchMessageW+0x5c
emacs.exe+0x1f6234  w32_msg_pump at w32fns.c:2450
emacs.exe+0x1f6472  w32_msg_worker@4 at w32fns.c:2678
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

TID: 4992
STATE: Wait:UserRequest
CALL STACK:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xf5
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!TpAlpcRegisterCompletionList+0x7f8b
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForMultipleObjects+0x15
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36


TID: 5268
STATE: Wait:UserRequest
CALL STACK:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!MD5Final+0x21e83
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForSingleObject+0x15
ntdll.dll!RtlIntegerToUnicodeString+0x20b
ntdll.dll!LdrGetDllHandleEx+0x29b
ntdll.dll!LdrGetDllHandle+0x18
ntdll.dll!RtlDetermineDosPathNameType_U+0x1fa
KERNELBASE.dll!GetModuleFileNameW+0x3bd
KERNELBASE.dll!GetModuleHandleW+0x29
KERNELBASE.dll!GetModuleHandleA+0x34
emacs.exe+0x135a     ?? at cygming-crtbegin.c:0
emacs.exe+0xf6827    shut_down_emacs at emacs.c:1991
emacs.exe+0xf2238    SUBRP at lisp.h:2471
emacs.exe+0xf0add    XSUBR at lisp.h:914
emacs.exe+0x185bcf   Ffuncall at eval.c:2815
emacs.exe+0x1c685c   exec_byte_code at bytecode.c:916
emacs.exe+0x1863b1   funcall_lambda at eval.c:2983
emacs.exe+0x185e0b   Ffuncall at eval.c:2864
emacs.exe+0x1c685c   exec_byte_code at bytecode.c:916
emacs.exe+0x1863b1   funcall_lambda at eval.c:2983
emacs.exe+0x185e0b   Ffuncall at eval.c:2864
emacs.exe+0x17f3b3   Fcall_interactively at callint.c:836
emacs.exe+0x185c24   Ffuncall at eval.c:2822
emacs.exe+0x1c685c   exec_byte_code at bytecode.c:916
emacs.exe+0x1863b1   funcall_lambda at eval.c:2983
emacs.exe+0x185e0b   Ffuncall at eval.c:2864
emacs.exe+0x1856ba   call1 at eval.c:2614
emacs.exe+0xf9001    command_loop_1 at keyboard.c:1567
emacs.exe+0x182b2f   internal_condition_case at eval.c:1354
emacs.exe+0xf8652    command_loop_2 at keyboard.c:1177
emacs.exe+0x1820dc   internal_catch at eval.c:1118
emacs.exe+0xf860a    command_loop at keyboard.c:1157
emacs.exe+0xf7da0    recursive_edit_1 at keyboard.c:777
emacs.exe+0xf7f5c    Frecursive_edit at keyboard.c:849
emacs.exe+0xf615f    main at emacs.c:1648
emacs.exe+0x10b9     __mingw_CRTStartup at crt1.c:244
emacs.exe+0x1284     WinMainCRTStartup at crt1.c:274
emacs.exe+0x1c422c   _start at unexw32.c:125
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36



-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Eli Zaretskii]

> Date: Fri, 12 Sep 2014 08:14:40 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: "14333@debbugs.gnu.org" <14333@debbugs.gnu.org>
> 
> KERNELBASE.dll!GetModuleFileNameW+0x3bd
> KERNELBASE.dll!GetModuleHandleW+0x29
> KERNELBASE.dll!GetModuleHandleA+0x34
> emacs.exe+0x135a     ?? at cygming-crtbegin.c:0
> emacs.exe+0xf6827    shut_down_emacs at emacs.c:1991
> emacs.exe+0xf2238    SUBRP at lisp.h:2471
> emacs.exe+0xf0add    XSUBR at lisp.h:914
> emacs.exe+0x185bcf   Ffuncall at eval.c:2815
> emacs.exe+0x1c685c   exec_byte_code at bytecode.c:916

This looks like an assertion violation (that somehow leads to a
deadlock).  The call to Ffuncall at eval.c:2815 should have called
Fkill_emacs, after extracting its function pointer:

  2814                case 1:
  2815                  val = (XSUBR (fun)->function.a1 (internal_args[0]));
  2816                  break;

Instead, it seems to hit the assertion violation inside XSUBR.

Could you next time attach GDB to a running Emacs (before it hangs),
or start Emacs under GDB to begin with, put a breakpoint in 'die' and
in 'Fkill_emacs', and see what happens when you exit?  If the
breakpoint inside 'Fkill_emacs' breaks, just type the "continue"
command; Emacs will probably exit normally.  But if the breakpoint in
'die' breaks, please see what kind of object do you have in 'fun', the
value that is passed to XSUBR on line 2815 above.

Do you have some hooks that are run via kill-emacs-query-functions?
If so, what are they?

Also, is it possible that you are exiting Emacs from a client frame,
i.e. a frame that was created by emacsclient?

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Dani Moncayo]

> Could you next time attach GDB to a running Emacs (before it hangs),
> or start Emacs under GDB to begin with, put a breakpoint in 'die' and
> in 'Fkill_emacs', and see what happens when you exit?  If the
> breakpoint inside 'Fkill_emacs' breaks, just type the "continue"
> command; Emacs will probably exit normally.  But if the breakpoint in
> 'die' breaks, please see what kind of object do you have in 'fun', the
> value that is passed to XSUBR on line 2815 above.

I'll try it next time.

> Do you have some hooks that are run via kill-emacs-query-functions?
> If so, what are they?

No, I don't have any such hook.

> Also, is it possible that you are exiting Emacs from a client frame,
> i.e. a frame that was created by emacsclient?

I had only one frame, but it was not a client frame  (but FWIW, I have
(server-start) in my init file).

Thank you.

-- 
Dani Moncayo

bug#14333: 24.3.50; Emacs hangs when trying to exit

[Lars Ingebrigtsen]

Dani Moncayo <dmoncayo@gmail.com> writes:

>> Could you next time attach GDB to a running Emacs (before it hangs),
>> or start Emacs under GDB to begin with, put a breakpoint in 'die' and
>> in 'Fkill_emacs', and see what happens when you exit?  If the
>> breakpoint inside 'Fkill_emacs' breaks, just type the "continue"
>> command; Emacs will probably exit normally.  But if the breakpoint in
>> 'die' breaks, please see what kind of object do you have in 'fun', the
>> value that is passed to XSUBR on line 2815 above.
>
> I'll try it next time.

More information was requested, but no response was given within a few
months, so I'm closing this bug report.  If the problem still exists,
please reopen this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no