Runtime.exec(), so much fun

I'm at the bang your head on the monitor stage of this.
I have some executables written in C that I need to be able to executed. They require an input file for processing and generate an output file with results, no big deal.
They both run great from a command prompt. (I'm running on linux with j2sdk1.3.0 by the way)
Now if I call one of them with Runtime.exec(), it runs perfectly as expected. Everything goes in, Everything comes out, Everyone is happy.
If I call the other, It says it runs, I get an exit value of 0, the output file is created, but empty.
I thought I could open a shell with Runtime and then try to get it to run from there to see if it would make any difference, but I was unable to get the shell to call the executables to run with the arguments for input. There is something weird with the way Runtime feeds the strings to the shell. I tried a couple variations.
Then I thought, what the hell, I wonder if I can write a shell script that calls the executables and see what I get from there. So I wrote a little script that just calls the executable with one little hard coded input, just to see if it would run. Run the script from a command prompt, works great and as expected. Try to call the simple little script from Runtime.exec() and I get a segmentation fault.
At this point, I'm almost giving up on an easy answer for what in theory should be taking a few lines of code.
If anybody has a clue on how to approach this or what might be causing this, please let me know.
for the whole saga
http://www.javaranch.com/ubb/Forum13/HTML/000198.html
http://www.javaranch.com/ubb/Forum34/HTML/001360.html
Any response here would be appreciated.

I guess clicking on links and reading is too much to
ask.I admit I didn't read the thread there. Shame on me.
But i did this litle test.
Here I have a C program that reads from a file two numbers and writes some lines to another. The names are passed in command line.
#include <stdio.h>
#define NAME "[first test program]"
int main(int argn, char** args) {
  FILE* in = NULL;
  FILE* out = NULL;
  int exitCode = 0;
  int nLoops = 0;
  int nSec = 0;
  int i;
  if(argn < 3) {
    fprintf(stderr, "%s usage: %s inFile outFile\n", NAME, args[0]);
    exitCode = 1;
    goto _exit;
  in=fopen(args[1], "rt");
  if(in == NULL) {
    fprintf(stderr, "%s Cannot open file %s\n", NAME, args[1]);
    exitCode = 2;
    goto _exit;
  out=fopen(args[2], "wt");
  if(out == NULL) {
    exitCode = 2;
    goto _exit;
  fscanf(in, "%d", &nLoops);
  fprintf(stdout, "%s read %d loops from %s\n", NAME, nLoops, args[1]);
  fflush(stdout);
  fscanf(in, "%d", &nSec);
  fprintf(stdout, "%s read %d seconds to sleep from %s\n", NAME, nSec, args[1]);
  fflush(stdout);
  for(i=0; i<nLoops; i++) {
    fprintf(stdout, "%s try to write line %d on %s ... ", NAME, i, args[2]);
    fflush(stdout);
    sleep(nSec);
    fprintf(out, "%s line number %d\n", NAME, i);
    fprintf(stdout, "done\n");
    fflush(stdout);
  fflush(out);
_exit:
  if(in != NULL) fclose(in);
  if(out != NULL) fclose(out);
  return exitCode;
}I created an executable c1 and the I modified the NAME and created another executable c2.
The I wrote a small java test class :
import java.io.*;
public class test {
    public static void main(String[] args) {
     String[] cmd1 = { "./c1", "input1", "out1" };
     String[] cmd2 = { "./c2", "input2", "out2" };
     Runtime r = Runtime.getRuntime();
     try {
         Process p1 = r.exec(cmd1);
         Process p2 = r.exec(cmd2);
         BufferedReader r1 =
          new BufferedReader(new InputStreamReader(p1.getInputStream()));
         BufferedReader r2 =
          new BufferedReader(new InputStreamReader(p2.getInputStream()));
         String l1 = r1.readLine();
         String l2 = r2.readLine();
         while(l1!=null || l2!=null) {
          if(l1 != null) System.out.println("from java proc 1:\t" + l1);
          if(l2 != null) System.out.println("from java proc 2:\t" + l2);
          l1 = r1.readLine();
          l2 = r2.readLine();
     } catch (Exception ex) {
         ex.printStackTrace();
}The imput files contains on a single line the number of lines to write on the output file and a sleep time between lines, like:
100 1This test runs fine on my linux box.
I have a RedHat 7.0 on a PIII, kernel 2.2.16-22 .
You can try and see if it is working on your box. I think it will. My guess is that the problem is somehow on the second c program.
I didn't read the other thread, so maybe the answer is there, but I'll ask: the problem is with a specific program, or allways happen with the second that you run?
Anyway, it will be nice if you can isolate the problem in three small source files and send them here.
Regards,
Iulian

Similar Messages

  • Any ideas why Runtime.exec() w/ 1.4.0 works but doesn't w/ 1.4.1

    I have developed a program which uses Runtime.exec(). It works in development but not in the production.
    The development machine runs Windows2000 with SDK 1.4.0.
    This program does not run on the target machine (production). The target machine is a Windows2000 servers with JRE 1.4.1_01.
    Here is the error:
    java.io.IOException: CreateProcess:
    "C:\Program Files\2TIFF\2TIFF.EXE"
    "s=C:\SplitTiff\pet.tif"
    "d=D:\SplitTiffWork"
    -namegen=123456.tif
    -sep
    -ct3
    error=3
    at java.lang.Win32Process.create(Native Method)
    at java.lang.Win32Process.<init>(Unknown Source)
    at java.lang.Runtime.execInternal(Native Method)
    at java.lang.Runtime.exec(Unknown Source)
    at java.lang.Runtime.exec(Unknown Source)
    at java.lang.Runtime.exec(Unknown Source)
    at utility.splitTiff.SplitTiff.extract(SplitTiff.java:54)
    at utility.splitTiff.SplitTiff.main(SplitTiff.java:340)
    The six lines following "Create Process:" are the elements of the String[] parm of Runtime.exec().
    Error 3 was returned by the JRE.
    Does anyone have any suggestions what is going on?
    Thanks much! I've got some Dukes to give out for some help on this.
    Bill Blalock

    Thanks!
    Where can I find out the meaning of errors returned by Runtime.exec()?
    Please reply to
    http://forum.java.sun.com/thread.jsp?forum=54&thread=291993
    And I'll send a couple a Duke I have locked up over there your way.
    Have a good weekend!!!

  • Start a new java process using Runtime.Exec() seems to ignore the -Xmx

    I am working with a process that requires a minimum of 1.5 GB to run and works better if more is available.
    So I am determining how much memory is available at startup and restarting the jre by calling
    Runtime.exec("java -Dcom.sun.management.jmxremote=true -Xmx1500M -jar XXX.jar")
    which reinvokes the same process with a new max memory size.
    The initial call to the process is
    java -Dcom.sun.management.jmxremote=true -Xmx3500M -jar XXX.jar
    The initial call returns 3262251008 from Runtime.maxmemory()
    When reinvoked through Runtime.exec() as above
    Runtime.maxmemory() still returns 3262251008
    Is there a way to separate the new process from the size specified by the parent process?

    That is strange. Here is a program I wrote which calls itself recursively.
    import java.io.IOException;
    import java.io.InputStream;
    import java.util.List;
    import java.util.ArrayList;
    import static java.util.Arrays.asList;
    public class MemorySize {
        public static void main(String... args) throws IOException, InterruptedException {
            System.out.println("Maximum memory size= "+Runtime.getRuntime().maxMemory());
            if (args.length == 0) return;
            List<String> cmd = new ArrayList<String>();
            cmd.add("java");
            cmd.add("-cp");
            cmd.add(System.getProperty("java.class.path"));
            cmd.add("-Xmx"+args[0]+'m');
            cmd.add("MemorySize");
            cmd.addAll(asList(args).subList(1,args.length));
            Process p = new ProcessBuilder(cmd).start();
            readin(p.getErrorStream());
            readin(p.getInputStream());
        private static void readin(final InputStream in) {
            new Thread(new Runnable() {
                public void run() {
                    try {
                        byte[] bytes = new byte[1024];
                        int len;
                        while((len = in.read(bytes))>0)
                            System.out.write(bytes, 0, len);
                        in.close();
                    } catch (IOException e) {
                        e.printStackTrace();
            }).start();
    }If you run this with the args 128 96 33 222 it prints out
    Maximum memory size= 66650112
    Maximum memory size= 133234688
    Maximum memory size= 99942400
    Maximum memory size= 35389440
    Maximum memory size= 231014400

  • Strange behavior when using Runtime.exec() to run batch file

    I've been struggling with this for hours.
    I have a Swing application which upon clicking a button, I want to execute a batch file. This batch file itself uses a command window.
    When I use
    Runtime load = Runtime.getRuntime();
    load.exec("cmd /c start c:\\renew\\renew2\\bin\\win\\renew.bat");
    The program (Renew) will start up no problem, but when I exit Renew, the command window stays put. I want the command window to close. Running Renew stand-alone, upon closing Renew, it will exit the command window.
    When I use
    Runtime load = Runtime.getRuntime();
    load.exec("cmd /c c:\\renew\\renew2\\bin\\win\\renew.bat");
    or
    Runtime load = Runtime.getRuntime();
    load.exec("c:\\renew\\renew2\\bin\\win\\renew.bat");
    When I press the button, sometimes the Renew application will come up right away, sometimes the Renew application will come up after a very long delay, and most times, the Renew application will only come up after I have closed the Swing frame where the button is located. When I use this code, the command window that Renew uses is never visible.
    What I want is to simply have the Renew application behave the same exact way launching from my Swing application as when Renew is being run standalone.
    Any suggestions? Thanks so much.
    Sincerely,
    Will

    Getting rid of start makes the startup time very variable. Sometimes it starts up right away, sometimes after many minutes, most times only after I close my application.
    Thanks, Any other suggestions?
    (BTW, I have read the famous "When Runtime.exec() won't" article, and have tried its suggestions to no avail)
    Message was edited by:
    willies777

  • Runtime.exec error in windows

    When i try to run an external program with Runtime.exec() in windows 2000, i get a windows pop-up with the following error msg:
    d:\winnt\system32\ntvdm.exe
    Error while setting up environment for the application.
    I have no idea how to fix this since i have no clue to what that error means.
    Thanks
    Rumy

    I've personally just encountered the same error. I am building a piece of demonstration software to distribute with my graduate school applications to demonstrate my programming experience and I wish to include a set of programs I wrote some years ago in Pascal and C++. The software has been compiled for MS-DOS 6.0. I am using the following command to execute the software from within my Java program:
    Runtime.getRuntime().exec(new String[]{"command.com","/c","12cards.bat"});The batch file performs the appropriate setup operations for the program and runs the executable. When I run this code segment, I receive the following error:
    [16 bit MS-DOS Subsystem]
    C:\WINNT\system32\ntvdm.exe
    Error while setting up environment for the application. Choose 'Close' to terminate the application.
    I have another code segment in which I attempt to run the executable myself (without the help of command.com or the batch file). The code segment is as follows:
    Runtime.getRuntime().exec(new String[]{"12cards.exe"}, new String[0], workingDir);When I run this code segment, the following IOException is thrown:
    java.io.IOException: CreateProcess: 12CARDS.EXE error=2
         at java.lang.Win32Process.create(Native Method)
         at java.lang.Win32Process.<init>(Win32Process.java:66)
         at java.lang.Runtime.execInternal(Native Method)
         at java.lang.Runtime.exec(Runtime.java:566)
         at (my code)I have already found the document on Microsoft's support website which describes a solution to this problem. Manually extracting the autoexec.nt, config.nt, and command.com files from the installation CD-ROM did not help.
    The most confusing element of this: 12CARDS.EXE runs fine if I execute it from Windows Explorer. It's only a problem if it's executed from within my Java program. I have two other DOS programs which I want to include as well; I am having the same trouble with them.
    Any advice will be much appreciated. Thanks!

  • Question about Runtime.exec

    Rob,
    Thanks for your help.
    I asked a question about a weird Exception on Nov 14, and you told me that I am
    using Runtime.exec to start an external process, and that process is crashing.
    I am a green-hand on Weblogic, and I am trying to enhancing a project developped
    by another person, so I am not familiar with some concepts yet.
    Could you please give me some simple explanation about Runtime.exec and external
    process?
    I found two methods that uses "Runtime" from two classes as following, could you
    help me to see whether or not there is something wrong with the usage of Runtime?
    Thank you very much.
    private int runShellCommand(String command) {
    int exitVal = -1;
    try {
    File runDir = new File(runDirectory);
    String[] env = new String[0];
    Runtime rt = Runtime.getRuntime();
                   double start = System.currentTimeMillis();
    Process proc = rt.exec(command, env, runDir);
    // Capture output in separate thread
    ThreadedStreamReader error = new ThreadedStreamReader(proc.getErrorStream(),
    "ERROR");
    ThreadedStreamReader output = new ThreadedStreamReader(proc.getInputStream(),
    "OUTPUT");
    error.start();
    output.start();
    exitVal = proc.waitFor();
    if (logger.isDebugEnabled()) {
         double runtime = (System.currentTimeMillis() - start) / 1000.0;
         logger.info("run " + runId + " " + command + " finished in " + runtime
    + " seconds");
    } catch (IOException e) {
    logger.fatal("DOE-2 failed \n" + e.getMessage());
    } catch (InterruptedException e) {
    e.printStackTrace();
    return exitVal;
    public static void main(String[] args) throws Exception, InterruptedException
    final Doe2MessageServer server = new Doe2MessageServer();
    while(!connected) {
    Thread.sleep(1000);
    logger.info("Attempting to start JMS service ...");
                   try {
              server.init();
                   } catch (Exception ex) {
    // shutdown hook to close JMS connection
    Runtime.getRuntime().addShutdownHook(
    new Thread() {
    public void run() {
    server.finalize();
    server.receiveMessage();

    Runtime.exec is a J2SE API. It's not really specific to WLS.
    You can read about it here:
    http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Runtime.html
    It looks like you are starting a JMS Server in a separate process and
    that process is crashing.
    (You could of course just use WLS's JMS Server instead :>)
    -- Rob
    Iris Qu wrote:
    Rob,
    Thanks for your help.
    I asked a question about a weird Exception on Nov 14, and you told me that I am
    using Runtime.exec to start an external process, and that process is crashing.
    I am a green-hand on Weblogic, and I am trying to enhancing a project developped
    by another person, so I am not familiar with some concepts yet.
    Could you please give me some simple explanation about Runtime.exec and external
    process?
    I found two methods that uses "Runtime" from two classes as following, could you
    help me to see whether or not there is something wrong with the usage of Runtime?
    Thank you very much.
    private int runShellCommand(String command) {
    int exitVal = -1;
    try {
    File runDir = new File(runDirectory);
    String[] env = new String[0];
    Runtime rt = Runtime.getRuntime();
                   double start = System.currentTimeMillis();
    Process proc = rt.exec(command, env, runDir);
    // Capture output in separate thread
    ThreadedStreamReader error = new ThreadedStreamReader(proc.getErrorStream(),
    "ERROR");
    ThreadedStreamReader output = new ThreadedStreamReader(proc.getInputStream(),
    "OUTPUT");
    error.start();
    output.start();
    exitVal = proc.waitFor();
    if (logger.isDebugEnabled()) {
         double runtime = (System.currentTimeMillis() - start) / 1000.0;
         logger.info("run " + runId + " " + command + " finished in " + runtime
    + " seconds");
    } catch (IOException e) {
    logger.fatal("DOE-2 failed \n" + e.getMessage());
    } catch (InterruptedException e) {
    e.printStackTrace();
    return exitVal;
    public static void main(String[] args) throws Exception, InterruptedException
    final Doe2MessageServer server = new Doe2MessageServer();
    while(!connected) {
    Thread.sleep(1000);
    logger.info("Attempting to start JMS service ...");
                   try {
              server.init();
                   } catch (Exception ex) {
    // shutdown hook to close JMS connection
    Runtime.getRuntime().addShutdownHook(
    new Thread() {
    public void run() {
    server.finalize();
    server.receiveMessage();

  • Launch Acrobat Reader with Runtime.exec() under WINNT4, without absolut pat

    Hi,
    I would like to launch Acrobat Reader from a Swing application. This works fine with Runtime.exec() as long as I provide the full path to the AcroRd32.exe. The problem is that I cannot predict the location of this exe on the systems of the users. Athough is in the Windows PATH, since I can launch from the windows execute-dialog, the Runtime.exec() is not able to locate the file.
    How can I solve this problem?
    Thanks a lot!
    Horst

    hey BIJ, thank you so much man. start really does wonders!! i was stuck with invoking a fortran program for last couple of days and now i went through your postings and tried with start. it did work!!
    thanks again,
    bhairampally

  • To jschell How to get data System properties by JNI and Runtime.exec()

    Thank you very much for answer. ummm....but I'm can not gets data system properties by JNI or Runtime.exec(). Please help me. I'm want create Java-Applet for data System properties ( memory quantity?, Harddisk capacity?, CPU speed ?, Printer Name? and all hardwares ) in my computer. It very important for me. Help me please. thank you..

    Java applets are restricted to accessing only some system properties - and it is good so. I would not be happy if any applet could inquire about, say, my user name or the amount of memory in my box.

  • 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

  • Running ftp from runtime exec()

    How would I run ftp from exec()? Can I run a script that is ftping from exec()? Why would anyone go through the trouble of writing their own ftp code, if you can just call a script from the exec() method? I am going to be running ftp from a servlet to send a file to a mainframe, where it will run and create an xml file that the servlet will then post to the screen. should I be using java's ftp commands, or will my script way work fine?
    Thanks

    How would I run ftp from exec()?Like any other program. It would be good to read the article http://www.javaworld.com/jw-12-2000/jw-1229-traps.html first to get it right the first time.
    Can I run a script that is ftping from exec()?I don't see any objections.
    Why would anyone go
    through the trouble of writing their own ftp code, if
    you can just call a script from the exec() method?Good question. 1) you are making your application platform dependent by using a platform depenent program 2) Runtime.exec() can't be used in applets but ftp over a socket connection is possible 3) There are already good packages for it (eg. at www.fooware.com) written for it so you don't need to write anything yourself (and 4: just because it's fun!)
    I am going to be running ftp from a servlet to send a
    file to a mainframe, where it will run and create an
    xml file that the servlet will then post to the
    screen. should I be using java's ftp commands, or
    will my script way work fine?
    If you have a working script and you know you will work on only one platform calling a script with exec will be just fine.

  • Runtime.exec since Java 1.7.0_21

    Since the last update to JRE 1.7.0_21 the following windows system command
    no longer works with Runtime.exec:
    cmd /c dir /p [Directory-Path] > [File-Path]
    Both '[Directory-Path]' and '[File-Path]' contains no spaces.
    Has anyone an idea how to solve this problem ?

    gimbal2 wrote:
    sabre150 wrote:
    correctly according to the 'traps' article cited by 'gymbal' . Oi. I know my nickname is terrible but no need to make it worse, 'cybre'.:-) I quite like 'cybre'. I think I will change may handle!
    >
    I still find it mysterious that it apparently did in fact work. Given your excellent description it should have never ever worked.Ultimately the exec() gets delegated to one of the Windows exec???() 'C' library methods (I can't remember which) and these seem to be poor version of the Unix/Linux implementations. I have seen the silliest commands work on Windows JRE that should not have worked. Fortunately, since I now pretty much exclusively work with *Nix, I usually don't have to live with it!                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Runtime exec IOException issues

    Hello,
    I have spent two 10 hours days on this problem with countless search permutations and peering into everything from kernel source to java source. Unfortunately, I am not coming up with useful results.
    Overview:
    I have a very large java application (Apache solr) running on a server with 12GB memory. Without going into too much detail, this application at a point will use a Runtime exec call to fire off a bash shell script. Over time, however, I end up with an IOException "Cannot allocate memory." (More info and stack trace below.)
    That application aside I have been able to reproduce this by varying the -Xms and -Xmx jvm parameters with confusing results using the simple program below:
    //Use with various -Xms and -Xmx arguments to produce
    //IOException on call to Runtime.exec()
    import java.io.*;
    public class DoRuntime {
       public static void main(String args[]) throws IOException {
          Runtime runtime = Runtime.getRuntime();
          long total = runtime.totalMemory();
          long max = runtime.maxMemory();
          long free = runtime.freeMemory();
          System.out.println("total: " + total);
          System.out.println("max: " + max);
          System.out.println("free: " + free);
          Process process = runtime.exec("/bin/ls");
          InputStream is = process.getInputStream();
          InputStreamReader isr = new InputStreamReader(is);
          BufferedReader br = new BufferedReader(isr);
          String line;
          while ((line = br.readLine()) != null) {
             System.out.println(line);
    }Here are some sample runs:
    RUN1
    rwoodrum@util1wad:~/tmp$ java DoRuntime
    total: 188743680
    max: 954466304
    free: 187759312
    DoRuntime.class
    DoRuntime.java
    rwoodrum@util1wad:~/tmp$
    RUN2
    rwoodrum@util1wad:~/tmp$ java -Xms10g -Xmx10g DoRuntime
    total: 10290069504
    max: 10290069504
    free: 10236381080
    Exception in thread "main" java.io.IOException: java.io.IOException: Cannot allocate memory
            at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
            at java.lang.ProcessImpl.start(ProcessImpl.java:65)
            at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
            at java.lang.Runtime.exec(Runtime.java:591)
            at java.lang.Runtime.exec(Runtime.java:429)
            at java.lang.Runtime.exec(Runtime.java:326)
            at DoRuntime.main(DoRuntime.java:14)
    rwoodrum@util1wad:~/tmp$
    RUN3
    rwoodrum@util1wad:~/tmp$ java -Xms10g -Xmx11g DoRuntime
    total: 10290069504
    max: 10498867200
    free: 10236381080
    DoRuntime.class
    DoRuntime.java
    rwoodrum@util1wad:~/tmp$-----
    (FWIW, I get the same results replacing /bin/ls with something as lightweight as /bin/true.)
    As can be seen in the above output of RUN2, I have set a fixed heap size of 10GB. The jvm seems content with that heap size, but when it goes to exec the child process it becomes rather unhappy. From this I would perhaps conclude that ultimately inside the call to forkAndExec (libjava.so) the call to fork() failed with an ENOMEM. (As a side note, an strace on the process doesn't actually ever show a fork, only a call to clone - which utilizes a fork eventually - more on clone below.)
    The results of RUN3, however, seem to imply that the problem is within the jvm itself. In RUN3, I set the initial heap allocation to 10GB, as in RUN2, but I set the maximum at 11GB. One would think (or at least I would) that if the fork in RUN2 failed that it would certainly fail in the case of RUN3. It doesn't.
    The manpage of clone indicates that the child process will "share parts of its execution context with the calling process". Indeed, if I'm reading it correctly, it indicates that the child process stack (among other things) is housed in the parent process address space.
    Could it be that by setting this very large, fixed heap size as in RUN2, there is no room for the jvm to "maneuver" and properly handle the effort of the Runtime.exec? The fact that RUN3 is successful is what has made me think something like this, but I am by far an expert on how the jvm would handle that sort of thing.
    In our production setup of this application, I adjusted the Xmx setting to be something larger than the Xms setting. This worked for a period of time, but eventually produced the same results. I suspect over time the heap simply increased toward the max and again the jvm couldn't do its thing when it came time to RunTime.exec. The fact that this happens on the trivial Runtime.exec program would seem to rule out a memory leak of the production application.
    Ultimately something fishy is going on with memory, but with seemingly contradictory results, I am at a loss of where the problem lies.
    If I have omittied any potentially relevant information, please let me know. Any thoughts are greatly appreciated.
    Some basic system information:
    rwoodrum@util1wad:~/tmp$ free
                 total       used       free     shared    buffers     cached
    Mem:      12304936   12200376     104560          0     337276    7082508
    -/+ buffers/cache:    4780592    7524344
    Swap:      2097144         32    2097112
    rwoodrum@util1wad:~/tmp$ uname -a
    Linux util1wad 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53 CEST 2007 x86_64 GNU/Linux
    rwoodrum@util1wad:~/tmp$ java -version
    java version "1.5.0_10"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
    Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_10-b03, mixed mode)-ryan woodrum

    I've continued to investigate this with my discoveries below. I've found some more interesting nuances, but am still not satisfied with the explanation of what is going on here. For time reasons, I've capitulated to a somewhat lame workaround.
    The test run in the 1.6.0 jvm environment is somewhat revealing in that it confirms that the eventual call to fork (I'm kind of guessing it's the fork call here) is returning an ENOMEM. The 1.5.0 jvm was not returning the actual errno from the call in the JNI code. Checking out $linux_src/include/asm-generic/errno-base.h indeed enumerates ENOMEM to 12.
    When I saw this, I started looking at the memory commit inside of /proc/meminfo to see what was going on when I would launch the jvm with the varying Xmx and Xms parameters. Somewhat unsurprisingly at this point, when I would run with large a large heap, the Committed_AS would skyrocket by a proportion roughly equal to the fixed heap size. (See here http://lwn.net/Articles/28345/ for an definition of Committed_AS and other /proc/meminfo fields.)
    With the above information in hand, I wanted to confirm without a doubt that the kernel was the thorn in my side. So on a test system I started to play around with the vm_overcommit feature - see $linux_src/Documentation/vm/overcommit-accounting for definitions of modes 0,1, and 2). Sure enough, toying with these modes I was able to alter the behavior of launching the jvm. I switched from the default heuristic mode (0) to an "always overcommit" mode and it would launch and sucessfully fork and exec every time. No surprise there.
    What IS surprising, however, is that if, under the default heuristic mode, I specify the jvm parameters differently it will sucessfully run and fork and exec the subprocess. It seems odd to me that at the OS level, specifying `java -Xms4g -Xmx4g` will cause the subprocess fork to fail but specifying `java -Xms4g -Xmx5g` will NOT cause the fork to fail. Running with the latter parameters shows the exact same Committed_AS spike. This all begs the question(s): What's the difference? With a min heap size set to 4g (or whatever) on the both jvm runs, how does a jvm parameter (especially one that allows MORE growth of the heap) impact this call to fork? One variable in the picture at this point that I'm unsure of is the strace call to clone(). I don't know what this could be doing to make things behave differently.
    So as I noted, above, I have a relatively lame workaround. Blindly add more swap to increase the CommittedLimit inside the kernel. It'll never get used, it's a waste of space, and, perhaps most importantly, on principal it just rubs me the wrong way.
    -ryan woodrum

  • Difference between command line and Runtime.exec()

    Hi all.
    I'm coding some lines to call sqlldr program.
    System info:
    OS: Win2k server
    Java platform: JSK 1.4
    DBMS: Oracle 9i
    I've tested sqlldr in command line and it is OK. But when i call Runtime.exec("sqlldr user/pass@servicename control=mycontrol.ctl")
    the ErrorStream show that: Message 2100 not found,No message file for product=RDBMS ,facility=UL...
    So i had to put a String array which contained "ORACLE_HOME" as the second parameter of exec method. But there's another error appear:
    SQL*Loader-704: Internal error: ulconnect: OCIServerAttach [0]
    ORA-12560: TNS:protocol adapter error
    I checked tnsnames.ora and it's OK. I do the command line again and it's still OK. Why did Runtime.exec("...") method get Error.
    Does Someone solve it for me.
    Thanks so much.

    I'm having the similar/same issue.
    I'm trying to run SQLLdr from JAVA.
    From a command line, it works fine.. From within JAVA, I get..
    SQL*Loader-704: Internal error: ulconnect: OCIServerAttach [0]
    ORA-12640: Authentication adapter initialization failed.
    Did you find a solution to your problem?

  • Runtime.exec input problem

    Hi
    My requirement is, run the command using Runtime.exec(), and provide the input "Y"/"N" and get the output of the command and process .
    I am able to give the input to Runtime.exec() and get the output of the command.
    To provide input to Runtime.exec() I am using as follows
    String input="Y";
    out.write(input.getBytes()); ( OutputStream of Runtime.exec() )
    out.flush();
    After providing input as above , i am able read the output of the command [ using InputStream.read() ],
    it works fine in Windows, Solaris, HP-UX IPF, In case of Linux(X86) or Linux IPF i am not able to read the output of the command.
    I analysed the problem and found that InputSream.read() call is blocked since input of the command not provided completely. then I did as follows,
    String input="Y"+Lineseperator
    out.write(input.getBytes()); ( OutputStream of Runtime.exec() )
    out.flush();
    Then it is working fine.....( I am able to get the output of the command)
    Plz help me what is background of this.

    Indeed, there are buffers involved both ways. The flush() should actually flush() the output buffer, at least so much as to shove the data into the other program. But if this other program reads input line by line, than it will not take notice of the data until the end-of-line marker is also received. Some old software is buggy enough to even ignore the last line of input if it is not properly terminated by an end-of-line marker, so a close() without preceeding end-of-line may not work.
    In general, controlling some program by feeding its input and reading its output can be quite tricky. Flushing first and then checking for input in a single thread may block, if some buffer size is too small.
    Harald.

  • Runtime.exec failure in applet(IE and Netscape)

    Hi
    Runtime.exec() failures to execute an executable(VB) in an Applet with Internet Explorer and Netscape Navigator. But the same is working fine with Mozilla Firefox and Opera. All the four browsers can load the applet successfully and listens the Swing component's action by actionlistener. But the problem is that IE and Netscape cant execute a VB created executable. The sample code of failure part is:
    public void actionPerformed(java.awt.event.ActionEvent e){
    Runtime.getRuntime().exec(abc.exe);
    Here abc.exe is a VB exe for doing simple thing.
    Plz help me on it if anyone knows about it..................
    Raz
    Message was edited by:
    rashidul

    hi,
    1st: 40MB is maybe a little bit too much :-)
    2nd swing is not really good for applets and espicially not for IE
    regards

Maybe you are looking for

  • How to install Windows 7 Enterprise using Bootcamp ?

    Hi, I'd like to install Windows 7 entreprise edition on a macbook pro 15" Early 2011 using Lions latest version. I have an orginal CD and also an ISO file. I tried this: - insert the original DVD, start bootcamp, downloaded the drivers and restarted

  • Hyperlink to open a file in a new window

    I have been trying to format the hyperlink to a file so it opens on a new window. iWeb allows us to check the box 'open in new window' only for links to external pages; when we insert a link to a file, I realize the app uploads the file to the websit

  • Net Price aggregated in BW

    Hi Mates,     I do not understand why is 2LIS_02_ITM giving me the wrong value of 0NETPRICE( NETPR )    In my ECC Purchase Order:, I have  line items as following     So, why does the Line Item 12 aggregate the Net Price to 54.95 ?

  • Can not get pictures to email

    Why will adobe not let me email my pictures? But I can purchase my already owned pictures? Is this program a big scam to get people to purchase their own pictures from shutterfly or some other for PROFIT business! Why did I purchase adobe if I have t

  • Data objects in Unicode cannot be converted dump

    Hi experts, I am using a Custom business object which if run independently throws no error. We are upgrading 4.6 to ECC 6.0.It is unicode active. The Business object contains methods for displaying a scanned document from IXOS server. On executing wo