Process core dumps when spawned by Runtime.exec()

I am using a Runtime.exec() command to spawn a local executable process on HP-UX. The local process (C++ executable) starts and is functional, though at a certain point during operation, the process creates a segmentation fault and core dumps. If the same process is spawned manully from a shell, this does not occur.
The process cores at the same point every time (a call to free+ in the system libC library). I have duplicated as much of my shell environment in the Runtime.exec() call as possible. Also, this issue does not occur on AIX or Linux (ports of my code to those platforms).
What is the fundimental difference between spawning a process from a shell V.S. the JVM spawning the process that could cause this difference in behavior?
java version "1.4.2.07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2.07-050121-15:53)
Java HotSpot(TM) Server VM (build 1.4.2 1.4.2.07-050121-17:30-PA_RISC2.0 PA2.0 (aCC_AP), mixed mode)

We are currently having the same problem, it is killing us.
We have upgraded to jdk 1.6u16 and still have the problem.
We think it is related to sparc platform we had been running for some time with same code on X86 server
Our solaris release is: Solaris 10 11/06 s10s_u3wos_10 SPARC
We can't get a reproducible small test case. It is getting us most often when the JVM running our
appserver uses the Runtime.getRuntime().exec(cmd);
We are jumping through hoops looking for workaround. We are trying to write a command server that can
have the command sent through a socket and have all the ouput sent back over the same socket.
That way the app server JVM is not the one doing the fork and exec.

Similar Messages

  • Core Dump when calling DriverManager.getConnection

    I'm very confused and hope someone can help me out with this.
    I'm trying to make a connection to a MS SQL Server 7 and am getting a core dump when getConnection is called. No exception is thrown, just a core dump and locked session. If I run the class from it's main there is absolutly no problem, but when I do a new on the class and call it's member to establish the connection: core dump. The environment is the same in both cases. The calling class did does use a mySql connection, but I tried closing it and setting it to null with the same problem. I'm not sure if the getConnection is stepping on a socket or what it's trying to violate in memory causing the dump. This is running on a SCO Openserver 5.0.5 box (green threads). Why it runs stand-alone and not when called from another class has got me tangled... Thread problem? I've tried several SQL drivers, they all do the same thing.
    Anyway, here's a snippet from the java class:
    try
    {Class.forName(myForName);
    // core dump, next line
    Connection myConn = DriverManager.getConnection(myUrl, myUser, myPass);
    // never get's here
    Statement myStmt = myConn.createStatement();
    catch (Exception e) // modified for this post
    {system.out.println(e.toString());
    Here's the dump printed to the monitor (2>&1)
    SIGSEGV 11* segmentation violation
    si_signo [11]: SIGSEGV 11* segmentation violation
    si_errno [0]: Error 0
    si_code [1]: SEGV_MAPERR [addr: 0x8]
         stackpointer=81adc820
    Full thread dump Classic VM (SCO-JDK-1.2.2-001:2000-Feb-17-03:54, green threads):
    "Thread-0" (TID:0x8074f3c8, sys_thread_t:0x83ae258, state:R) prio=5
         at com.inet.tds.TdsDriver.run(Unknown Source)
         at java.lang.Thread.run(Thread.java, Compiled Code)
    "process reaper" (TID:0x807431d0, sys_thread_t:0x82cd980, state:CW) prio=5
         at java.lang.Object.wait(Native Method)
         at java.lang.UNIXProcess.run(Native Method)
         at java.lang.Thread.run(Thread.java, Compiled Code)
    "Finalizer" (TID:0x8071f320, sys_thread_t:0x808e478, state:CW) prio=8
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174)
    "Reference Handler" (TID:0x8071f3b0, sys_thread_t:0x808a2d8, state:CW) prio=10
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java, Compiled Code)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114)
    "Signal dispatcher" (TID:0x8071f3e0, sys_thread_t:0x80845a8, state:CW) prio=5
    "main" (TID:0x8071f1e0, sys_thread_t:0x804c2d8, state:R) prio=5
         at java.lang.Thread.sleep(Native Method)
         at com.inet.tds.TdsDriver.connect(Unknown Source)
         at java.sql.DriverManager.getConnection(DriverManager.java, Compiled Code)
         at java.sql.DriverManager.getConnection(DriverManager.java, Compiled Code)
         at SLSCorpRpt.printSchedule(SLSCorpRpt.java, Compiled Code)
         at SLSSchedule.runSchedule(SLSSchedule.java, Compiled Code)
         at SLSTextMain.<init>(SLSTextMain.java, Compiled Code)
         at SLSTextMain.main(SLSTextMain.java, Compiled Code)
    Monitor Cache Dump:
    java.lang.Object@807431A8/807C6140: <unowned>
         Waiting to be notified:
         "process reaper" (0x82cd980)
    java.lang.Class@80736EF8/807970A8: owner "main" (0x804c2d8) 2 entries
    <unknown key> (0x80737c21): owner "Thread-0" (0x83ae258) 1 entry
    java.lang.ref.ReferenceQueue$Lock@8071F338/80754D60: <unowned>
         Waiting to be notified:
         "Finalizer" (0x808e478)
    java.lang.ref.Reference$Lock@8071F3C0/80754890: <unowned>
         Waiting to be notified:
         "Reference Handler" (0x808a2d8)
    Registered Monitor Dump:
    PCMap lock: <unowned>
    utf8 hash table: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: owner "Thread-0" (0x83ae258) 1 entry
    Class linking lock: <unowned>
    System class loader lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Monitor cache lock: owner "Thread-0" (0x83ae258) 1 entry
    Monitor IO lock: <unowned>
    User signal monitor: <unowned>
         Waiting to be notified:
         "Signal dispatcher" (0x80845a8)
    Child death monitor: <unowned>
    I/O monitor: <unowned>
    Alarm monitor: <unowned>
         Waiting to be notified:
         <unknown thread> (0x804be18)
    Thread queue lock: owner "Thread-0" (0x83ae258) 1 entry
    Monitor registry: owner "Thread-0" (0x83ae258) 1 entry
    SIGABRT 6* abort (generated by abort(3) routine)
         stackpointer=81adc820
    Full thread dump Classic VM (SCO-JDK-1.2.2-001:2000-Feb-17-03:54, green threads):
    "Thread-0" (TID:0x8074f3c8, sys_thread_t:0x83ae258, state:R) prio=5
         at com.inet.tds.TdsDriver.run(Unknown Source)
         at java.lang.Thread.run(Thread.java, Compiled Code)
    "process reaper" (TID:0x807431d0, sys_thread_t:0x82cd980, state:CW) prio=5
         at java.lang.Object.wait(Native Method)
         at java.lang.UNIXProcess.run(Native Method)
         at java.lang.Thread.run(Thread.java, Compiled Code)
    "Finalizer" (TID:0x8071f320, sys_thread_t:0x808e478, state:CW) prio=8
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174)
    "Reference Handler" (TID:0x8071f3b0, sys_thread_t:0x808a2d8, state:CW) prio=10
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java, Compiled Code)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114)
    "Signal dispatcher" (TID:0x8071f3e0, sys_thread_t:0x80845a8, state:CW) prio=5
    "main" (TID:0x8071f1e0, sys_thread_t:0x804c2d8, state:R) prio=5
         at java.lang.Thread.sleep(Native Method)
         at com.inet.tds.TdsDriver.connect(Unknown Source)
         at java.sql.DriverManager.getConnection(DriverManager.java, Compiled Code)
         at java.sql.DriverManager.getConnection(DriverManager.java, Compiled Code)
         at SLSCorpRpt.printSchedule(SLSCorpRpt.java, Compiled Code)
         at SLSSchedule.runSchedule(SLSSchedule.java, Compiled Code)
         at SLSTextMain.<init>(SLSTextMain.java, Compiled Code)
         at SLSTextMain.main(SLSTextMain.java, Compiled Code)
    Monitor Cache Dump:
    java.lang.Object@807431A8/807C6140: <unowned>
         Waiting to be notified:
         "process reaper" (0x82cd980)
    java.lang.Class@80736EF8/807970A8: owner "main" (0x804c2d8) 2 entries
    <unknown key> (0x80737c21): owner "Thread-0" (0x83ae258) 1 entry
    java.lang.ref.ReferenceQueue$Lock@8071F338/80754D60: <unowned>
         Waiting to be notified:
         "Finalizer" (0x808e478)
    java.lang.ref.Reference$Lock@8071F3C0/80754890: <unowned>
         Waiting to be notified:
         "Reference Handler" (0x808a2d8)
    Registered Monitor Dump:
    PCMap lock: <unowned>
    utf8 hash table: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: owner "Thread-0" (0x83ae258) 1 entry
    Class linking lock: <unowned>
    System class loader lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Monitor cache lock: owner "Thread-0" (0x83ae258) 1 entry
    Monitor IO lock: <unowned>
    User signal monitor: <unowned>
         Waiting to be notified:
         "Signal dispatcher" (0x80845a8)
    Child death monitor: <unowned>
    I/O monitor: <unowned>
    Alarm monitor: <unowned>
         Waiting to be notified:
         <unknown thread> (0x804be18)
    Thread queue lock: owner "Thread-0" (0x83ae258) 1 entry
    Monitor registry: owner "Thread-0" (0x83ae258) 1 entry

    I have a similar problem with establishing a connection through JNI. Have you resolved your problem?
    Here's mine.
    In java, I have a class that provides an interface to a mysql database. The java programs that call this interface work fine.
    When I try to call the java interface from C++ through JNI, I get the following output -- some debug statements sprinkled through also. I am assuming that the JVM is missing something at runtime that is there in my JRE. The classpaths match , etc. Exception handling in java and in JNI code are not providing any more detail.. Thanks for comments!!
    Created jvm
    Got KBModel and String classes
    KBModel.java:stest()
    KBModel.java:init(String)
    KBModel.java:init(String) - got Properties file
    Got DBDRIVER class: org.gjt.mm.mysql.Driver
    Object = class org.gjt.mm.mysql.Driver
    init(): DBURLSTRING = jdbc:mysql://sturgeon.xxx.com:3306/<valid db name>
    init(): DBUSER = <valid user>
    init(): DBPASSWORD =<valid password>
    KBModel.java:init(Properties) - Attempting connection
    init(): Drivers available:
    com.mysql.jdbc.Driver
    Driver accepts this URL
    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : 11 occurred at PC=0x4053ea09
    Function name=(N/A)
    Library=/lib/i686/libc.so.6
    NOTE: We are unable to locate the function name symbol for the error
    just occurred. Please refer to release documentation for possible
    reason and solutions.
    Dynamic libraries:
    08048000-0804a000 r-xp 00000000 03:02 279279 /home/kathy/cm/src/Onto/Tools/Annotator/src/test/invokeKB
    0804a000-0804b000 rw-p 00001000 03:02 279279 /home/kathy/cm/src/Onto/Tools/Annotator/src/test/invokeKB
    40000000-40016000 r-xp 00000000 03:02 2093075 /lib/ld-2.2.4.so
    40016000-40017000 rw-p 00015000 03:02 2093075 /lib/ld-2.2.4.so
    40017000-40020000 r-xp 00000000 03:02 1309343 /usr/java/jdk1.3.1_03/jre/lib/i386/native_threads/libhpi.so
    40020000-40021000 rw-p 00008000 03:02 1309343 /usr/java/jdk1.3.1_03/jre/lib/i386/native_threads/libhpi.so
    40031000-40032000 r--p 00000000 03:02 768548 /usr/lib/locale/en_US/LC_IDENTIFICATION
    40033000-40085000 r-xp 00000000 03:02 328384 /usr/lib/libodbc.so.1.0.0
    40085000-40088000 rw-p 00051000 03:02 328384 /usr/lib/libodbc.so.1.0.0
    40088000-400c1000 r-xp 00000000 03:02 327275 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
    400c1000-400c8000 rw-p 00038000 03:02 327275 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
    400ca000-400eb000 r-xp 00000000 03:02 246620 /usr/java/jdk1.3.1_03/jre/lib/i386/libjava.so
    400eb000-400ed000 rw-p 00020000 03:02 246620 /usr/java/jdk1.3.1_03/jre/lib/i386/libjava.so
    400ee000-400ff000 r-xp 00000000 03:02 246629 /usr/java/jdk1.3.1_03/jre/lib/i386/libverify.so
    400ff000-40101000 rw-p 00010000 03:02 246629 /usr/java/jdk1.3.1_03/jre/lib/i386/libverify.so
    40101000-402f1000 r-xp 00000000 03:02 1701922 /usr/java/jdk1.3.1_03/jre/lib/i386/client/libjvm.so
    402f1000-403f1000 rw-p 001ef000 03:02 1701922 /usr/java/jdk1.3.1_03/jre/lib/i386/client/libjvm.so
    40408000-4053c000 r-xp 00000000 03:02 2093084 /lib/libc-2.2.4.so
    4053c000-40542000 rw-p 00133000 03:02 2093084 /lib/libc-2.2.4.so
    40547000-4054a000 r-xp 00000000 03:02 2093088 /lib/libdl-2.2.4.so
    4054a000-4054b000 rw-p 00002000 03:02 2093088 /lib/libdl-2.2.4.so
    4054b000-40558000 r-xp 00000000 03:02 343415 /lib/i686/libpthread-0.9.so
    40558000-40560000 rw-p 0000c000 03:02 343415 /lib/i686/libpthread-0.9.so
    40560000-40582000 r-xp 00000000 03:02 343413 /lib/i686/libm-2.2.4.so
    40582000-40583000 rw-p 00021000 03:02 343413 /lib/i686/libm-2.2.4.so
    40583000-40596000 r-xp 00000000 03:02 2093093 /lib/libnsl-2.2.4.so
    40596000-40597000 rw-p 00012000 03:02 2093093 /lib/libnsl-2.2.4.so
    40599000-405cd000 r-xp 00000000 03:02 328243 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
    405cd000-405d9000 rw-p 00033000 03:02 328243 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
    405dc000-405f0000 r-xp 00000000 03:02 246630 /usr/java/jdk1.3.1_03/jre/lib/i386/libzip.so
    405f0000-405f3000 rw-p 00013000 03:02 246630 /usr/java/jdk1.3.1_03/jre/lib/i386/libzip.so
    405f3000-41327000 r--s 00000000 03:02 1717328 /usr/java/jdk1.3.1_03/jre/lib/rt.jar
    41354000-4164b000 r--s 00000000 03:02 1717321 /usr/java/jdk1.3.1_03/jre/lib/i18n.jar
    4164b000-41661000 r--s 00000000 03:02 1717329 /usr/java/jdk1.3.1_03/jre/lib/sunrsasign.jar
    43709000-4370a000 r--p 00000000 03:02 408823 /usr/lib/locale/en_US/LC_MEASUREMENT
    4370a000-4370b000 r--p 00000000 03:02 2158478 /usr/lib/locale/en_US/LC_TELEPHONE
    4370b000-4370c000 r--p 00000000 03:02 2158480 /usr/lib/locale/en_US/LC_ADDRESS
    4370c000-4370d000 r--p 00000000 03:02 2158479 /usr/lib/locale/en_US/LC_NAME
    4370d000-4370e000 r--p 00000000 03:02 1864168 /usr/lib/locale/en_US/LC_PAPER
    4370e000-4370f000 r--p 00000000 03:02 2174846 /usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES
    4370f000-43710000 r--p 00000000 03:02 408822 /usr/lib/locale/en_US/LC_MONETARY
    49d5f000-49d8a000 r--p 00000000 03:02 572342 /usr/lib/locale/en_US/LC_CTYPE
    49d8a000-49d90000 r--p 00000000 03:02 866674 /usr/lib/locale/en_US/LC_COLLATE
    49d90000-49d91000 r--p 00000000 03:02 768549 /usr/lib/locale/en_US/LC_TIME
    49d91000-49d92000 r--p 00000000 03:02 572338 /usr/lib/locale/en_US/LC_NUMERIC
    49d93000-49d9c000 r-xp 00000000 03:02 246627 /usr/java/jdk1.3.1_03/jre/lib/i386/libnet.so
    49d9c000-49d9d000 rw-p 00008000 03:02 246627 /usr/java/jdk1.3.1_03/jre/lib/i386/libnet.so
    49d9d000-49da7000 r-xp 00000000 03:02 2093117 /lib/libnss_nisplus-2.2.4.so
    49da7000-49da8000 rw-p 00009000 03:02 2093117 /lib/libnss_nisplus-2.2.4.so
    49da8000-49dab000 r-xp 00000000 03:02 2093106 /lib/libnss_dns-2.2.4.so
    49dab000-49dac000 rw-p 00002000 03:02 2093106 /lib/libnss_dns-2.2.4.so
    49dad000-49db7000 r-xp 00000000 03:02 2093109 /lib/libnss_files-2.2.4.so
    49db7000-49db8000 rw-p 00009000 03:02 2093109 /lib/libnss_files-2.2.4.so
    4a624000-4a67a000 r--s 00000000 03:02 540401 /usr/java/jdk1.3.1_03/jre/lib/ext/log4j-1.2.6.jar
    4a695000-4a6a3000 r-xp 00000000 03:02 2093122 /lib/libresolv-2.2.4.so
    4a6a3000-4a6a5000 rw-p 0000d000 03:02 2093122 /lib/libresolv-2.2.4.so
    Local Time = Thu Feb 13 13:35:05 2003
    Elapsed Time = 1
    # The exception above was detected in native code outside the VM
    # Java VM: Java HotSpot(TM) Client VM (1.3.1_03-b03 mixed mode)
    # An error report file has been saved as hs_err_pid9210.log.
    # Please refer to the file for further information.
    #

  • Snmpdemo core dump when sending traps

    Hi,
    I am investigating the SEA SNMP toolkit on Solaris x86 7 & 8. I applied the recommended patches on both of my systems. Everything worked fine except the traps.
    I modified the mib_demo.txt by adding a test trap definition:
    myTestTrap TRAP-TYPE
    ENTERPRISE demo
    VARIABLES {
    demoEntryInteger
    DESCRIPTION "This is a test trap."
    ::= 2
    Then I used mibcodgen to generate the code, and modified agent_loop() in snmpdemo_appl.c to let it send the trap in every agent_loop. It compiled okay, but it core dumped when it ran into SSASendTrap3(...) in snmpdemotrap.c. The _SSASendTrap3 looks like a SDK function that I have no clue how it processes inside.
    I noticed if I change "demoEntryInteger" into "demoInteger" - to change the variable(s) from table attribute(s) to non-table attribute(s), and followed the same build process, the snmpdemod worked fine - I was able to get the traps on the destination host without core dump.
    I discovered this problem several weeks ago on Solaris 7, and now I found the same on Solaris 8.
    I think it is quite common for a subagent to bind some variables to the enterprise-specific traps. And the variables can be attributes of a talbe entry. And this is exactly the case of the subagent which I am going to work on.
    Any clue? Could it be a SDK defect? Or is there any newer patch which has already fixed this problem?
    Or any way to hack _SSASendTrap3 so that I can get around it?
    Thanks a lot!
    Wen

    It works by using _SSASendTrap4( char *, IndexType * )
    instead of _SSASendTrap3( char * ).How?
    _SSASendTrap(char *, IndexType *) long-jumps into oblivion whenever I try it. Can someone please provide an example?                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • I want to know why display core dump when arch starts!

    I want to know why display core dump when arch starts!
    2008. 06 iso!
    u can see display coredump in starting......

    GAH, you silly people!
    Now I'm going to have to go off and write a program that selects a random string from a file to show on startup!
    (I'll probably fill the file with all the Arch snapshot names)
    EDIT: I should mention that you're silly because you managed to get me following a random compulsion.
    EDIT AGAIN: Done! I now get a random snapshot name in that spot whenever my system boots. I can post the script if anyone wants it, it's three lines.
    EDIT ONE LAST TIME: Oh wait, three lines and a extra file full of snapshot names.
    Last edited by arew264 (2008-07-19 02:35:05)

  • Tuxedo8 core dumps when performing a tpcall in Solaris

    Hi all,
    I'm installing a Tuxedo application on a Solaris OS:
    SunOS 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R
    Tuxedo 8.0 compiled under 32bits libraries.
    This application also runs correctly under a RedHat Linux 7.1 (kernel 2.4.9-31)
    and on a Digital (OSF1 V4.0 878 alpha)
    When running the application on Solaris, we always get a core dump when the service
    performs a tpcall. Debugging the Tuxedo server we can see the core dump is produced
    when the service gets de response from the tpcall, i.e: when the service called
    performs the tpreturn.
    Any clues will be appreciated, thanks!
    Yol.

    Oh, thanks very much, what a stupid mistake! sorry :(
    We knew about the cast, but after looking for the problem in many ways we didn't
    realize FLDLEN was a short!
    Thank you all for your quick help!
    Yol.
    Scott Orshan <[email protected]> wrote:
    FLDLEN nLongitud is a short. Casting its pointer to a long * does not
    change the
    fact that the return value will overwrite other memory. On Linux, the
    alignment or
    arrangement of the stack was different, so it didn't core dump. You need
    to pass
    the address of a real long for the return length.
         Scott Orshan
    Yol. wrote:
    Yes, that's what we thought at first sight, nevertheless remember itruns ok in
    other OS.
    Anyway here I give you 2 samples of code we've tried.
    Any of this cases fail creating a core dump.
    Case 1:
    Src1 calls Src2:
    Src1:
    void SRC1(TPSVCINFO * BufferFml)
    FLDLEN nLongitud;
    FBFR *pBuffer;
    pBuffer = (FBFR *) BufferFml->data;
    if (tpcall("SRC2", (char *) pBuffer, 0, (char **) &pBuffer, (long*) &nLongitud,
    0) == -1)
    userlog("Error!!!!!!!!!!!!!!!!!");
    tpreturn(TPSUCCESS, 0, (char *) pBuffer, 0L, 0);
    Src2
    void SRC2(TPSVCINFO * BufferFml)
    FLDLEN nLongitud;
    FBFR *pBuffer;
    pBuffer = (FBFR *) BufferFml->data;
    tpreturn(TPSUCCESS, 0, (char *) pBuffer, 0L, 0);
    Case 2:
    Src1 calls Src2:
    Src1:
    The same as in case 1
    Src2:
    void SRC2(TPSVCINFO * BufferFml)
    tpreturn(TPSUCCESS, 0, NULL, 0L, 0);
    Thanks anyway for your attention ;-)
    Peter Holditch <[email protected]> wrote:
    Yol,
    My initial guess is that your code is not keeping track of the tpalloced
    buffers correctly - in particular, the one that the reply is received
    into.
    If you post some code, maybe someone will see the error. Alternatively,
    have you got purift or some other bounds checking software that might
    help you track the problem?
    Regards,
    Peter.
    Yol. wrote:
    Hi all,
    I'm installing a Tuxedo application on a Solaris OS:
    SunOS 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R
    Tuxedo 8.0 compiled under 32bits libraries.
    This application also runs correctly under a RedHat Linux 7.1 (kernel2.4.9-31)
    and on a Digital (OSF1 V4.0 878 alpha)
    When running the application on Solaris, we always get a core dumpwhen the service
    performs a tpcall. Debugging the Tuxedo server we can see the coredump is produced
    when the service gets de response from the tpcall, i.e: when the servicecalled
    performs the tpreturn.
    Any clues will be appreciated, thanks!
    Yol.

  • Getting core dump when using EXEC SQL CLOSE

    In my pro*c program , i have used a cursor to fetch the set of accounts.Once cursor is opened , code will perform set
    of operation using fetched data and then cursor is closed. Between open and closing of cursor , i have used 23 EXEC
    SQL CLOSE. For example i am copying the value of a to b using strlcpy between fetch and close cursor statement.If
    returned value from strlcpy is greater than size of destination variable, then flow should not proceed , in that case I will
    close the cursor using EXEC SQL CLOSE and return the flow to calling program. Similarly i have closed the cursor at
    another 22 locations.
    When i compile the code and run binary the core dump occurs. On analyzing the core it shows
    t@null (l@8) terminated by signal SEGV (no mapping at the fault address)
    0xffffffffffffffff: <bad address 0xffffffffffffffff>
    dbx: core file read error: address 0xfc4ffe48 not in data space
    Current function is dbMtBaseClass::Pswd_Change
    7860 sqlcxt(&_dbMtCtx, &sqlctx, &sqlstm, &sqlfpn);
    if I remove any of the three EXEC SQL CLOSE commands , core dump does not occurs.
    It looks strange.Please help me to resolve the issue.

    In my pro*c program , i have used a cursor to fetch the set of accounts.Once cursor is opened , code will perform set
    of operation using fetched data and then cursor is closed. Between open and closing of cursor , i have used 23 EXEC
    SQL CLOSE. For example i am copying the value of a to b using strlcpy between fetch and close cursor statement.If
    returned value from strlcpy is greater than size of destination variable, then flow should not proceed , in that case I will
    close the cursor using EXEC SQL CLOSE and return the flow to calling program. Similarly i have closed the cursor at
    another 22 locations.
    When i compile the code and run binary the core dump occurs. On analyzing the core it shows
    t@null (l@8) terminated by signal SEGV (no mapping at the fault address)
    0xffffffffffffffff: <bad address 0xffffffffffffffff>
    dbx: core file read error: address 0xfc4ffe48 not in data space
    Current function is dbMtBaseClass::Pswd_Change
    7860 sqlcxt(&_dbMtCtx, &sqlctx, &sqlstm, &sqlfpn);
    if I remove any of the three EXEC SQL CLOSE commands , core dump does not occurs.
    It looks strange.Please help me to resolve the issue.

  • Core dump when clearing vector of std::string/creating std:string

    Hi,
    I am seeing a couple of core dump which point to std::strings like the ones below. The application is a multi-threaded application and compiled on sun4u 5.8 sparc with Sun Studio 11 C++ compiler 5.8 Patch 121017-16. The stack trace is being shown from a shared library which we built and is being used by our daemon service. I stack traces points to code where simple operation like clearing of vector<std::string> or creating or erasing std::string. The runtime environment is Solaris 5.10 sun4u sparc with SUNWlibC patches of 119963-19 and 119963-10.
    We had an issue with clearing of vectors earlier whcih we solved by applying some compiler patches. This issue coming even after we have built the binaries with compiler patches. I have made sure that both the daemon and the shared library are all built with same compiler version. I would appreciate if any possible direction can be given for this.
    ======================1=================================
    $clibc.so.1`t_splay+0x10(82d828, 38, 753d736f, ff324c28, fe0b03a8, 732c6f3d)
    libc.so.1`realfree+0x8c(82d7e8, 39, d995c, fe7153a4, 0, 0)
    libc.so.1`_free_unlocked+0xb0(fe0b9224, 0, d9188, fe0b92a4, fe0b03a8, 555810)
    libc.so.1`free+0x24(555810, 555810, d91c8, fe041ebc, fe0b03a8, 555831)
    libCrun.so.1`void operator delete+4(555810, 0, 0, ffffffff, 59, 0)
    libCstd_isa.so.1`std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string #Nvariant 1+0x84(0, 555838, 2160c,
    555838, 38, 754b3c)
    ======================2=================================
    $clibc.so.1`t_splay+0xf4(590e78, 3b0, 6934c8, fdfd6eb0, fe0b03a8, 0)
    libc.so.1`realfree+0xb8(590e78, 5b, d995c, 0, 0, 5912b8)
    libc.so.1`cleanfree+0x5c(0, 19, d90ac, fe042230, fe0b03a8, fe0b92a4)
    libc.so.1`_malloc_unlocked+0xf4(8, 0, 0, fe29c734, fe0b3910, fe29c734)
    libc.so.1`malloc+0x4c(8, 1, da058, fe85eb20, fe0b03a8, fe0ba518)
    libCrun.so.1`void*operator new+0x28(8, 66c918, 7, fed6bf10, 14e98, 3afc38)
    ======================3=================================
    C [libc.so.1+0x57204] free+0x2c
    C [libCrun.so.1+0x665c] void operator delete(void*)+0xc
    C [libCstd_isa.so.1+0xd9ac]
    cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___Hreplace6MIIpkc
    III_pc_+0x120
    C [libCstd_isa.so.1+0x1a488]
    std::string &std::string::erase(unsigned,unsigned)+
    0x5c
    ======================4=================================
    C [libCstd_isa.so.1+0x119c8]
    cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___M__sun_append6M
    rk1_r1_+0x10
    ======================5=================================
    C [libc.so.1+0x5639c] malloc+0x54
    C [libCrun.so.1+0x70a4] void*operator new(unsigned)+0x30
    C [libCstd_isa.so.1+0xc69c]
    cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___I__getRep6MII_p
    nH__rwstdM__string_ref4Ccn0B_n0C____+0x60
    C [libCstd_isa.so.1+0xdad0]
    cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___Hreplace6MIIpkc
    III_pc_+0x1c0
    C [libCstd_isa.so.1+0xf5b4]
    std::string &std::string::operator=(const char*)+0x1
    08
    Edited by: bekz007 on Feb 24, 2010 1:55 PM

    Hi Clamage,
    The the application in question is built using various third party libraries and we will not be able to compile it with SunStudio 12. Even if we do that we may have to test for functionality which can be a major task now.
    Is there any other way in which I can proceed to verify this in client's env?
    Running the app in DBX didn't work as when the process was started it said
    dbx: internal warning: rtc: ld/st instruction user %r6 at 0xaca16840 in /opt/oracle/client102_1/lib32/libnnz10.so`SHATransform_SOL
    dbx: system error: cannont recover; Access checking disabledBelow give are the few stack traces we got recently and most of them are coming malloc
    -------------------------- Run3----------------------------------------------------
    fdfd710c t_splay  (590e78, 3b0, 6934c8, fdfd6eb0, fe0b03a8, 0) + f4
    fdfd6af0 realfree (590e78, 5b, d995c, 0, 0, 5912b8) + b8
    fdfd734c cleanfree (0, 19, d90ac, fe042230, fe0b03a8, fe0b92a4) + 5c
    fdfd64a4 _malloc_unlocked (8, 0, 0, fe29c734, fe0b3910, fe29c734) + f4
    fdfd6394 malloc   (8, 1, da058, fe85eb20, fe0b03a8, fe0ba518) + 4c
    fed5709c void*operator new(unsigned) (8, 66c918, 7, fed6bf10, 14e98, 3afc38) + 28
    fe713c78 bool Safe::Session::addAttr(const char*,const char*) (5f6478, fe831127, 7d0d50, fe856bd4, 0, fe831127) + 60
    fe69ac5c void Safe::Context::populateSession(Safe::Session*,Safe::GlobalUser*,Safe::User*,bool) (378400, 5f6478, 3afc38, fe8310ac, 1, fe831232) + e34
    fe699c58 void Safe::Context::populateSessionQs(std::deque<Safe::Session*>&,std::deque<Safe::Session*>&) (378400, 0, 378830, 2, fe856bd4, 0) + 15e0
    fe77cd64 void Safe::Cache::threadLoop() (3787e8, 378898, 378830, 0, 0, 0) + 54a4
    fe7762f4 ???????? (3787d0, 0, 0, fe856bd4, fdea5a00, 16800)
    fe7455d4 void*ithread_func(void*) (37a960, fe7762d8, fe856bd4, 0, 37a960, 1) + 48
    fe048968 _lwp_start (0, 0, 0, 0, 0, 0)
    -------------------------- Run4----------------------------------------------------
    fdf5710c t_splay  (659620, 58, 891658, fdfc0a2c, fe0303a8, 601200) + f4
    fdf56ac4 realfree (6595c0, 59, d995c, 0, 0, 71ad08) + 8c
    fdf5734c cleanfree (0, 7, d90ac, fed5631c, fe0303a8, fe0392a4) + 5c
    fdf564a4 _malloc_unlocked (798, 418, 4a52a8, 4a52b0, fffffffc, fd66d060) + f4
    fdf56394 malloc   (794, 1, da058, fe75d8b0, fe0303a8, fe03a518) + 4c
    fed5709c void*operator new(unsigned) (794, 6014a8, 6014a4, fed6bf10, 14e98, fe86ce2c) + 28
    fe68e650 bool Safe::Context::privSearchGlobalUsers(std::deque<Safe::Filter*>&,std::deque<Safe::GlobalUser*>&,Safe::Error&,bool) (193088, 9d7af8, fbb7a77c, fbb7a614, fbb7a4f4, 1) + 1e8
    fe6a5370 void Safe::Context::populateSessionQs(std::deque<Safe::Session*>&,std::deque<Safe::Session*>&) (193088, 19348c, 1934b8, 7858c4, fe86321c, 0) + 868
    fe7891f4 void Safe::Cache::threadLoop() (193470, 193520, 1934b8, 0, 0, 0) + 54a4
    fe782784 void*pollthreadfunc(void*) (193458, 0, 0, fe86321c, fde92a00, 16800) + 1c
    fe751a64 void*ithread_func(void*) (4525b0, fe782768, fe86321c, 0, 4525b0, 1) + 48
    fdfc8968 _lwp_start (0, 0, 0, 0, 0, 0)
    -------------------------- Run5----------------------------------------------------
    libc.so.1`malloc+0x4c(a, 1, da058, fd88c710, fe0303a8, fe03a518)
    libCrun.so.1`void*operator new+0x28(a, fb878177, 0, fec6bf10, 14e98, 3)
    libxerces-c.so.26`void*xercesc_2_6::MemoryManagerImpl::allocate+0x14(1c3e88, a, 55, fd9cea50, fda366e8, 1)
    libxerces-c.so.26`xercesc_2_6::XMLTranscoder::XMLTranscoder #Nvariant 1+0x60(fb877d20, fe874e52, 5, 1c3e88, 0, fffc00)
    libxerces-c.so.26`xercesc_2_6::XMLUTF8Transcoder::XMLUTF8Transcoder #Nvariant 1+0x20(fb877d20, fe874e52, 5, 1c3e88, 0, 0)
    libassafe_api.so`char*ispUtil::XMLChtoUTF8+0x4c(606c338, 67c, 400, fe86321c, 5, 1)
    libassafe_api.so`istring::istring #Nvariant 1+0x30(fb877f7c, fe86b470, fe86b448, fe86321c, 7a0, 400)
    libassafe_api.so`void ParseUtil::endElement+0xa0(c1f888, 693288, 606c338, fe86321c, 2, 2d4a160)
    libxerces-c.so.26`void xercesc_2_6::SAX2XMLReaderImpl::endElement+0x10c(876788, ece8e0, 1, fe875c80, 6043eb8, fe76d448)
    libxerces-c.so.26`void xercesc_2_6::IGXMLScanner::scanEndTag+0x644(5cb4628, fb878177, 0, fd9cea50, fd864978, 3)
    libxerces-c.so.26`bool xercesc_2_6::IGXMLScanner::scanContent+0x160(5cb4628, 0, 0, fd9fdb24, fd869d60, 1)
    libxerces-c.so.26`void xercesc_2_6::IGXMLScanner::scanDocument+0x78(5cb4628, 0, fd85dfb0, fd87214c, 1c3e88, 2800)
    libxerces-c.so.26`void xercesc_2_6::SAX2XMLReaderImpl::parse+0x8c(876788, fbf8d0, 4a, fe84a145, 0, 1c3e88)
    libassafe_api.so`bool ParseUtil::Parse+0x1c0(c1f888, 67c, fb878914, 16c82d0, fe86321c, fda348dc)
    libassafe_api.so`bool ispUtil::Parse+0x34(7fd350, fb878914, fe76ffc0, fe86321c, f320c, f3000)
    libassafe_api.so`void PozObject::poMapInterface+0xb08(49a40a8, 2, fb8787b8, fb878914, fe86321c, 0)
    libassafe_api.so`void PortableObject::poParseCallback+0x314(49a40a8, 7, fb8788d4, fb878954, fb878914, fb8787b8)
    0xfe76e828(49a40a8, 0, fb8788d4, fb878954, fb878994, fb8789c0)
    libassafe_api.so`void ParseUtil::endElement+0x224(3954508, 17d45a0, 1af1320, fe86321c, 395453c, a2f4f8)
    libxerces-c.so.26`void xercesc_2_6::SAX2XMLReaderImpl::endElement+0x10c(96ed20, 8686b0, 1, fe875c80, 60786c0, fe76d448)
    libxerces-c.so.26`void xercesc_2_6::IGXMLScanner::scanEndTag+0x644(4a533e0, fb878b4f, 0, fd9cea50, fd864978, 3)
    libxerces-c.so.26`bool xercesc_2_6::IGXMLScanner::scanContent+0x160(4a533e0, 0, 0, fd9fdb24, fd869d60, 1)
    libxerces-c.so.26`void xercesc_2_6::IGXMLScanner::scanDocument+0x78(4a533e0, 0, fd85dfb0, fd87214c, 1c3e88, 2800)
    libxerces-c.so.26`void xercesc_2_6::SAX2XMLReaderImpl::parse+0x8c(96ed20, 10fd780, 17eb0, fe84a145, 0, 1c3e88)
    libassafe_api.so`bool ParseUtil::Parse+0x1c0(3954508, 67c, fb878ed0, 6023ac8, fe86321c, fda348dc)
    libassafe_api.so`bool ispUtil::Parse+0x34(49a40a8, fb878ed0, fe76e800, fe86321c, cd0840, fe86321c)
    libassafe_api.so`void PortableObject::poImportObject+0x18c(49a40a8, fb878ed0, fff0b5e4, f4800, fe86321c, 3)
    libassafe_api.so`void Safe::StoredObject::soExport+0x2e4(5bb7250, 49a40a8, 320, 318, ffffffff, 5bb725c)
    libassafe_api.so`PozObject*Safe::StoredObject::getPozObject+0x38(5bb7250, 0, 0, 49a40a8, fe23e01c, 0)
    libassafe_api.so`bool Safe::GlobalUserGroup::soMap+0x2c(5bb7250, 1, 0, 0, fb879428, 400)
    libassafe_api.so`PozObject*Safe::StoredObject::soExport+0x30(5bb7250, 1, 5d916c0, fe6cec54, fe86cf4c, fe724618)
    libassafe_api.so`Safe::GlobalUserGroup*Safe::Context::getCachedGlobalUserGroup+0x1f4(1dfc00, 10a2538, 2153918, 0, 0, 0)
    libassafe_api.so`bool Safe::Context::expandGlobalUserGroup+0x20(1dfc00, 6e, 3541cd4, fb87a3f8, 7a0, 10a2538)
    libassafe_api.so`void Safe::Context::populateSession+0x195c(1dfc00, 3541c78, 0, 59b5544, 52935d0, ffffffff)
    libassafe_api.so`void Safe::Context::populateSessionQs+0x15e0(1dfc00, 0, 1e0030, 1, fe86321c, 0)
    libassafe_api.so`void Safe::Cache::threadLoop+0x54a4(1dffe8, 1e0098, 1e0030, 0, 0, 0)
    0xfe782784(1dffd0, 0, 0, fe86321c, fde23a00, 16800)
    libassafe_api.so`void*ithread_func+0x48(4cef10, fe782768, fe86321c, 0, 4cef10, 1)Edited by: bekz007 on Mar 17, 2010 12:23 PM

  • Core dump when starting extract, no error messages

    Hello,
    This is a basic one way replication, Data Pump and Replicat start but Extract stops at once.
    In ggserr.log there's only a message: EXTRACT EORATE02 starting, nothing else. In ggsci it can be seen that it's stopped.
    CHECKPARAMS didn't give the message "Parameters processed successfully", neither did it give error messages
    when starting the extract.
    There are no old Oracle processes which could prevent Extract from starting.
    There's EORATE02.pce in dirpcs, although EORATE02 is not running. If I delete it and try to start the extract,
    the extract will immediately stop.
    A core file has been created in GG_HOME when trying to start the extract. I haven't been able to find out how to read it.
    Source and target are on Aix 6100-06. The source database is Oracle 10.1.0.5, target database is Oracle 11.2.0.3.
    The installation files are V32435-01.zip for db 10.1.0.5 (ggs_AIX_ppc_ora10.1_64bit.tar), V32437-01.zip
    for db 11.2.0.3 (ggs_AIX_ppc_ora11g_64bit.tar). This is GoldenGate 11.2.1.0.1.
    The db:s are on Asm.
    There's only 1 table in source, 1 in target, they are identical and empty.
    There's enough space in the OS.
    If I run the extract in OS (extract paramfile dirprm/eorate02.prm), it ends like this without more information:
    TRANLOGOPTIONS ASMUSER ggs_owner@HOSTNAME:1521/+ASM , ASMPASSWORD *********
    Abort(coredump)
    This happens in both ways of extract described below.
    (1)
    EXTRACT EORATE02
    USERID ggs_owner, PASSWORD [PASSWORD]
    EXTTRAIL ./dirdat/data02/te
    TRANLOGOPTIONS ASMUSER ggs_owner@HOSTNAME:1521/+ASM , ASMPASSWORD [PASSWORD]
    TABLE USER.myobjects2;
    (2)
    EXTRACT EORATE02
    USERID ggs_owner, PASSWORD [PASSWORD]
    EXTTRAIL ./dirdat/data02/te
    tranlogoptions COMPLETEARCHIVEDLOGONLY ALTARCHIVELOGDEST /backup/arch_log/abcd/ABCD/archivelog
    TRANLOGOPTIONS ASMUSER ggs_owner@HOSTNAME:1521/+ASM , ASMPASSWORD [PASSWORD]
    TABLE USER.myobjects2;
    Here's more information on this setup and commands which have been used:
    add extract EORATE02 tranlog begin now, threads 1
    add exttrail ./dirdat/data02/te, extract EORATE02, megabytes 5
    EXTRACT EPMPTE02
    PASSTHRU
    RMTHOST HOSTNAME, MGRPORT 13447
    RMTTRAIL /u01/app/oracle/gg11210/for_11g/dirdat/data02/tr
    TABLE USER.myobjects2;
    ADD EXTRACT EPMPTE02 EXTTRAILSOURCE ./dirdat/data02/te
    ADD RMTTRAIL /u01/app/oracle/gg11210/for_db11/dirdat/data02/tr EXTRACT EPMPTE02, MEGABYTES 5
    Target
    REPLICAT RORATE02
    USERID ggs_owner, PASSWORD [PASSWORD]
    HANDLECOLLISIONS
    ASSUMETARGETDEFS
    DISCARDFILE ./dirrpt/RORATE02.DSC, PURGE
    MAP USER.MYOBJECTS2, TARGET USER.MYOBJECTS2;
    add replicat RORATE02, exttrail /u01/app/oracle/gg11210/for_11g/dirdat/data02/tr
    add checkpointtable ggs_owner.ggschkpt
    Grants
    Source:
    grant connect, resource to ggs_owner;
    grant select any dictionary, select any table to ggs_owner;
    grant create table, alter any table to ggs_owner;
    grant flashback any table to ggs_owner;
    grant execute on dbms_flashback to ggs_owner;
    grant execute on utl_file to ggs_owner;
    grant create session, alter session to ggs_owner;
    Target:
    grant create session, alter session, resource, connect, select any dictionary to ggs_owner;
    grant select any table, insert any table, update any table, delete any table to ggs_owner;
    grant create table, alter any table, lock any table to ggs_owner;
    Source
    ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
    ggsci add trandata USER.myobjects2
    mgr.prm
    --GoldenGate Manager parameter file
    PORT 13346
    Target
    GLOBALS
    CHECKPOINTTABLE ggs_owner.ggschkpt
    mgr.prm
    --GoldenGate Manager parameter file
    PORT 13447
    Thanks for reading this far. Possible comments will be much appreciated!
    Best regards
    Edited by: user11323660 on 14.6.2012 6:39
    Edited by: user11323660 on 14.6.2012 6:41

    Hello,
    Could you wrap your process definitions in proper code brackets so its easier to understand.
    Also I'm not sure what your problem is other then you are receiving core dumps. I'm happy to help.
    Two small comment though regarding your ASM config
    1 . Dont not use ggs_owner as the asm user
    TRANLOGOPTIONS ASMUSER ggs_owner@HOSTNAME:1521/+ASM , ASMPASSWORD *********2. Create a TNSNAMES entry for your ASM instance and tehn use the following:
    TRANLOGOPTIONS ASMUSER SYS@ASM, ASMPASSWORD *****Also here is an example of an extract process that I've setup on RAC database with ASM
    EXTRACT EWFMMTLP
    EXTTRAIL ./dirdat/ew
    USERID GGATE@MY_DB, PASSWORD ggatehcc
    DDLOPTIONS ADDTRANDATA RETRYOP RETRYDELAY 20 MAXRETRIES 5 REPORT
    TRANLOGOPTIONS EXCLUDEUSER ggate
    TRANLOGOPTIONS ASMUSER SYS@ASM, ASMPASSWORD ****
    TRANLOGOPTIONS ALTARCHIVELOGDEST /u02/oracle/fast_recovery_area/MY_DB/archivelog
    TRANLOGOPTIONS PURGEORPHANEDTRANSACTIONS
    STATOPTIONS RESETREPORTSTATS
    REPORT AT 00:01
    REPORTROLLOVER AT 00:01
    REPORTCOUNT EVERY 60 SECONDS, RATELet me know if that helps
    Jan S.

  • Core Dump when try to connect to oracle in Pro*C ( on HP)

    Hi ,
    I am getting 'Core Dump' at EXEC SQL Connect stmt in Pro*C. The program works fine on Solaris. Are there any changes needed in Makefile?
    Pls help.
    Thanks
    Nivedita

    I have this exact same problem with 2 MacBook Pro's both running 10.6.5
    I've double checked that the settings are identical on both machines, yet only one of the them can connect to the other using the Guest account. When the Guest account doesn't work and I use the registered user of the other machine, it connects fine. I just would like to be able to use the simple Drop Box function.

  • 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

  • Supressing windows spawned from Runtime.exec()

    Hi,
    I was wondering if anyone had any suggestions on how to suppress windows spawned from using Runtime.exec(program). I've had a good look at the Process object returned from this and cant find a way to do it. I'd like to keep the process being run completely invisible from the user but i'm getting a blank window appear - spawned from the app being run.
    Any ideas?
    TIA,
    Danny

    The exec is called k.exe - its a programming language. I'm writing an interface for a database system called KDB which is implemented in K. (called using 'k db args...').
    Have a look at www.kudib.com if you want to see a bit more about my project or www.kx.com to learn more about K and KDB.
    Danny

  • Make can't recursively call Make when run from Runtime.exec (for some user)

    This one is a little complicated. The afflicted platform is Mac OS X. It works fine on Linux, it seems, and even then, it does work for some Mac OS X users...
    First, the setup. I have a Java program that has to call GNU Make. Then, GNU Make will recursively call Make in some subdirectories. This results in the following Java code:
    String make = "make"; //on windows, I have this swapped with "mingw32-make"
    String workDir = ...; //this is programmatically detected to be the same folder that the parent Makefile is in
    Runtime.getRuntime().exec(make,null,workDir);This calls make on a Makefile which has the following line early on to be executed (this is only a snippet from the makefile):
    cd subdirectory && $(MAKE)When I fetch the output from the make command, I usually get what I expect: It cd's to the directory and it recursively calls make and everything goes smoothly.
    However, for one particular user, using Mac OS X, he has reported the following output:
    cd subdirectory && make
    /bin/sh: make: command not found
    make: *** [PROJNAME] Error 127Which is like, kinda hurts my head... make can't find make, apparently.
    I've gotten some suggestions that it might be due to the "cd" command acting wonky. I've gotten other suggestions that it may be some strange setup with the env variables (My Mac developer is implementing a fix/workaround for 'environ', which is apparently posix standard, but Mac (Mr. Posix Compliance...) doesn't implement it. When he finishes that, I'll know whether it worked or not, but I get the feeling it won't fix this problem, since it's intended for another area of code entirely...
    Also worth mentioning, when the user calls "make" from the terminal in said directory, it recurses fine, getting past that particular line. (Later on down the road he hits errors with environ, which is what my aforementioned Mac dev is working on). Although calling "make" by hand is not an ideal solution here.
    Anyways, I'm looking for someone who's fairly knowledgeable with Runtime.exec() to suggest some way to work around this, or at least to find out that perhaps one of the User's settings are wonked up and they can just fix it and have this working... that'd be great too.
    -IsmAvatar

    YoungWinston
    YoungWinston wrote:
    IsmAvatar wrote:
    However, for one particular user, using Mac OS X, he has reported the following output:One particular user, or all users on Mac OS?In this case, I have two mac users. One is reporting that all works fine. The other is reporting this problem.
    cd subdirectory && make
    /bin/sh: make: command not found
    make: *** [PROJNAME] Error 127Which is like, kinda hurts my head... make can't find make, apparently.If that is being reported on the command line, then I'd say that make wasn't being found at all.If make isn't being found, then who's interpreting the Makefile?
    It's also just possible that the make script on Mac isn't correctly exporting its PATH variable, though it seems unlikely, since this would surely have been reported as a bug long ago.
    I've gotten some suggestions that it might be due to the "cd" command acting wonky...Also seems unlikely. 'cd' has been around since shortly after the K-T extinction event.
    WinstonBy "acting wonky", I mean being given a bad work directory or some such, such that it's not changing to the intended directory.
    Andrew Thompson
    Andrew Thompson wrote:
    (shudder) Read and implement all the recommendations of "When Runtime.exec() won't" (http://www.javaworld.com/jw-12-2000/jw-1229-traps.html).
    Already read it. I already know the dreadful wonders of Runtime.exec. But in this case, it's been working fine for us up until one Mac user reported that make can't find make.
    Also, why are you still coding for Java 1.4? If you are not, use a ProcessBuilder, which takes a small part of the pain out of dealing with processes.Usually I do use a ProcessBuilder. I noticed that it usually delegates to Runtime.exec() anyways, and seeing as I didn't need any of the additional functionality, I decided to just use Runtime.exec() in this particular case.
    jschell
    jschell wrote:
    So print thos env vars, in your app and when the user does it.I'll look into that. It's a good start.
    -IsmAvatar

  • Xcelsius Causes core dump when importing a workbook

    When I try to import a certain workbook a message comes up saying that the server is busy and switch to the application. Switching to the application does nothing and the only way to get out of this is to kill Xcelsius which then causes a blue screen and core dump. Does anyone know how to address this problem?

    Hi there,
    I have posted a suggestion via this link [Server Busy issue with Xcelsius|Re: Server Busy; or you can refer to my following steps:
    1. Open the Windows Task Manager.
    2. Go to tab Applications and look for task Microsoft Excel - Compatibility Check and double click on it. This action will bring you to the small windows of Excel which alerts you about the compatibility check of the Excel file.
    3. Click button Continue to process the import.
    4. Go back to Xcelsius and click Retry button to import the Excel sheet.
    Well, the issue is solved.
    Hopefully this tips will be useful for you.
    Cheers,
    Danny Pham

  • Core dump when running the Proc Application

    I have client that has decided to upgrade from Oracle 10g to Oracle11g version. Presently the client code is compiled with Oracle version 11.1.0.7. We have tuxedo version as 9.0 patch02. When running the ProC application, I am getting the core dump. The stack trace for dump is as follows :-
    core 'core' of 7784: bp_Customer -C dom=KenanFX -g 5 -i 225 -u dsesun10 -U /users/denver/pc
    ffffffff6e8d9bbc kill (2, ffffffff7ffe002c, 1, ffffffff7de3b9a0, ffffffff7ffe0028, ffffffff7e10b5a0) + 8
    ffffffff7d27b1f4 skgesigCrash (ffffffff7ffe09a8, ffffffff7e10a070, 1a0c00, ffffffff7dfdbc40, d60a7c, 1) + 34
    ffffffff7d27b81c skgesig_sigactionHandler (ffffffff7d6fb9a0, ffffffff7ffe1800, ffffffff7ffe0990, ffffffff7e10b578, ffffffff7ffe0998, ffffffff7ffe09a8) + dc
    ffffffff6e8d62e0 __sighndlr (b, ffffffff7ffe1800, ffffffff7ffe1520, ffffffff7d27b740, 0, a) + c
    ffffffff6e8c9e44 call_user_handler (ffffffff75f00200, ffffffff75f00200, ffffffff7ffe1520, 8, 0, 0) + 3e0
    ffffffff6e8ca03c sigacthandler (0, ffffffff7ffe1800, ffffffff7ffe1520, ffffffff75f00200, 0, ffffffff6ea3c000) + 54
    --- called from signal handler with signal 0 (SIGEXIT) ---
    ffffffff7c24bb24 sqlrlc (ffffffff7e0f9fc0, 0, 60, c0, 4, 8) + 4
    ffffffff7c253594 sqlbrl (ffffffff7e0f9fc0, 1004bc630, 1004bc658, 1004bc5d0, ffffffff7ffe1b30, 2) + 114
    ffffffff7c2745ec sqlhvdsc (1004bc5c0, ffffffff7e0f9fc0, 8, ffffffff7fff27a0, 0, 1d676b0) + ac
    ffffffff7c274e68 sqlshv (c, 0, e, 0, f, 1c) + 128
    ffffffff7c25bd8c sqlsel (ffffffff7fff27a0, 1002d0850, 1002d0d80, 1, ffffffff7e0f9fc0, ffffffff7dd09d70) + 38c
    ffffffff7c24ed18 sqlcmex (1, ffffffff7ffe1e80, 0, c, 1002d0850, 0) + 278
    ffffffff7c24f724 sqlcxt (0, ffffffff74fd3800, ffffffff7fff27a0, ffffffff74e5d3e4, 16400, 0) + 44
    ffffffff74c65aec selectCMF_XIDDB (788, 16450, 2, ffffffff74fbb978, ffffffff7fff4344, ffffffff7971de60) + f14
    ffffffff79f5743c bp_AccountFind (0, 0, 1002b6118, 1002b6118, 1002b6118, 1002b6118) + 137c
    000000010001748c commonServiceWrapper (30, 0, 558, 1, 100140428, ffffffff6fa08560) + cac
    000000010001d1a4 I_AccountFind (100188220, 12336c, 2e60, 100186b80, ffffffff7fffa440, ffffffff6fa08560) + ec
    ffffffff7f25ea34 _tmsvcdsp (100186b80, 0, 1001f7b60, 800, 100186b80, 1400) + 11ac
    ffffffff7f28241c _tmrunserver (2bb4, 0, 100186b80, 10017c480, 10017d5a0, 0) + 11ac
    ffffffff7f25d47c _tmstartserver (1, 2c00, 100144c90, 800, 10017ebe0, 1001444e0) + 1ac
    0000000100014e4c main (1b, ffffffff7fffab18, ffffffff7fffabf8, ffffffff6e84b8e0, ffffffff75b05200, ffffffff75f00200) + 14
    0000000100014d9c _start (0, 0, 0, 0, 0, 0) + 17c
    Can you please help what is causing problem in the applications. Thanks in advanced.

    This forum is about C programming in general, and about using Oracle Studio C in particular.
    Your question seems to be about a database application that now crashes when run on an updated version of Oracle database.
    You mention "Proc" and ProC". If you are referring to the Pro*C compiler, that would also be a database question, since the Pro*C compiler is not related to Oracle Studio or Oracle Studio C.
    You are more likely to find a helpful answer in a database programming forum. Start here:
    https://forums.oracle.com/forums/category.jspa?categoryID=18

  • Core Dump when using SSASendTrap()

    Hi!
    I use Solaris 8, os 5.8
    When calling SSASendTrap() I get a core dump.
    Are there any patches available? I searched for but didn't find anything working on my Solaris Version and os Version.
    Is a patch or know how necessary to solve this Problem? Is a detailed description of the SDK-build source code available?
    br,
    cAner

    Hello Ajay ,
    THanks for the reply .
    DATA : BEGIN OF it_data OCCURS 0,
       matnr like RMMG1-MATNR , " Material number
       mbrsh like RMMG1-MBRSH, " Industry sector
       mtart like RMMG1-MTART, " Material type
       meins like MARA-MEINS, " Base unit of measure
       maktx like MAKT-MAKTX, " Material description
       spras like makt-spras , " Language key
       END OF it_data.
    my fm
    CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
    EXPORTING
       I_PROGRAM_NAME               = ge_repid
       I_INTERNAL_TABNAME           = 'it_data'
    *   I_STRUCTURE_NAME             = 'it_data'
    *   I_CLIENT_NEVER_DISPLAY       = 'X'
       I_INCLNAME                   = ge_repid
    *   I_BYPASSING_BUFFER           = 'X'
    *   I_BUFFER_ACTIVE              =
      CHANGING
        ct_fieldcat                  = alv_fieldcat
    EXCEPTIONS
       INCONSISTENT_INTERFACE       = 1
       PROGRAM_ERROR                = 2
       OTHERS                       = 3
    Regards,
    K.Sibi
    Edited by: sibi k  kanagaraj on Apr 27, 2009 9:21 PM

Maybe you are looking for