Crash when interrupting and auto-answering a redirected app in 0.4.4

[costin]

Hi,

I'm experiencing a consistent crash on Win 8.1 SP1 x64 when auto-answering is enabled. Appears both in conemu and outside of it on a pure cmd prompt.

 Problem Event Name:    APPCRASH
  Application Name: cmd.exe
  Application Version:  6.3.9600.17415
  Application Timestamp:    545042b1
  Fault Module Name:    clink_dll_x64.dll
  Fault Module Version: 0.4.4.21105
  Fault Module Timestamp:   54ed21cc
  Exception Code:   c0000005
  Exception Offset: 0000000000003ef5
  OS Version:   6.3.9600.2.0.0.256.4
  Locale ID:    1033
  Additional Information 1: 707b
  Additional Information 2: 707b568e2f8abfc677de7ee74e678a7b
  Additional Information 3: 78ef
  Additional Information 4: 78efad0c170554707f9ac950eb11a61f

The problem seems to appear when running a java app that is redirected to a file:

# gradle build
// press ^C
Terminate batch job (Y/N)?
# gradle build > out
// press ^C
// Crash

Note that this does not occur when the app is not redirected. I suspect the bug might be caused by the fact that the app might steal the output (System.in and System.out) but it's just a hunch.

Note the problem does not occur in clink 0.4.3 nor 0.4.2.

[mridgers]

I tried all sorts of redirection inside a .bat file to no avail sadly. Are you able to get a minidump of the cmd.exe process that has segfaulted? It would be useful to see the contents of clink.log too if possible.

[costin]

Sure. Can you please let me know how I can do that? Some blog post, link somewhere I can use to make sure the dump is in the right format? Thanks!

[MagicAndre1981]

use WER to create a dump: http://msdn.microsoft.com/en-us/library/bb787181%28VS.85%29.aspx. I made a .reg file which configures WER to generate a full dump under C:\localdumps: https://www.dropbox.com/s/x4rhog9aujg53bz/WER_cmd.reg?dl=0

[costin]

For some reason after importing the reg the dumps where under the default folder but nevertheless hopefully it is just as useful: https://www.dropbox.com/sh/vtmxn9p4unl0rf3/AACvujG9R6hJF_PXQzvnnTpia?dl=0

> clink.bat
> gradle build
^C
Terminate (Y/N)
> gradle build > out
^C
//crash

[mridgers]

Thanks! For some reason the minidump was pretty garbled but I did manage to get an address which looked like a possible candidate. Clink will actually create its own minidumps if it crashes but I set the handler after the auto-answering code.

Would you be able to try the build below? I've added a guard against the possible smoking gun in the minidump you provided and increased the scope of Clink's exception handler;

https://www.dropbox.com/sh/hqbrpkf0dpmmizq/AADwEdKRtMkmmDLesBVNtp5Ja/20150408_e90f83

[costin]

Thanks - just tried the dev build and there are no more crashes - thanks!
By the way, if there is some extra information I can provide to make debugging easier, let me know (no idea why my minidump is the way it is).

By the way, one thing I've noticed is that when redirecting, I need to press ^C twice in order to return to the shell:

> command > out.log
^C
// nothing displayed on the screen - type any key nothing happens
^C
^CThe system cannot open the device or file specified.

Looking at the log file it looks like the Terminate batch job is not properly answered as it contains

//potentially some output
Terminate batch job (Y/N)? 

If I press y, the shell properly exists without the cannot open:

> command > out.log
^C
y
> 

Would it be possible to somehow answer the question even when the input is redirected?
While I'm currently reproducing this issue by redirecting manually, I bumped into it while building my projects where the build system keeps redirecting the output and potentially controlling the input and interrupting it leads to the cmd crash. In other words, it's something that I tend to use a lot...

Thanks for looking into this and the fast responses! The fact that the project is simply awesome goes without saying!

[mridgers]

tl;dr; cmd.exe is a mysterious beast.

The redirection and piping of input, output, and error streams isn't all that straight forward when it comes to cmd.exe, and can sometimes require multiple Ctrl-C presses to get back to a prompt. It happens most often with .bat scripts that call out to other .bat scripts. This is regardless of whether Clink in use or not and as much as I'd like to try it isn't trivial to explain.

Take you first example above. What the command command does is important. If it's a .bat script that spawns another .bat script, then it's probable you will need to press Ctrl-C twice - once for each active script. It's important to realise that there can be multiple processes attached to a console that you press Ctrl-C in - it's anyone's guess who actually gets that Ctrl-C.

As for the "cannot open device for file" message - numerous scenarios can occur to cause this. Perhaps two .bat scripts tried to redirect to out.log simultaneously? Maybe one process was pipeline output to the input of another but opening the pipe failed, or it was closed early due to the Ctrl-C?

[costin]

Fair enough - I was hoping there was a way for clink to tag the starting shell and somehow intercept and propagate the 'signal' until it reaches the root but I realize that's not really possible since there are several, independent processes.
You are correct that the command is actually a bat which creates a JVM which handles its own ^C (I assume that's the reason the message shows up only in the log and it is not handled).
Pressing an ^C several times is not an real issue.

Any idea when the next version will be released?

Cheers,

[MagicAndre1981]

@costin importing can fail because of AV suites. Disable it next time or manually add the entry.

[costin]

@MagicAndre1981 I've actually added the .reg manually - probably need to double check that the entry is there and potentially reboot/relog.
Either way, thanks for the tip - I have another toolbox in my arsenal for debugging window crashes.

Cheers!