Runtime.exec() hangs on solaris 10, deadlock in soft_delete_session ?

Hi,
In my application sometimes Runtime.exec calls hangs for ever.
The pstack of java process is at the end of the post. It seems like there is a deadlock in soft_delete_session.
Does anyone know of any java/os patch we can apply to fix this issue?
I will really appreciate any tips to get over this issue.
# uname -a
SunOS thor256 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-V245
# /opt/VRTSjre/jre1.5/bin/java -version
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)
The trace is as follows:
0xff340408 __lwp_park + 0x10
0xff339068 mutex_lock_internal + 0x5d0
0xfb08a2ec soft_delete_session + 0xf0
0xfb089f90 soft_delete_all_sessions + 0x4c
0xfb084348 finalize_common + 0x70
0xfb0844d8 softtoken_fini + 0x44
0xfb0d8d48 _fini + 0x4
0xff3c00d0 call_fini + 0xc8
0xff3ca614 remove_hdl + 0xab8
0xff3c4d54 dlclose_intn + 0x98
0xff3c4e68 dlclose + 0x5c
0xfb3a2b3c pkcs11_slottable_delete + 0x138
0xfb39d664 pkcs11_fini + 0x4c
0xff2c0ea0 postforkchild_handler + 0x30
0xff332c20 fork + 0x140
0xfe8f8df4 Java_java_lang_UNIXProcess_forkAndExec + 0x7d4
0xf9226020 0xf9226020 * java.lang.UNIXProcess.forkAndExec(byte[], byte[], int, byte[], int, byte[], boolean, java.io.FileDescriptor, java.io.FileDescriptor, java.io.FileDescriptor) bci:0 (Compiled frame; information may be imprecise)
0xf92216c4 0xf92216c4 * java.lang.UNIXProcess.(byte[], byte[], int, byte[], int, byte[], boolean) bci:62 line:53 (Compiled frame)
0xf90fa6b8 0xf90fa6b8 * java.lang.ProcessImpl.start(java.lang.String[], java.util.Map, java.lang.String, boolean) bci:182 line:65 (Compiled frame)
0xf90fbe0c 0xf90fbe0c * java.lang.ProcessBuilder.start() bci:112 line:451 (Compiled frame)
0xf921842c 0xf921842c * java.lang.Runtime.exec(java.lang.String[], java.lang.String[], java.io.File) bci:16 line:591 (Compiled frame)
0xf9005874 * java.lang.Runtime.exec(java.lang.String[]) bci:4 line:464 (Interpreted frame)
0xf9005874 * TestExec.run() bci:26 line:22 (Interpreted frame)
0xf9005c2c * java.lang.Thread.run() bci:11 line:595 (Interpreted frame)
0xf9000218
0xfecdca88 void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) + 0x5b8
0xfecf4310 void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,symbolHandle,symbolHandle ,Thread*) + 0x18c
0xfecf416c void thread_entry(JavaThread*,Thread*) + 0x12c
0xfecf3ff0 void JavaThread::run() + 0x1f4
0xff02fb30 void*_start(void*) + 0x200
0xff340368 lwpstart

Found this information about this problem:
Bug: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6276483
Info for patch 127111-11: http://sunsolve.sun.com/search/document.do?assetkey=1-21-127111-11-1
Download page: http://sunsolve.sun.com/show.do?target=patches/zos-s10

Similar Messages

  • Running java process in a while loop using Runtime.exec() hangs on solaris

    I'm writting a multithreaded application in which I'll be starting multiple instances of "AppStartThread" class (given below). If I start only one instance of "AppStartThread", it is working fine. But if I start more than one instance of "AppStartThread", one of the threads hangs after some time (occasionaly). But other threads are working fine.
    I have the following questions:
    1. Is there any problem with starting a Thread inside another thread?. Here I'm executing the process in a while loop.
    2. Other thing i noticed is the Thread is hanging after completing the process ("java ExecuteProcess"). But the P.waitFor() is not coming out.
    3. Is it bcoz of the same problem as given in Bug ID : 4098442 ?.
    4. Also java 1.2.2 documentation says:
    "Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock. "
    I'm running this on sun Solaris/java 1.2.2 standard edition. If any of you have experienced the same problem please help me out.
    Will the same problem can happen on java 1.2.2 enterprise edition.?
    class AppStartThread implements Runnable
    public void run()
    while(true)
    try
    Process P=Runtime.getRuntime().exec("java ExecuteProcess");
    P.waitFor();
    System.out.println("after executing application.");
    P.destroy();
    P = null;
    System.gc();
    catch(java.io.IOException io)
    System.out.println("Could not execute application - IOException " + io);
    catch(java.lang.InterruptedException ip)
    System.out.println("Could not execute application - InterruptedException" + ip);
    catch (Exception e)
    System.out.println("Could not execute application -" + e.getMessage());

    I'm writting a multithreaded application in which I'll
    be starting multiple instances of "AppStartThread"
    class (given below). If I start only one instance of
    "AppStartThread", it is working fine. But if I start
    more than one instance of "AppStartThread", one of the
    threads hangs after some time (occasionaly). But other
    threads are working fine.
    I have the following questions:
    1. Is there any problem with starting a Thread inside
    another thread?. Here I'm executing the process in a
    while loop.Of course this is OK, as your code is always being run by one thread or another. And no, it doesn't depend on which thread is starting threads.
    2. Other thing i noticed is the Thread is hanging
    after completing the process ("java ExecuteProcess").
    But the P.waitFor() is not coming out.This is a vital clue. Is the process started by the Runtime.exec() actually completing or does the ps command still show that it is running?
    3. Is it bcoz of the same problem as given in Bug ID :
    4098442 ?.
    4. Also java 1.2.2 documentation says:
    "Because some native platforms only provide limited
    ed buffer size for standard input and output streams,
    failure to promptly write the input stream or read the
    output stream of the subprocess may cause the
    subprocess to block, and even deadlock. "These two are really the same thing (4098442 is not really a bug due to the reasons explained in the doc). If the program that you are exec'ing produces very much output, it is possible that the buffers to stdout and stderr are filling preventing your program from continuing. On Windows platforms, this buffer size is quite small (hundreds of characters) while (if I recall) on Solaris it is somewhat larger. However, I have seent his behavior causing problem on Solaris 8 in my own systems.
    I once hit this problem when I was 'sure' that I was emitting no output due to an exception being thrown that I wasn't even aware of - the stack trace was more than enough to fill the output buffer and cause the deadlock.
    You have several options. One, you could replace the System.out and System.err with PrintStream's backed up by (ie. on top of) BufferedOutputStream's that have large buffers (multi-K) that in turn are backed up by the original out and err PrintStream's. You would use System.setErr() and System.setOut() very early (static initializer block) in the startup of your class. The problem is that you are still at the mercy of code that may call flush() on these streams. I suppose you could implement your own FilterOutputStream to eat any flush requests...
    Another solution if you just don't care about the output is to replace System.out and System.err with PrintStreams that write to /dev/nul. This is really easy and efficient.
    The other tried and true approach is to start two threads in the main process each time you start a process. These will simply consume anything that is emitted through the stdout and stderr pipes. These would die when the streams close (i.e. when the process exits). Not pretty, but it works. I'd be worried about the overhead of two additional threads per external process except that processes have such huge overhead (considering you are starting a JVM) that it just won't matter. And it's not like the CPU is going to get hit much.
    If you do this frequently in your program you might consider using a worker thread pool (see Doug Lea's Executor class) to avoid creating a lot of fairly short-lived threads. But this is probably over-optimizing.
    Chuck

  • Runtime.exec() hangs with 1.4.1

    Hello altogether,
    I am trying to execute a command with Runtime.getRuntime.exec()
    I have already taken care of capturing the output and I observe that depending of the program I try to execute the process hangs.
    I am using JRE 1.4.1_02 under Redhat 7.2 with kernel 2.4.18-26
    Executing the same program under JRE 1.3.1 the program does not hang.
    Executing 'top -bn0q' hangs, executing 'ls -als' it hangs.
    Here is my sample code:
    <code>
    import java.io.*;
    public class Exec
    /** catches the output in a parallel thread */
    class StreamReader extends Thread
    String category = null;
    InputStream is;
    StreamReader(String category, InputStream is)
    this.category = category;
    this.is = is;
    public void run()
    try
    System.out.println(this.category+": reader runs");
    InputStreamReader isr = new InputStreamReader(this.is);
    BufferedReader br = new BufferedReader(isr);
    String line = null;
    while (br.ready() && (line = br.readLine())!=null)
    System.out.println(this.category+':'+line);
    catch (Exception e)
    e.printStackTrace();
    public void run(String[] cmd)
    StringBuffer outStrBuf = new StringBuffer();
    try
    Runtime rt = Runtime.getRuntime();
    System.out.println("got runtime");
    Process process = rt.exec(cmd);
    System.out.println("fired cmd");
    // any errors
    System.out.println("prepare error stream");
    StreamReader errSr = new StreamReader("ERR",process.getErrorStream());
    // any output
    System.out.println("prepare output stream");
    StreamReader outSr = new StreamReader("OUT",process.getInputStream());
    // start the readers to read
    System.out.println("start readers");
    errSr.start();
    outSr.start();
    System.out.println("waiting for process to end");
    process.waitFor(); //Waits for the subprocess to complete.
    catch (Exception e)
    System.err.println("Error while executing cmd: " + cmd);
    e.printStackTrace();
    System.out.println(outStrBuf);
         public static void main(String[] args)
    String [] cmd = {"top","-bn0q"};
    if (args.length >= 1)
    cmd = args;
    System.out.println(args[0]);
    Exec exec = new Exec();
    exec.run(cmd);
    </code>
    The output of java Exec is:
    [user]$ java Exec
    got runtime
    fired cmd
    prepare error stream
    prepare output stream
    start readers
    waiting for process to end
    OUT: reader runs
    ERR: reader runs
    ...and there it hangs. Interesting is, that when I use ls -als as command, I get the directory listing.
    Do you have any ideas what I am doing wrong? Is there any difference in the Runtime.exec() between 1.3 and 1.4 version?

    Unbelievable and what a shame. I was hacking 2 days on several variations of this problem and the solution and I finally found one difference:
    while (br.ready() && (line = br.readLine())!=null)
    I assume that when executing the command, the output streams are not ready and my Output gobbler threads end.
    ...however the command is still executing and starts to write its output. And as we all know this will overflow the buffer and the process hangs.
    So the final solution is:
    /** catches the output in a parallel thread */
    class StreamReader extends Thread
      String category = null;
      InputStream is;
      StreamReader(String category, InputStream is)
        this.category = category;
        this.is = is;
      public void run()
        try
          System.out.println(this.category+": reader runs");
          InputStreamReader isr = new InputStreamReader(this.is);
          BufferedReader br = new BufferedReader(isr);
          String line = null;
          while (/**br.ready() &&*/ (line = br.readLine())!=null)
            System.out.println(this.category+':'+line);
        catch (Exception e)
          e.printStackTrace();
    }So the only question that I have open: Why does this makes no problem with 1.3 but with 1.4 ?

  • Runtime.exec hang

    I used Runtime class to run a 3rd party exe. If I just called
    Runtime.exec("3rd.exe whatever"), 3rd.exe would run half way
    then hang. If I called Runtime.exec("start 3rd.exe whatever"),
    3rd.exe would run successfully. However, Runtime.getInputStream
    couldn't receive the output from 3rd.exe.
    Is any way I can get the output from 3rd.exe with "start 3rd.exe
    whatever"?

    Hi,KellanMom :
    I also experienced this problem.
    You should read sth from Process's inputStream,
    outputStream and errorStream.
    You can browse "http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html" to get details.
    Regards.
    Sunway

  • Runtime.exec hangs even If I drain output.

    Hi Everyone,
    I'm trying to make a program that would give me access to a command line on a remote server. So what I'm trying to do is use Runtime.exec("cmd") to open a command line, then reading from it and printing to it normally.
    The problem is the same very common problem anyone using exec encounters: it hangs. The thing is, however, I do drain the input and error streams immediately, but it still hangs, and here's a curious thing:
    When I use a BufferedReader and use its readLine() method, it only manages to read the first two lines before it hangs, giving me an output such as this:
    +Microsoft Windows XP [Version 5.1.2600]+
    +(C) Copyright 1985-2001 Microsoft Corp.+
    Of course I placed the System.out.println inside the loop that reads lines, cause if I put it outside the loop, I don't get any output at all because the subprocess hangs before the loop is finished.
    Now if I don't use a buffer, and use the input's stream's read() method, it reads all the way through the output, but hangs at the end where it's supposed to read -1, and never reads it.
    I thought maybe I could bypass that, and break the loop at the last character in the output (the character '>'). Now while this works the first time, sending the output to the client like this:
    +Microsoft Windows XP [Version 5.1.2600]+
    +(C) Copyright 1985-2001 Microsoft Corp.+
    F:\eclipse workspace\RemCommand>
    However it doesn't work after that, when I try to type any command. I send my command to the subprocess normally using a PrintWriter, and then try to read the output, but that fails because apparently the subprocess is still stuck at the -1 from the previous read operation.
    I really don't know what the problem is, is it possible that the read possibly doesn't return -1 at all, maybe returns a different character to signify the end or something, and my loop keeps trying to read or what?
    I'm at my wits end.
    Any help?
    Thanks in advance.

    Here is the code again. Check the somehow improved detection of the default Windows prompt.
    Check the lines in comments that allow you to define your own, perhaps more reliable prompt.
    import java.io.*;
    import java.util.*;
    public class Cmd
      public static void main( String[] args ) throws Exception
        ProcessBuilder pb = new ProcessBuilder( "cmd" );
    //    Map<String, String> env = pb.environment();
    //    env.put( "PROMPT", ".,.,." );
        pb.redirectErrorStream( true );
        Process p = pb.start();
        InputStream is = p.getInputStream();
        OutputStream os = p.getOutputStream();
        PrintWriter pw = new PrintWriter( os, true );
        readToPrompt( is );
        pw.println( "dir" );
        readToPrompt( is );
        pw.println( "ipconfig" );
        readToPrompt( is );
        pw.println( "netstat" );
        readToPrompt( is );
      private static void readToPrompt( InputStream is ) throws IOException
        String s = "";
        for (;;)
          int i = is.read();
          if ( i < 0 )
            System.out.println();
            System.out.println( "EOF" );
            System.exit( 0 );
          s += new String( new byte[] { ( byte )i } ).charAt( 0 );
          if ( s.endsWith( "\r\n" ) )
            System.out.print( s );
            s = "";
    //      if ( s.equals( ".,.,." ) )
          if ( s.length() > 2 && s.charAt( 0 ) >= 'A' && s.charAt( 0 ) <= 'Z' && s.charAt( 1 ) == ':' && s.endsWith( ">" ) )
            System.out.print( s );
            break;
    }Edited by: baftos on Sep 10, 2008 11:27 AM

  • Runtime.exec - hangs or doesn't produce output

    Hey,
    I've been trying to get my program to run an application that I downloaded off the net. It is a console based telnet application build for windows. Now, I've been trying to bascially automate some telnet stuff but it doesn't seem to work at the moment that is it doesn't give me output and it causes my computer to slow down. I've noticed that it does start the application which causes the slow down but I was wondering why it doesn't give me any output. Here is the code that I have
    import java.io.*;
    public class Main
      public static void main(String[] args)
        String command = new String[3];
        command[0] = "cmd.exe";
        command[1] = "/C";
        command[2] = "D:\\Temp\\telnet\telnet.exe";
        try
          Process p = Runtime.getRuntime().exec(command);
          BufferdReader stdin = new BufferedReader(new InputStreamReader
                                                   (p.getInputStream()));
          BufferedReader stderr = new BufferedRader(new InputStreamReader
                                                   (p.getErrorStream()));
          PrintStream stdout = new PrintStream(p.getOutputStream());
          String line = "";
          while((line = stderr.readLine()) != null)
            System.out.println(line);
          System.out.println();
          while((line = stdin.readLine()) != null)
            System.out.println(line);
          p.destroy();
        catch(Exception ex)
          System.out.println("Exception: " + ex.getMessage());
          System.exit(-1);
    }Could some please help me and trying to get this program to work?
    Thanks,
    Ny

    now try it
    you should get
    D:\Temp\telnet' is not recognized as an internal or external command,
    operable program or batch file.
    as an output
    import java.io.*;
    public class Main{
      public static void main(String[] args)
        String[] command = new String[3];
        command[0] = "cmd.exe";
        command[1] = "/C";
        command[2] = "D:\\Temp\\telnet\telnet.exe";
        try
          Process p = Runtime.getRuntime().exec(command);
          BufferedReader stdin = new BufferedReader(new InputStreamReader
                                                   (p.getInputStream()));
          BufferedReader stderr = new BufferedReader(new InputStreamReader
                                                   (p.getErrorStream()));
          PrintStream stdout = new PrintStream(p.getOutputStream());
          String line = "";
          while((line = stderr.readLine()) != null)
            System.out.println(line);
          System.out.println();
          while((line = stdin.readLine()) != null)
            System.out.println(line);
          p.destroy();
        catch(Exception ex)
          System.out.println("Exception: " + ex.getMessage());
          System.exit(-1);
    }

  • Runtime.exec() hangs

    When i am trying to execute a particular dos program from my java program, the system hangs. I am not even trying to retrieve any output from the program in my java code. Executing the same program from the dos shell doesn't cause any problems.
    I am running on Win98 --- hitting CTRL-ALT-DEL tells me that "winoldap" is NOT RESPONDING ---- i don't know what this is (atleast not the name of the program i am executing)
    PLEASE HELP.

    http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html

  • The Runtime.exec methods doesn't work well on Solaris ???

    I have two threads and I set the different running time.
    I use Runtime.exec to a run the command and use Process to get the process.
    It works properly in the windows2000 platform.
    However, when I transfer the platform to Solaris...and run the program...
    Two threads always at the same time....It is very wired....I always debug
    for 2 days....
    (at first I run "vmstat 1 2" command, later I change to "ls","rmdir"....etc,
    all of them don't work.....
    If I close the Runtime.exec..........Everything works well......)
    And I study the API. I found this message...
    The Runtime.exec methods may not work well for special processes on certain
    native platforms, such as native windowing processes, daemon processes,
    Win16/DOS processes on Win32, or shell scripts. The created subprocess does
    not have its own terminal or console.
    Could someone share her/his experience.....:(
    And if any other way I can run command inside java code instead of
    Runtime.exec.....???
    Please reply my mail to [email protected] I do appreciate your kindly &
    great help!!!!!!!!
    This is my code.......
    import java.io.*;
    import java.lang.*;
    import java.util.*;
    * <p>ServerThread1</p>
    * <p>??�X???��?�D???�X???, "Vmstat 1 2".</p>
    class ServerThread1 extends Thread{
    private ServerAgent Sa;
    public ServerThread1 (String Name, ServerAgent Sa){
    super(Name);
    this.Sa = Sa; file://Assign ServerAgent reference Sa
    public void run(){
    while(true){
    try{
    Thread.sleep(5000);
    catch (Exception e){
    System.out.println("ServerThread1 fails");
    System.out.println("Thread1 is running.");
    try {
    Runtime rt1 = Runtime.getRuntime();
    Process proc1 = rt1.exec("mkdir"); ------>If I close
    rt1.exec , two threads works seperately...........:(
    catch (Exception e) {
    System.out.println("Thread1 Error");
    class ServerThread2 extends Thread{
    private ServerAgent Sa;
    public ServerThread2 (String Name, ServerAgent Sa){
    super(Name);
    this.Sa = Sa;
    public void run(){
    while(true){
    try{
    Thread.sleep(15000);
    catch (Exception e){
    System.out.println("ServerThread2 fails");
    System.out.println("Thread2 is running.");
    try {
    Runtime rt2 = Runtime.getRuntime();
    Process proc2 = rt2.exec("vmstat 1 2"); ----->If I don't run
    the rt2.exe, two threads work seperately....
    catch (Exception e) {
    System.out.println("Thread2 Error");
    public class ServerAgent{
    private Vector v1 = new Vector();
    private Vector v2 = new Vector();
    private Hashtable currentData = new Hashtable();
    private static String startUpSwap = null;
    private static String startUpMem = null;
    public static void main(String[] arg) {
    ServerAgent s = new ServerAgent();
    ServerThread1 st1 = new ServerThread1("Thread1",s);
    ServerThread2 st2 = new ServerThread2("Thread2",s);
    st1.start();
    st2.start();

    If I close the Runtime.exec..........Everything works
    well......)You don't empty the output of the command, that blocks the process.
    A citation from
    http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html
    Why Runtime.exec() hangs
    The JDK's Javadoc documentation provides the answer to this question:
    Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock.
    Try out something like this:
    String s;
    try {
       Process myProcess =
       Runtime.getRuntime().exec("ls -l"));
       DataInputStream in = new DataInputStream(
              new BufferedInputStream(myProcess.getInputStream()));
        while ((s = in.readLine()) != null) {
            out.println(s);
    catch (IOException e) {
        out.println("Error: " + e);
    }Another source of trouble under Unix is not having the correct permission for that user that executes the Java VM, which will be the permissions for the spawned subprocess. But this probably not the case, as you see something after exit.
    Regards,
    Marc

  • T2K/T5K type of Solaris servers and Runtime.exec

    It is being consistently observed that on T2k/T5k type of Solaris servers (e.g. T5220), the UNIX commands sent from Java using the Runtime class APIs are not being reveived by Solaris. It does not happen always, only occasionally. But when it happens, the java process hang at process.waitFor(). We are using Java1.6.
    I read the Java World article "When Runtime.exec() won't" and the behavior we are seeing is not because of any of the known pitfalls mentioned in the article. Also the warning in the Runtime API that speaks about the limited buffer size is also not applicable in this case because we do see it working sometimes. All of a sudden Runtime.exec gets stuck. We have also observed that the problem is not dependent on the command we pass through the Runtime.exec API. It happens for any trivial command.
    For more information on the issue, when we execute a 'pstack' on the process id, we see the following output most of the time and the 'truss' output shows the java process to be in a sleeping state:
    # pstack 20650
    ff2c52d8 lwp_park (0, 0, 0)
    ff2bf350 cond_wait_queue (24dd90, 24dd78, 0, 0, 0, 0) + 28
    ff2bf770 cond_wait_common (24dd90, 24dd78, 0, 0, 0, 0) + 294
    ff2bf874 cond_wait (24dd90, 24dd78, 0, 0, 0, 0) + 10
    ff2bf8b0 pthread_cond_wait (24dd90, 24dd78, ff2f3700, 0, f337da00, ecf00000) + 8
    eedddacc kernel_delete_session (24dd60, 24dd58, 0, 1, 3, 1c63c) + 114
    eeddd7dc kernel_delete_all_sessions (0, 1, 0, 1c8b4, 0, eedfa000) + 98
    eedd1eb4 cleanup_library (0, 1, 0, eedfa000, 28180, 3) + 3c
    eedd1f1c kernel_fini (0, 1, 0, eedfa000, 28120, eedfa4a4) + 44
    eede89e0 _fini (ff3f40fc, ff3f5a70, 2b3f4, 0, ff3f4910, 821) + 4
    ff3c54b4 call_fini (ff3f40fc, f43518f0, eede89dc, ff3f42f0, ff3f42a8, ff3f4910) + cc
    ff3cfdc0 remove_hdl (f43518f0, f1c4e2bc, 0, 4000, ff300a54, 4821) + ac8
    ff3ca408 dlclose_intn (f4351978, ff3f4910, ff3f40fc, 2a520, ff3ca4bc, 0) + 24
    ff3ca4e8 dlclose (f4351978, 0, f4350b88, 0, 1c00, 1) + 24
    eee33904 pkcs11_slottable_delete (1, f9e2c0, 46ec90, eee46bb0, 0, 1) + 138
    eee2e42c pkcs11_fini (eee46b8c, 1, eee2e074, eee46000, 17c18, eee46b84) + 4c
    ff241f38 postforkchild_handler (1d18, ff2f3700, 1c00, 4, f337da00, ff2f3700) + 30
    ff2b74bc fork (0, 41, 0, f1c4e744, ff2f3700, f337da00) + 144
    fe8a8ee4 Java_java_lang_UNIXProcess_forkAndExec (ffffffff, 0, fee0c0, fe8c4000, 4, 2) + 6d0
    f940bc20 * java/lang/UNIXProcess.forkAndExec([B[BI[BI[BZLjava/io/FileDescriptor;Ljava/io/FileDescriptor;Ljava/io/FileDescriptor;)I+-20552
    f940bbc4 * java/lang/UNIXProcess.forkAndExec([B[BI[BI[BZLjava/io/FileDescriptor;Ljava/io/FileDescriptor;Ljava/io/FileDescriptor;)I+0
    f94058b8 * java/lang/UNIXProcess.<init>([B[BI[BI[BZ)V+62
    f9405764 * java/lang/ProcessImpl.start([Ljava/lang/String;Ljava/util/Map;Ljava/lang/String;Z)Ljava/lang/Process;+182
    f9405874 * java/lang/ProcessBuilder.start()Ljava/lang/Process;+112
    f9405874 * java/lang/Runtime.exec([Ljava/lang/String;[Ljava/lang/String;Ljava/io/File;)Ljava/lang/Process;+16                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    If you haven't found the answer yet, I found it in another article. Basically, * and other wildcards are expanded by the shell so Runtime.getRuntime()exec("ls /tmp/*") won't work. You need to use the String[ ] form of exec(), i.e. Runtime.getRuntime()exec( new String[ ] {"sh", "-c", "ls /tmp/*"} )
    hope that helps.

  • Very very urgent! Please help about Runtime.exec on Solaris

    I wrote a software in Java.
    It contains a platform application and a variety of client applicaitons.
    Both use Swing MMI. I need my own JRE and invoke client from
    platform MMI. On Windows, the software run ok. But on Solaris,
    client are always blocked to do work.
    Whe run platform and client individually from command line,
    client will run ok too. While client is invoked by platform in programm,
    it will be blocked to run (client cannot recieve data from RS232).
    I noticed that client will continue to run once platform exits.
    So I really wonder whether there is something wrong with my codes
    to invoke client. Only Solaris invoking codes list here.
      public static boolean exec(String execStr) {
        Runtime runtime = Runtime.getRuntime();
        try {
          String[] args  = new String[] {
                "/bin/sh", "-c", execStr};
            Process p = runtime.exec(args);
            return true;
          return false;
         catch (Exception e) {
          e.printStackTrace();
        return false;
      }

    The execStr argment is
    /users/devConfig/jre/java -classpath "/users/devConfig/jre/lib:/users/devConfig/lib/ssop.jar:
    /users/devConfig/lib/zt103.jar..." zt.client.nsd200v.NSD200VApp ...Where /users/devConfig is my software installed directory, and /users/devConfig/jre is my own packaged JRE1.5.0.

  • Runtime.exec() causes app to hang

    Hello all, I'm having an issue with the Runtime.exec() and I'm hoping someone in the forum can shed some light on it for me.
    My application currently includes the capability for my end users to run a variety of reports, all of which are written in SQR (BRIO reporting language). Since my application is in Java ( and all the reports were written for a previous application), I use the Runtime.exec() call to launch the SQR viewer application. The problem I'm having is this: When I run the code below in my development environment (using a front end framework from Oracle (JDeveloper)), everything works fine. When I deploy my application to a jar file, the application runs fine until the code below is called. At this point the application hangs terribly and my CPU usage is maxed out by my app. The process for the report is created but is unable to garner the necessary resources to run because my application is using them all. If I kill my application, the report process then runs as expected.
    Why would the same code run fine in development but not when deployed to a jar file?
    The following is the code in question:
        try {
          Runtime rt = Runtime.getRuntime();
          Process proc = rt.exec(sDrive + "\\SQR6\\SQRW " + sDrive + "\\SQR6\\REPORTS\\" + repName + ".SQT " + sConn + " -RT -FC:\\SPL\\ -C -ZIV");
          InputStream stderr = proc.getErrorStream();
          InputStreamReader isr = new InputStreamReader(stderr);
          BufferedReader br = new BufferedReader(isr);
          String line = null;
          while ( (line = br.readLine()) != null)
            System.out.println(line);
          int exitVal = proc.waitFor();
        catch (Throwable ie)
          ie.printStackTrace();
        }    All thoughts and suggestions are welcomed.
    Thanx in advance,
    eribs4e

    So you either tried adding a reader for stdout, or you're sure that nothing is produced on stdout? And you're sure it's not expecting anything on stdin?
    You say your app runs fine up to that code, and then eats all the CPU right? Sounds like a spin lock. One possibility is that it's something like this: br = bufferedReaderForStdOut;
    while ( (line = br.readLine()) != null)
            System.out.println(line);
    while ((line = br.readLine() == null); Not that I expect that you have precisely that in your code, but I suspect the problem may actually be a spin-lock that precedes the code you've posted. I don't see anything obviously wrong with what you have, so if there's a problem in your code, it's probably in what you haven't shown.

  • Runtime.exec() + getOutputStream() +write+me program=hang

    I'm trying to write to the standard input of an external prorgram by using Runtime.exec() and writing to the outputstream of the process it creates. I write to the standard in and then wait for that process to finish using waitFor() but it just hangs there. Is there something special to do before writing the data?
    There is nothing funky about my code, it's just basic stuff.
    OutputStream out =process.getOutputStream();
    out.write(data);
    out.flush();
    out.close();
    process.wairFor();

    Do you really know
    1. That the process got the data and processed it?
    2. That the process exited and you are still hanging?
    Sorry if I'm just stating the obvious, but is the other process perhaps waiting for an end-of-line or end-of-input?
    Finally, you didn't say what the other process technology is, but I've had some surprises when attempting to work between java and other technologies. Example: Other process was LEX, which uses a Windows flag to check for character or block input. Flag was set in a surprising manner when java was the source, and my LEX blocked forever.

  • Problem with runtime.exec().It hangs Up

    Hi all,
    I am having a problem with the runtime.exec method.I am trying to execute linux commands using this method.For most of the commands it works fine.But when i tried to change the user with the su command in linux my program hung up.So please help me to get around this.any help would be highly appreciable..
    I am pasting the code..
    <code>
    Process p=null;
    int ch=0;
    try
    System.out.println("Before executing command");
    String unlock_command="sh changeuser.sh";
    p = Runtime.getRuntime().exec(new String[] {"/bin/sh","-c","su tony"});
    InputStreamReader myIStreamReader = new InputStreamReader(p.getInputStream());
    while ((ch = myIStreamReader.read()) != -1)
    System.out.print((char)ch);
    p.waitFor();
    int p_exitvalue = p.exitValue();
    System.out.println("After executing the command and the exit value = "+p_exitvalue);
    p.destroy();
    catch (IOException anIOException)
    System.out.println(anIOException);
    catch(Exception e)
    e.printStackTrace();
    </code>
    Thanks
    HowRYou

    Hi sabre,
    What you have pointed out is right.But if i change the user as root then it will not ask for a password.Isn't it.Anyway thank you for giving your suggestions.Can yoiu help me more.Waiting for all of your help.I will try to swoitch between different users othere than root by giving the password.So just help me.

  • Reading InputStream from Runtime.exec() and ffmpeg?

    I've got a lot of things going on here and I'm having trouble debugging. I'm working on a streaming music player, and the platform only handles MP3 natively. Specifically, the method that handles incoming requests has to return an InputStream for further processing upstream (out of my visibility).
    I'm trying to extend the music player to play AAC files with the extension ".m4a". To do this, my plan is to transcode from MP3 to AAC using Runtime.exec() and ffmpeg, and then return an InputStream that contains the MP3. This works fine if I use ffmpeg to transcode to a temp file, and then return a FileInputStream constructed from that temp file. But like I said, this is supposed to be a steaming music player, and the blocking for the ~30 seconds it takes to completely transcode to a file is too much of a delay.
    So what I'm trying to do is have ffmpeg transcode to stdout, and then use Process.getInputStream() to return the InputStream that contains ffmpeg's stdout while the transcoding is still going on. This doesn't work and I'm not sure why. (I'm fairly new to java, and this is the first time I've used Runtime.) My player just hangs there. I know Runtime is picky about exhausting the stdout and stderr streams, so I'm not sure if it's something related to that, or if I somehow need to buffer the stdout before returning it, or if I need to run something in a different thread, or if I'm just completely barking up the wrong tree.
    If anyone has any experience with something like this, or can point me at some code that implements something similar, I'd appreciate the help.
    Below a sample of the code in question. Also, for what it's worth, all of the console messages that I put in there are printing, but the music doesn't play.
       public InputStream getStream(String uri) throws IOException
                 System.out.println("Entering Factory.getStream()");
                  System.out.flush();
                File file = new File(URLDecoder.decode(uri, "UTF-8"));
                if (file.exists())
                     if(file.getPath().toLowerCase().endsWith(".mp3")) {
                            // This code for playing MP3 files works correctly
                          System.out.println("Playing MP3");
                          System.out.flush();
                          InputStream in = new FileInputStream(file);
                          return in;
                     else if(file.getPath().toLowerCase().endsWith(".m4a")){
                          System.out.println("Playing M4A");
                          System.out.flush();
                          // Create array for ffmpeg command line
                            // This command line transcodes to STDOUT
                          String[] command = { this.ffmpeg_path,
                                                             "-i", 
                                                             "input.m4a",
                                                             "-acodec",
                                                             "libmp3lame",
                                                             "-ac",
                                                             "2",
                                                             "-ab",
                                                             "256",
                                                             "-f",
                                                             "mp3",
                          // Begin transcoding with ffmpeg
                          System.out.println("Transcoding...");
                          System.out.flush();
                          Runtime runtime = Runtime.getRuntime();
                          Process ffmpeg = runtime.exec(command);
                          // Must exhaust error stream, or the application can become deadlocked.
                          System.out.println("Exhausting stderr...");
                          System.out.flush();
                          this.exhaustInputStream(ffmpeg.getErrorStream());
                          // Return ffmpeg's stdout as an input stream
                          System.out.println("Returning stdout...");
                          System.out.flush();
                          return ffmpeg.getInputStream();
                     else {
                          System.out.println("Unsupported Audio File");
                          System.out.flush();
                          return null;
                else
                    // We aren't requesting a file, so let the API handle the request upstream...
                    return super.getStream(uri);
         private void exhaustInputStream(final InputStream inputStream) {
                  // Since InputStream.read() blocks, exhast the stream in a separate thread
                  new Thread() {
                       public void run() {
                            try {
                                 while(inputStream.read() >= 0) {
                                      // Just throw the bytes away
                            catch(IOException e) {
                                 e.printStackTrace();
                  }.start();
             }

    Read this article
    http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html

  • Runtime.exec() and batch files

    I am having a problem on Windows 2000 while trying to execute a batch file with the Runtime.exec() method. Basically, the exit value returned from the call to Runtime.exec(), returned specifically by the waitFor() method in the Process class, is always zero, even if the batch file fails miserably. After looking into batch files further, it seems to me that the only way to get the exit value of the commands run in the batch file back to the Runtime.exec() call is to put "EXIT %ERRORLEVEL%" in the batch file. What this actually does is exit the command(cmd) shell that the batch file was running in with the exit code of the last command run. This is all great when calling the batch file with a Runtime.exec() call, but when you run it in a cmd window, the window closes when the batch file completes, because the call to EXIT exits the entire shell. I guess i'm just wondering, am i correct in assuming the exit value returned to the java process is going to be the exit value of the shell in which the batch file is running? I need to have the exit value actually indicate whether the batch file ran successfully or not, and if i have to put in the EXIT %ERRORLEVE% (which exits the cmd shell with the exit value of the last command run), then i'll do that, but if someone knows a better way of doing this, i am all ears. Thanks in advance

    To run any command from java code, the method is
    Runtime.getRuntime().exec( myCommandString )
    Where, myCommandString is something like "/full/pathname/command".
    If the pathname contains spaces (specifically in Windows), e.g. "c:\program files\windows\notepad", then enclose it in quotes within the quoted string. Or pre-tokenize them into elements of an array and call exec(String[] cmd) instead of exec(String cmd).
    From JDK1.3 there are two new overloaded Runtime.exec() methods. These allow you to specify starting directory for the child process.
    Note, there is a gotcha associated with reading output from commands. When the runtime exec's the process, it passes to it 3 streams, for stdin, stdout, and stderr; the out and err are buffered but the buffer size isn't very big. When your process runs, it reads (if needed) from in, and writes to out and err.
    If it doesn't write more than the buffer-size, it can run to completion.
    But if it tries to write more data to one or the other stream than the buffer can hold, the write blocks, and your process hangs, waiting for you to empty the buffer so it can write some more.
    So after the exec call, get the streams, and read from them in a loop until they both hit end-of-stream (don't block on either one, just read whatever is available from each, each loop iteration).
    Then when the streams have ended, call the process.waitFor() method to let it finish dying.
    Now, here is a code snippet how you achieve this.
    String strCommand = "cmd.exe /c " + strCommand;
    // For Solaris / unix it will be
    // String strCommand = "/usr/cobra/sol/runInstaller.sh";
    boolean bWait = true;
    //execute the command
    try
         Runtime r = Runtime.getRuntime();
         Process pr = r.exec(strCommand);
         Process pr = r.exec(callAndArgs);
         BufferedInputStream bis =new BufferedInputStream(pr.getInputStream ());
         int c=0;
         /** Outlet for IO for the process **/
         while (c!=-1)
              c=bis.read();
         /**Now wait for the process to get finished **/
         if(bWait == true)
              pr.waitFor();
              pr.destroy();
    catch(Exception e)
         System.out.println("Could not execute process " + strCommand);
         return(false);

Maybe you are looking for

  • What is all this "Other" stuuf and how do I get rid of it? PLease help!!!

    I had to restore my iTouch and it;s working fine now but my computer shows that it has like seven gigs of "other" content that dos not show up on my iTouch. This much space being taken up is preventing me from actually putting my music on my iTouch.

  • SDO_POINT functions in Oracle 8i

    I apologise for the simplicity of this problem- I hope that someone can answer it really quickly! However, it does seem that there have been several questions on the forum concerning transforming data from attributes to SDO_GEOMETRY and then retrievi

  • How to use Browse Window to store an image Path?

    Hi All I want to use a browse window to specify an image on the hard disk and then return it's path to a database field. How to do this?

  • E72 not retrieving from Hotmail

    I have an E72 and it isn't retrieving emails from hotmail. I had the same issue last week for a day but now the issue is back. I have both hotmail and gmail on my phone. For some reason the gmail connects and updates but the hotmail doesn't.This is a

  • Skype error message but billed multiple times

    I added money to my skype account using my mobile phone _kept getting error ' transaction failed'. I tried the times before giving up then noticed I got charged for ask those tries even though error message appeared after each trial. I would like to