1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Ctrl-C and Java

Discussion in 'Support' started by mmavrov, Apr 3, 2011.

  1. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    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).
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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?
     
  3. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    Java. It is maven build engine, invoked for a long process (runtime is couple of minutes).


    mvn install

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


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

    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).
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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)?
     
  5. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    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.
     
  6. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    The same behavior can be observed not only from TCMD, but also if you execute TCC.EXE as standalone process.
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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.)
     
  8. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    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.
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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.
     
  10. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    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.
     
  11. nikbackm

    Joined:
    May 30, 2008
    Messages:
    194
    Likes Received:
    1
    Just out of curiosity, is it possible to get this to happen with CMD.EXE too?
     
  12. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    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.
     
  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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.
     
  14. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    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.
     
  15. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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?
     
  16. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    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.
     
  17. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    Since you're the only one that can duplicate this, there's nothing I can do until somebody comes up with a reproducible failcase.
     
  18. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    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.
     
  19. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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.)
     
  20. mmavrov

    Joined:
    Mar 15, 2011
    Messages:
    11
    Likes Received:
    0
    http://tranz.it/load.php?id=DJtoggTUgwbqy1fp891556

    xxx.p12 password: xxx

    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.
     

Share This Page