bug#18420: 24.3; interaction with external process hangs emacs

[Eli Zaretskii]

> Date: Sun, 07 Sep 2014 03:04:51 -0500
> From: stephen_leake@stephe-leake.org
> 
>     ;; WORKAROUND: process-send-string is supposed to allow accepting
>     ;; process output while writing to process input, but apparently
>     ;; it doesn't, at least on windows via pipes. So break up
>     ;; buf-string, and call accept-process-output explicitly
>     (let ((bytes-per-cycle 2047)
>         (bytes-to-send (length buf-string))
>         (first 0)
>         (last 0))
>       (while (< last bytes-to-send)
>       (setq last (min bytes-to-send (+ first bytes-per-cycle)))
>       (message "%d" last)
>       (process-send-string process (substring buf-string first last))
>       (setq first (1+ last))
>       (accept-process-output process 0.1)))
>     (wisi-ada-parse-session-wait)
>     ))
> 
> It hangs on one of the process-send-string calls in the WORKAROUND loop.

Did you try replacing accept-process-output with sit-for?

How about enlarging the 2nd argument to accept-process-output -- did
you try that, and if so, did it have any effect?

> The loop is replacing an earlier version that used a single
> process-send-string to send the entire buffer string. I was hoping that
> the explicit accept-process-out calls would allow C-g to work, but
> apparently not.

I cannot easily interpret this, too much info is missing.  For
starters, if the parser gets only part of its expected input (whose
size you are apparently passing via command-line arguments), would it
start parsing, or will it wait for the rest?  If the latter, then the
way you've broken the buffer string into chunks will not change
anything, right?

> The external process implements an LALR parser for Ada source; it
> outputs the parse results back to Emacs. There is a lot of output, so
> it can easily fill up the IO queue. Attaching to that process when
> Emacs is hung shows it is blocked writing to stdout, in a normal part
> of the code flow.

Can you tell how much did it write to the pipe at that point?

> Attaching the debugger I have to the Emacs process shows that it is
> also blocked in WriteFile, called from emacs_write, but I can't see
> any farther up the stack; the debugger says the stack is corrupt. I
> don't have debugging symbols, so I can't tell where in Emacs write it
> is.

If you didn't have debugging symbols, GDB wouldn't be able to show you
symbols like emacs_write and WriteFile.

In any case, it sounds like your binary is optimized, in which case
backtraces are not useful at best, and downright misleading at worst.

> I'm working on building Emacs from the pre-release source, and
> installing a compatible debugger.

Be sure to build with CFLAGS='-O0 -g3'.

What is your versions of GCC, Binutils, MinGW runtime, and w32 API
headers, btw?