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

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.
#

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)

SRW.APPLY_DEFINITION cause (core dumped) Segmentation fault

When I run report under Concurrent manager, i.e. within Oracle Applications I get this error:
(core dumped) Segmentation fault.
I use SRW.APPLY_DEFINITION in After Parameter Form. When I remove SRW.APPLY_DEFINITION report runs fine.
I tried following in the command line:
$ ar60runb report=/PATH_TO_RDF_FILE/NAME.rdf batch=yes destype=file desname=/PATH_TO_OUTPUT_FILE/NAME.out desformat=XML
and I get this error:
ar60runb: uisfz.c:173: uisfzfn_Fns: Assertion `0' failed.
Aborted (core dumped)
When I remove "batch=yes" or use "batch=no" everything passed fine.
I get the same result when I use .RDF file without SRW.APPLY_DEFINITION in the code.
I have applied the solution from Note:368457.1 but it didn't help.
I want to set "batch=no" when I run report under Oracle Applications or just resolve this problem somehow.
Platform SUSE \ UnitedLinux x86-64
Product Version 11.5.10.2

Come on, guys. Help! :(

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.

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?

Value type exception causes core dump

Hi,
Here is the situation: Session EJB (SynchronousAdapterBean) running on WebLogic
7.0 is being called by C++ client using Tuxedo 8.1 Solaris 8. The SynchronousAdapterBean
has a find method which throws a user defined exception (SynchronousAdapterException)
resulting in a core dump.
I have read through much documentation on the newsgroups, edocs.bea.com, and
the examples coming with WebLogic.
Here some of the things I did:
1.
When using the 'idl' command to generate the C++ code, I did not forget to use
a '-i' to generate the implementation files: SynchronousAdapterException_i.cpp
and SynchronousAdapterException_i.h.
In my "play with it to make it work" phase, I also did this for: SynchronousAdapterEx_i.cpp
and SynchronousAdapterEx_i.h.
2.
In my C++ client, I did not forget to register the factory as such:
orb->register_value_factory
((char* const)com::trs::cv::comm::cnja::synchadapter::_tc_SynchronousAdapterException->id(),
(CORBA::ValueFactory)
new com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory());
This seemed to work because I actually put debug cout statements in the 'com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory'
in the file SynchronousAdapterEx_i.cpp and it confirmed that it was constructed
and the reference count was incremented.
3.
I know for sure that it is a 'SynchronousAdapterException' being thrown on the
server side because all the find method does it this point is:
throw new SynchronousAdapterException("test1");
Questions:
1. I read at a few places that one only has to register the "most derived" class
being thrown (in my case 'SynchronousAdapterException'). What does one do with
all the other exceptions generated:
EJBException_c.h
EJBException_c.cpp
EJBEx_c.h
EJBEx_c.cpp
CreateEx_c.h
CreateEx_c.cpp
CreateException_c.h
CreateException_c.cpp
RemoveEx_c.h
RemoveEx_c.cpp
RemoveException_c.h
RemoveException_c.cpp
RuntimeEx_c.h
RuntimeEx_c.cpp
RuntimeException_c.cpp
RuntimeException_c.h
SynchronousAdapterEx_c.cpp
SynchronousAdapterEx_c.h
SynchronousAdapterEx_i.cpp
SynchronousAdapterEx_i.h
Exc.cpp
Exc.h
Exceptionc.cpp
Exceptionc.h
2. What step could I have missed?
Alex

Hi Andy,
1.
Well no new member classes in SynchronousAdapterException it just looks like this:
public class SynchronousAdapterException extends Exception {
public SynchronousAdapterException() {
super();
Not available in 1.3.1, but is available in 1.4
public SynchronousAdapterException(String message, Throwable ex) {
super(message, ex);
public SynchronousAdapterException(String message) {
super(message);
Not available in 1.3.1, but is available in 1.4
public SynchronousAdapterException(Throwable ex) {
super(ex);
2.
We are using:
java version "1.3.1_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode)
3.
dbx produces the following, anything ring a bell?
Reading libdl.so.1
Reading libaio.so.1
Reading libmp.so.2
Reading libc_psr.so.1
Reading liborbiiop.so.71
Reading liborbtcp.so.71
detected a multithreaded program
t@2 (l@2) terminated by signal ABRT (Abort)
0xfec9bbd4: lwpkill+0x0008: bgeu,a lwpkill+0x1c
Current function is operator>>
218 mb.UnMarshalValue(::com::trs::cv::comm::cnja::synchadapter::_tc_SynchronousAdapterException,
obj);
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
current thread: t@2
[1] lwpkill(0x0, 0x2, 0x0, 0x6, 0x197f0, 0x4c6e0), at 0xfec9bbd4
[2] raise(0x6, 0x0, 0xffffffff, 0xc00cc, 0x8, 0xfee355c0), at 0x4c6e8
[3] abort(0xd2040, 0xbeaf8, 0xff3b2aac, 0xfee34684, 0x15398, 0xfee34874), at
0x4c6a8
[4] __Cimpl::ex_terminate(0x0, 0x0, 0xfee4a500, 0xff1edf90, 0xff09ecd0, 0x1),
at 0xfee34684
---- hidden frames, use 'where -h' to see them all ----
[6] OBB::MarshalBuf::UnMarshalValue(0xfeaf9a28, 0xc9dd8, 0xfeaf99b0, 0xff1edf90,
0xff1edfd0, 0xfed2ebb8), at 0xff0a3980
=>[7] operator>>(mb = CLASS, obj = CLASS), line 218 in "SynchronousAdapterExc.cpp"
[8] _tcr_com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterEx_unmarsh(mh =
0xce520, obj = 0xfeaf9b7c, flags = 130U), line 259 in "SynchronousAdapterEx_c.cpp"
[9] TCInterpreter::DecodeByTypeCode(0x16, 0xff1d674c, 0xfeaf9b7c, 0xce520, 0x82,
0xfeaf9b07), at 0xff0f3aec
[10] TCInterpreter::DecodeById(0xcbaa0, 0xcf230, 0xfeaf9b7c, 0xce520, 0x82,
0xfeaf9f98), at 0xff0f3c94
[11] ReplyMessage::DecodeMessageBody(0x18000, 0xcd820, 0xfeaf9f98, 0xbf358,
0xfebcffb0, 0xfed2ebb8), at 0xff0e1938
[12] GIOPMessage::DecodeBody(0xce240, 0xfeaf9f98, 0xff0dd494, 0xff0dd494, 0xffffffd0,
0xfeb93e24), at 0xff0c23a0
[13] IiopProtocol::Reply(0xd0958, 0xce240, 0xce148, 0xfeaf9f98, 0x100, 0xfebd0010),
at 0xfeb94064
[14] IiopMsgReceiver::MsgReceived(0xca5a0, 0xce240, 0xce148, 0xfeaf9f98, 0x0,
0xfeaf9f98), at 0xfeb9bc74
[15] GiopMessageProtocol::MsgReceived(0xcb358, 0xfeaf9dd8, 0xd1160, 0xfeaf9f98,
0x0, 0xfeaf9f98), at 0xfebac6fc
[16] MessageManager::RecvMsgFirstTime(0xcf8c0, 0xce240, 0xd1160, 0xcb358, 0xd11d0,
0xfeaf9f98), at 0xfebab1b0
[17] MessageManager::AvailableForRecvMsg(0xcf8c0, 0xd1160, 0xcb358, 0xfeaf9f98,
0x3e8, 0xd1170), at 0xfebaa030
[18] ChannelManager::DoReadWork(0xff1d674c, 0xfebd0038, 0xd1160, 0x0, 0x0, 0xcfd58),
at 0xfeba54dc
[19] ChannelManager::DoIt(0xcb3b0, 0xfeaf9f98, 0x0, 0xfebcffd0, 0xcfda0, 0xfebcffd0),
at 0xfeba0750
[20] WorkerManager::DoWorkerThread(0x0, 0xca648, 0xfeaf9f98, 0xcfda0, 0xfeba9924,
0x0), at 0xfeba7894
[21] WorkerThread(0xcfd98, 0xfeafa000, 0x0, 0x0, 0x0, 0x0), at 0xfeba9974
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx)
Thanks,
Alex
Andy Piper <[email protected]> wrote:
"Alex" <[email protected]> writes:
It sounds like you have done all the right steps. More comments in-line:
1.
When using the 'idl' command to generate the C++ code, I did not forgetto use
a '-i' to generate the implementation files: SynchronousAdapterException_i.cpp
and SynchronousAdapterException_i.h. Ok.
In my "play with it to make it work" phase, I also did this for: SynchronousAdapterEx_i.cpp
and SynchronousAdapterEx_i.h.This should not be necessary - XXXEx is an IDL exception.
2.
In my C++ client, I did not forget to register the factory as such:
orb->register_value_factory
((char* const)com::trs::cv::comm::cnja::synchadapter::_tc_SynchronousAdapterException->id(),
(CORBA::ValueFactory)
new com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory());Ok. What does the Exception actually look like in Java? (Incidentally
the _i file creates a useful helper function called _register() which
will do this step for you). Did you register all member classes? You
are correct about most derived types being the important ones, but you
need to also register member classes if they are not standard.
This seemed to work because I actually put debug cout statements inthe 'com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory'
in the file SynchronousAdapterEx_i.cpp and it confirmed that it wasconstructed
and the reference count was incremented.
3.
I know for sure that it is a 'SynchronousAdapterException' being thrownon the
server side because all the find method does it this point is:
throw new SynchronousAdapterException("test1");Ok (incidentally you are not running the server on JDK 1.4 are
you. This would cause problems).
Questions:
1. I read at a few places that one only has to register the "most derived"class
being thrown (in my case 'SynchronousAdapterException'). What doesone do with
Yes.
all the other exceptions generated:These are just needed at compile time so that you don't get undefined
symbols.
2. What step could I have missed?Its not clear. You should try running in a debugger and seeing where
its falling over.
andy

Pro*c program causing core dump in 11g

hello every one,
I am trying to debug a pro*c program which is resulting in a core dump. It used to work fine in with Oracle 10g precompiler but is causing a core dump with 11g. When I run dbx here is what I get.
dbx wreg309
Type 'help' for help.
[using memory image in core]
reading symbolic information ...
Segmentation fault in u_fsetcodepage_3_8 at 0x9000000014f4f70 ($t1)
0x9000000014f4f70 (u_fsetcodepage_3_8+0x68) f87f0010 std r3,0x10(r31)
Any ideas what this means ? Thanks.

Hi,
I came across your problem on the Oracle Discussions Forum from back on June of 2009.
I am working with a pro*c program, in Banner 8. I getting the same message from a core dump,, that you got. I was hoping
you might have written down what you did to resolve it.
My pro*c program is key to running all the SQR code we have. So it's very important. The version of sqr that gets
linked into it is 32-bit and our environment is 64-bit. Our contract with Oracle for SQR has lapsed (it's a long
and expensive story and this is probably not the place). My whole migration to Oracle 11 is being held up by this.
I realize it's been a while since you worked on it but if you could tell me how you resolved your problem, I might be
able to do the same.
Thanks,
Tom Mayne
North Shore Community College
Danvers MA
[email protected]
cell 978 423 6867

OCI connect error reported to cause core dump

I use OCI in my developped library. Other developers use my library for their development purposes. Last night, the oracle server went down for patching, and a user reported a core dump that I recognized it is comming from my OCI section of library.
I do OCI initialization, select, execute a query, and cleanup.
Has there been any reports as for the case, when a connection is initialized, and the server goes down after successful initialization but before calls to execute a query or commit?
Any comment???
I have the error message below, and replace prepriotory info with xxxxxxx.
thanks,
--M
Fatal NI connect error 12541, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxxx)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=xxxxxx)(CID=(PROGRAM=xxxxxx@fashing)(HOST=xxxxxx)(USER=xxxxx))))
VERSION INFORMATION:
TNS for Solaris: Version 10.1.0.4.0 - Production
TCP/IP NT Protocol Adapter for Solaris: Version 10.1.0.4.0 - Production
Time: 15-FEB-2007 15:49:09
Tracing not turned on.
Tns error struct:
ns main err code: 12541
TNS-12541: TNS:no listener
ns secondary err code: 12560
nt main err code: 511
TNS-00511: No listener

We have seen core dumps in system calls earlier and have tried to debug them. We did not have the exact same stack as you but the core used to show up a stack in _malloc.
As it turned out that we had out of bound array reads (used purify to detect this) and which resulted in this dump. So the stack shown in this case could be totally misleading and the real cause could be somewhere else.
Hope this helps.

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

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.

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 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 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 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

Xcelsius Causes core dump when importing a workbook

Similar Messages

Maybe you are looking for