bug#13546: 24.2.92; Error(s) when sending emails

[Eli Zaretskii <eliz@gnu.org>]

> From: "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com>
> Cc: 13546@debbugs.gnu.org
> Date: Tue, 12 Feb 2013 19:28:30 +0100
> 
> Breakpoint 2, sys_read (fd=6, buffer=0x64b1034 "", count=5) at w32.c:6410
> 6410    in w32.c
> (gdb)
> Continuing.
> warning: sys_read called when read is in progress
> warning: reader_thread.SetEvent failed with 6 for fd 6
> [New Thread 15276.0x6774]
> warning: reader_thread.SetEvent failed with 6 for fd 3
> warning: reader_thread.SetEvent failed with 6 for fd 5
> [New Thread 15276.0x5b0c]
> [New Thread 15276.0x1898]

It's weird, these messages.  I cannot figure out what causes them.  I
see in your screencast that helm launches subprocesses like crazy (it
looks like every pattern character you type runs another Locate
process).  But even if I try simulating such a subprocess pressure, by
launching another 'locate' command every 100 msec, I cannot reproduce
the above messages on my system.  So some other factor is at work
here.

I need more data.  Please modify the way you set breakpoint at
w32.c:6410 as follows:

 (gdb) break w32.c:6410
 (gdb) commands
  > bt 4
  > p fd
  > p fd_info[fd]
  > b *cp
  > continue
  > end

In addition, please add a 3rd breakpoint, like this:

 (gdb) break w32proc.c:2276
 (gdb) commands
  > bt 5
  > p cp
  > p cp->wnd
  > continue
  > end

Please do this right at the beginning of a fresh session, and please
post the entire GDB session until it gets to the "unusable" state.
(You may need to enlarge the Screen Buffer Size property of the cmd
window in which you run GDB, for it to be able to keep all those
message and backtraces.)  It is very important for me to see all the
messages and backtraces one after the other, to see how the problem
develops.

Also, do you per chance have w32-start-process-share-console
customized to a non-nil value?  If so, can you try with it being nil?

> (gdb) p *cp
> $9 = {fd = 3, pid = -1, char_avail = 0x318, char_consumed = 0x314, thrd = 0x31c, hwnd = 0x0,
>   procinfo = {hProcess = 0x0, hThread = 0x0, dwProcessId = 0, dwThreadId = 0}, status = 1,
>   chr = 22 '\026', ovl_read = {Internal = 0, InternalHigh = 0, {{Offset = 0, OffsetHigh = 0},

Not sure if this is important, but every time this breakpoint breaks,
the character read from the pipe is \026, i.e. Ctrl-V.  Does that ring
any bells?