Ctrl-C and Java

[mmavrov]

I'm experiencing the same problem, described in the thread "@PERL and ^C", only it happens when running Java.

If I press Ctrl-C in a console, that runs long tasks in the JVM, the TC tab just vanishes. It happens almost 100% of the time. In the rare occasions that it works as expected (terminating the JVM), I see multiple ^C characters, as if I pressed Ctrl-C numerous times - which is not the case.

It seems quite odd that this hasn't been resolved in the almost three years that "@PERL and ^C" has been reported.

Is there any workaround?

Take Command LE v12.01.45 (and also previous versions, 11 and above).

 

[rconn]

I'm experiencing the same problem, described in the thread "@PERL and ^C", only it happens when running Java.

If I press Ctrl-C in a console, that runs long tasks in the JVM, the TC tab just vanishes. It happens almost 100% of the time. In the rare occasions that it works as expected (terminating the JVM), I see multiple ^C characters, as if I pressed Ctrl-C numerous times - which is not the case.

It seems quite odd that this hasn't been resolved in the almost three years that "@PERL and ^C" has been reported.

The problem with Perl and ^C is a Perl bug, not Take Command or TCC. (The Perl developers apparently have no interest in ever fixing anything in Embedded Perl for Windows, which is one reason I switched to PerlScript in 12.0.)

I haven't heard of a similar problem with Java. Unless you're running Javascript with the internal TCC Active Scripting interface, (i.e., using the SCRIPT command), this would be unrelated to TCC (and to the Perl bug).

Is this a Java app or Javascript?

What is the exact syntax you're using to execute the command?

How have you defined the TC tab window?

Do you have a simple demo app to reproduce the problem?

 

[mmavrov]

Is this a Java app or Javascript?

Java. It is maven build engine, invoked for a long process (runtime is couple of minutes).

What is the exact syntax you're using to execute the command?

mvn install

How have you defined the TC tab window?

File -> New Tab, there's nothing special.


This happened with other programs as well, not only Java, but rarely.

Do you have a simple demo app to reproduce the problem?

Unfortunately I can't disclose the project. But I guess any maven-based project should do.

I think it's important to note that Ctrl-C for some reason is generating more than one keystroke, although it's pressed only once (the multiple ^C^C^C in the console).

 

[rconn]

File -> New Tab, there's nothing special.

I need more details on this -- are you running TCC.EXE or CMD.EXE in the tab window and running maven under TCC/CMD, or are you running maven directly (definitely *not* recommended)?

 

[mmavrov]

I need more details on this -- are you running TCC.EXE or CMD.EXE in the tab window and running maven under TCC/CMD, or are you running maven directly (definitely *not* recommended)?

In the tab, it's TCC prompt running. In the prompt, I:

cd project-directory
mvn install


Then I wait for some of the compilation or test phases (where it is sure that the JVM is running) and press Ctrl-C. Tab disappears.

That's about it.

 

[mmavrov]

The same behavior can be observed not only from TCMD, but also if you execute TCC.EXE as standalone process.

 

[rconn]

The same behavior can be observed not only from TCMD, but also if you execute TCC.EXE as standalone process.

Then it cannot have anything to do with either TCC or TCMD -- this has to be either a JVM problem or something in the Java app itself.

In TCC, when you execute a child process, all keyboard input goes to that process, and the child gets all of the Windows events (like Ctrl-C and Ctrl-Break). TCC will never see the event. Circumventing this would require a major Windows architectural bug, as well as some badly misbehaving Intel silicon.

(When running a console app in a TCMD tab window, TCMD will get the keyboard input & events, and it passes them on to the child console processes.)

 

[mmavrov]

Then it cannot have anything to do with either TCC or TCMD -- this has to be either a JVM problem or something in the Java app itself.

Apparently, it *does* have to do with TCC/TCMD.

I happen to have an old 4NT 5.0, and with it, everything works just fine.
I also have TC/LE 11.00.48, and it also works fine.


Here's what happens with 4NT 5.00U:
--------------------------------------------------------------
..... process output...

.... press ^C ...

Destroying 1 processes
Destroying process..
Destroyed 1 processes

Cancel batch job D:\softdev\apache-maven-2.2.1\bin\mvn.bat ? (Y/N/A) : Y
--------------------------------------------------------------


And here's TC/LE 11.00.48:
--------------------------------------------------------------
..... process output...

.... press ^C ...

Destroying 1 processes
Destroying process..
Destroyed 1 processes
^C
--------------------------------------------------------------


Same process with TC/LE 12.01.45
--------------------------------------------------------------
..... process output...

.... press ^C ...

... tab disappears....
--------------------------------------------------------------

I find it difficult to believe it's JVM's problem.

 

[rconn]

Apparently, it *does* have to do with TCC/TCMD.

The first thing to do is forget about Take Command -- if the problem also occurs in a stand-alone TCC console window, then Take Command has nothing to do with it (and just complicates finding the real culprit).

The second thing is that the exception handler in TCC/LE v11 and TCC v12 is *exactly* the same. But that's also irrelevant since it will never be called when you ^C in a child process. (If you want to argue this point, you need to take it up with Microsoft and Intel!)

Without a reproducible failcase that I could test here, I can't do more than speculate. You might have one or more third-party apps that are injecting dll's into the JVM (and/or TCC) that are reacting badly to the ^C. You might have another app or plugin that's installing a low-level keyboard hook. Or you might have a keyboard driver that's doing something odd.

 

[mmavrov]

What I am trying to explain is that I have the problem on my system with only TakeCommand LE v12. On the same system at the same time, TakeCommand LE v11 works as expected. The configuration is shared between v11 and v12.

I will try to create a test case for this issue.

 

[nikbackm]

Just out of curiosity, is it possible to get this to happen with CMD.EXE too?

 

[mmavrov]

Just out of curiosity, is it possible to get this to happen with CMD.EXE too?

No, if I run the command under CMD.EXE (in TakeCommand tab), there are no problems, I am returned to the command prompt as expected.


However, I was able to reproduce it with (standalone) TCC.EXE v10, v11 and v12.

4NT.EXE v5 works OK.

 

[rconn]

What I am trying to explain is that I have the problem on my system with only TakeCommand LE v12. On the same system at the same time, TakeCommand LE v11 works as expected. The configuration is shared between v11 and v12.

I will try to create a test case for this issue.

You said previously that you have the same problem with TCC in a standalone console window. So Take Command and/or Take Command/LE is completely irrelevant; you need to remove it from the test, as it vastly complicates the testing.

Do the testing & test case creation solely in TCC or TCC/LE.

 

[mmavrov]

You said previously that you have the same problem with TCC in a standalone console window. So Take Command and/or Take Command/LE is completely irrelevant; you need to remove it from the test, as it vastly complicates the testing.

Do the testing & test case creation solely in TCC or TCC/LE.

As mentioned in my response to nickbackm, I'm seeing the same behavior in TCC/LE 10, 11 and 12.

If I run CMD.EXE inside TCC/LE, everything works fine. But with TCC alone, pressing Ctrl-C while compilation/unit-testing is running, the console window disappears.

 

[rconn]

As mentioned in my response to nickbackm, I'm seeing the same behavior in TCC/LE 10, 11 and 12.

If I run CMD.EXE inside TCC/LE, everything works fine. But with TCC alone, pressing Ctrl-C while compilation/unit-testing is running, the console window disappears.

You seem to be contradicting yourself here -- in an earlier post, you said it worked with v11. Are you now saying it fails with both v11 and v12?

Do you have a reproducible failcase yet?

 

[mmavrov]

You seem to be contradicting yourself here -- in an earlier post, you said it worked with v11. Are you now saying it fails with both v11 and v12?

Yes, I am now saying that it fails in v10 (after some minor version), v11 and v12.

Do you have a reproducible failcase yet?

The only consistently failing case is my working project, but it's sources are confidential, so I can't post it here.

Note that running CMD.EXE in a TCC.EXE console is working correctly every time.

 

[rconn]

Yes, I am now saying that it fails in v10 (after some minor version), v11 and v12.

The only consistently failing case is my working project, but it's sources are confidential, so I can't post it here.

Note that running CMD.EXE in a TCC.EXE console is working correctly every time.

Since you're the only one that can duplicate this, there's nothing I can do until somebody comes up with a reproducible failcase.

 

[mmavrov]

I think I got a reproducible scenario. It seems the whole issue is related in some way to long directory paths. Here's how to reproduce it:

1. Create the path: D:\Pedro\Buongiorno\mts-bonus-ws\com.buongiorno.ru.mts.bonus.webservices\src\main\certs
2. Put some PKCS12 file in this directory
3. Do: openssl pkcs12 pkcs12_file_name.p12
4. On the password prompt press Ctrl-C.
5. TCMD tab disappears.

I use the cygwin openssl.

This scenario exposes the issue in 100% of the time.

 

[rconn]

I think I got a reproducible scenario. It seems the whole issue is related in some way to long directory paths. Here's how to reproduce it:

1. Create the path: D:\Pedro\Buongiorno\mts-bonus-ws\com.buongiorno.ru.mts.bonus.webservices\src\main\certs
2. Put some PKCS12 file in this directory
3. Do: openssl pkcs12 pkcs12_file_name.p12
4. On the password prompt press Ctrl-C.
5. TCMD tab disappears.

I use the cygwin openssl.

This scenario exposes the issue in 100% of the time.

Two problems:

1) I don't have any PKCS12 files on my system -- can you email me one?

2) What does this have to do with Java? Is the Cygwin OpenSSL using the JVM? (Seems unlikely, since AFAIK OpenSSL is written in C.)

 

[mmavrov]

Two problems:

1) I don't have any PKCS12 files on my system -- can you email me one?

http://tranz.it/load.php?id=DJtoggTUgwbqy1fp891556

xxx.p12 password: xxx

2) What does this have to do with Java? Is the Cygwin OpenSSL using the JVM? (Seems unlikely, since AFAIK OpenSSL is written in C.)

It doesn't. At first I thought it has to do with the JVM, because the behavior was exposed by Ctrl-C-ing maven build processes. Only lately I was able to observe this behavior with other Ctrl-C-ed processes in a directory with a long name.