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

Similar Messages

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

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.

_smalloc cause core dump

Hi:
I got a core dump on _smalloc. Is it due to memory corruption on my application ? The frame stack on gdb is attached:
#0 0xff0456c8 in _smalloc () from /usr/lib/libc.so.1
(gdb) bt
#0 0xff0456c8 in _smalloc () from /usr/lib/libc.so.1
#1 0xff04570c in malloc () from /usr/lib/libc.so.1
#2 0x1fde4 in debug_malloc (nsize=11, ntype=1 '\001') at comm_utility.cpp:312
#3 0x1c144 in LNXSocket_OnReceive (sockfd=12) at comm_connect.cpp:418
#4 0x1cbc8 in Select_socket () at comm_connect.cpp:612
#5 0x1e028 in main () at comm.cpp:177
(gdb) quit
Thanks and Regards

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.

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

/AdminMain causes core dump

I've installed WebLogic on a Solaris (SPARC) 2.7, JDK 1.2.2.
I'm just going through WebLogic and testing the various functionalities.
When I load then /AdminMain page the first time, it works beutifully.
However, if I click on any of the links or reload the page, the web server
goes down in flames (Core Dump)
Any Ideas?
I have attached two files, the one listing the webserver's output at startup
and the second being the webserver's output when it dies.
Regards
Johan Locke
http://www.JohanLocke.co.za
Certified Oracle 8 & 8i DBA
Certified Oracle Developer
Dimension Data i-Commerce Internet Services
Direct Line: +27 11 283 5789
mailto:[email protected]
http://www.is.co.za
[webLogic_startup.txt]
[web_logic_dump.txt]

Yes there is a problem with JD 1.2.2_05a. It's documented on our platform support
page
Check out: http://www.weblogic.com/platforms/index.html#solaris
Kumar
Cliff Hafen wrote:
I have the same problem and can't go back to an earlier jdk. Running Solcaris
2.7, WL5.1sp4. I can provide more info if needed.
Cliff
First Last wrote:
I got the same problem with 122-05a but the problem goes away once I change it
back to 121_04. Is there a problem with running weblogic51 under jdk122_05a ?
Michael Girdley wrote:
Are you on JDK version 1.2.2_05 a?
Thanks,
Michael
Michael Girdley
BEA Systems Inc
"Johan Locke" <[email protected]> wrote in message
news:[email protected]..
I've installed WebLogic on a Solaris (SPARC) 2.7, JDK 1.2.2.
I'm just going through WebLogic and testing the various functionalities.
When I load then /AdminMain page the first time, it works beutifully.
However, if I click on any of the links or reload the page, the web server
goes down in flames (Core Dump)
Any Ideas?
I have attached two files, the one listing the webserver's output atstartup
and the second being the webserver's output when it dies.
Regards
Johan Locke
http://www.JohanLocke.co.za
Certified Oracle 8 & 8i DBA
Certified Oracle Developer
Dimension Data i-Commerce Internet Services
Direct Line: +27 11 283 5789
mailto:[email protected]
http://www.is.co.za

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! :(

OCILogon Causing Core Dump

I have created a shared lib on both AIX 5.2 and Tru64 UNIX 5.1A which calls the OCILogon() function to logon to the database. In a driver program, I dynamically load the shared library using dlopen() and call the function that contains the OCILogon() call. The driver program crashes when it tries to exit after calling dlclose(). Looking at the stack trace on Tru64 it appears to crash unloading the libc.so shared library.
0 0x3ff800ddee8 in exit(0x3ffc008a060, 0x0, 0x1000000, 0x3ffc0184000, 0x0, 0x1) in /usr/shlib/libc.so#1 0x3ff800ddee4 in exit(0x3ffc008a060, 0x0, 0x1000000, 0x3ffc0184000, 0x0, 0x1) in /usr/shlib/libc.so
#2 0x1200013f8 in __start(0x3ffc008a060, 0x0, 0x1000000, 0x3ffc0184000, 0x0, 0x1) in driver
On AIX I am not able to get a stack trace. The reason that I think the problem is in the OCILogon function is because when I take it out, the code does not crash. Any ideas?

My guess is that this is purely security/access permissions problem. Client probably needs to open up security on port or something to allow permissions. Perhaps something in java.policy can be edited to allow? Hope that helps somewhat.

ReplyTo header field from Java JMS read by C JMS API causes core dump...

Hi,

First step is to add the option -Xcheck:jni to your java command line. It will flag common JNI errors.
If that doesn't identify the problem, then compile your jni code with debugging symbols (-g) and add the following option to the java command line when you run your test: -XX:+ShowMessageBoxOnError. When you hit the problem again, the VM will keep the process alive instead of calling abort(). Then you can use dbx to attach to the live process and should be able to get a better idea of what went wrong.

Xmlcg core dump

I'm using Oracle XML Class Generator version 9.2.0.5.0 Production in UNIX.
The xmlcg program is core dumping if my DTD contains an empty element. I'm running it from the command line and uses the '-d' option:
xmlcg -d test test.dtdexample:
<!ELEMENT Data EMPTY> //this causes a core dump
<!ELEMENT Data (#PCDATA)> //this is ok
Can somebody please help? I'm trying to evaluate if we can use this class generator for a project.
thanks,
Greg D.

Forgot to mention. We are calling OCISessionEnd before rolling through OCIServerDetach.
/* STATIC */
static void logout()
printf ("\n\nFreeing statement handles..\n");
if(stmthp) OCIHandleFree ((dvoid *) stmthp, (ub4) OCI_HTYPE_STMT);
printf ("Logging off...\n");
if(authp) OCISessionEnd (svchp, errhp, authp, (ub4) 0);

Core dump on solaris 8/7 making JNI call.

Hi,
I am running solaris 8 and solaris 7 with Java 1.3.1. I have required solaris patches installed on the machine for java 1.3.1.
From a C program I am making some JNI calls and when I run the program it core dumps at the very first JNI call. C program that make JNI calls are in a .so file.
Same C code with Java 1.3.1 is running fine on window 2000, AIX 5.1, RedHat Advanced Server 2.1 and SuSE Enterprise Linux 7.
Any help will be greatly appriciated.
Thanks

Hiya,
Any resolution to this post , we have a native JNI call on a Websphere server running on Solaris 8 .. and same thing happening .. random core dump on the box ..
No warning , no explanation
Thanks so much for your help
(btw . running Sun jvm 1.4.2_13)

Service pack 5 core dumping

We were having the same trouble with 5.1.0 SP9
using Oracle Client 8.1.5, Oracle Server 8.1.7.
Also using Solaris 2.7 and JDK 1.3.1.
and OCI JDBC drivers supplied by Weblogic.
This gave us sporatic failures identical to below.
Thin drivers were too slow and also produced other
'wierd' side effects.
SP10 allows upgrade to Oracle 8.1.7 client drivers.
The combination upgrade to SP10 and Oracle 8.1.7 client
drivers appears to fix the problem.
--Rich
================
Kumar Allamraju <[email protected]> wrote:
type-4 driver is pure java. It doesn't use native code at all..
Kumar
arun wrote:
I treid using Oracle's type-4 jdbc driver and it work fine - no coredumps so far!
Arun.
Kumar Allamraju wrote:
I don't think SP-5 is causing core dump. The following stack trace
doesn't show me that JVM has core
dumped
on this particular native call. Post the full thread dump here ,so that we can analyze further.
If you take out SP4, don't you see this problem? Could you try type-4driver also?
Kumar
arun wrote:
Hi,
I'm getting a core dump on
SunOS packet 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-250
WebLogic Build: 5.1.0 Service Pack 5 08/17/2000 07:21:55 #79895
I'm including the relevant(?) stack trace below:
"ExecuteThread-9" (TID:0xf1171580, sys_thread_t:0x552570, state:R,
native ID:0x13) prio=5
at weblogic.db.oci.OciCursor.execAndFetch(Native Method)
at weblogic.db.oci.OciCursor.oci_execAndFetch(OciCursor.java,
Compiled Code)
at weblogic.jdbcbase.oci.Statement.executeQuery(Statement.java,
Compiled Code)
at weblogic.jdbc.pool.Statement.executeQuery(Statement.java,
Compiled Code)
at com.avulet.db.DataDock.getUser(DataDock.java, Compiled
Code)
at com.avulet.db.DataDock.getUser(DataDock.java, CompiledCode)
at
com.avulet.webapp.archive.ArchiveBean.getTop(ArchiveBean.java,Compiled
Code)
at
jsp_servlet._reservation._createRes._jspService(_createRes.java,
Compiled Code)
at weblogic.servlet.jsp.JspBase.service(JspBase.java, Compiled
Code)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java,
Compiled Code)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java,
Compiled Code)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java,
Compiled Code)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java,
Compiled Code)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java,
Compiled Code)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java,
Compiled Code)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java,
Compiled Code)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java,
Compiled Code)
This started happening ever since I applied the service pack 5.Any
ideas on how to get past this?
Thanks,
Arun.

OWB 9.03.35.3 + Oracle 9.2 + Core dumps

We have big problems, after we migrate to Oracle 9.2 Database with our packages, we use a selfimplemented Flowmanager like the Oracle one based on a web application using oracle specific functions, but after we migrate to 9.2 no package works, most of them causes core dumps!!!!!
Here is the info we send to Metalink.
Do someone have an idea what may cause this problems!!!!
Erik Heindel (DBA)
Metalink Infos:
Resolution History
13-MAR-03 16:58:03
Can you easily recover from, bypass or work around the problem? = NO
Does your system or application continue normally after the problem occurs? =
YES
Are the standard features of the system or application still available; is the
loss of service minor? = NO
### Platform and O/S version, including patchset or service pack level? ###
HP-UX 64Bit
### What version and patchset level of the database are you running? ###
9.2.0.2
### Are you running the most recent patchset? ###
Yes
### Please describe your problem: ###
Jobs/Packages generated with OWB results in a core dump.
### If you are receiving errors, please list exact error messages and text: ###
see attached file 'core'
### Did the error generate a trace file? ###
No
### Please list all files that you plan to upload: ###
core dump file
### What was being done at time of error? Any changes since this last worked? ##
Database was upgraded from 8.1.7.4 to 9.2.0.2
### Can error be generated if SQL is run in SQL*Plus or Server Manager? ###
Yes
### What is the frequency of the error? ###
Consistently
### What is the impact to your business because of this problem? ###
DWH can't go live!!! Packages where needed to load the data into the
Datawarehouse-DB.
### Are you running any third-party applications? ###
NO
### If your current issue involves a 3rd party software, has this vendor been co
Does Not Apply
Contact me via : E-mail -> [email protected]
13-MAR-03 17:02:05
Country: GERMANY
The customer has uploaded the following file via MetaLink:
C:\test\core

Erik,
Can you identify whether the problem is Warehouse Builder specific or whether it is caused by the database? I will contact the email address that is mentioned in your message.
Thanks,
Mark.

Core dump on COMMIT in Pro C

Hi all,
I was wondering if anyone has encoutered this problem - and, more
importantly, how he/she solved it.
I have Pro-C application with embedded SQL which reads the file and imports the data into database. It does a bunch of queries and then a lot of inserts. After each insert a commit. Six insert-commits go OK, seventh insert is OK (no Oracle error message whatsoever) but the program coredumps on the EXEC SQL COMMIT WORK;
Interesting thing is, I am getting core dump only if there are 2 records in the file otherwise it works fine.
We are running Oracle8i Enterprise Edition Release 8.1.7.4.0 on Solaris.
Any ideas?
Regards
Narayana Gupta

As Joel said, wrong forum...however I couldn't help noticing -
After each insert a commitMy question would be "why"?

Forms 11g frmcmp gives Aborted (core dumped) error while compiling pll

Hello
We've installed oracle forms 11.1.2 on our linux server and are now trying to recompile all form objects from our previous release (10g).
All forms compile without much problems, but some pll's (not all) fail with the error: Aborted (core dumped).
Is there any way to find out what might be happening? I don't seem to find any log about what is causing this problem.
Any input or ideas are more then welcome.
Regards
Johan
Edited by: vanvojo on Sep 12, 2012 10:57 PM

I had the same problem on my development machine; I solved it by converting all pll files to pld files with the 10g reports compiler and convert them back to pll with the 11g reports compiler. I noticed that the problem is most likely to occur on libraries having a lot of other libraries attached which are not converted to 11g yet, so it also might be that you can solve the problem by changing the compile-order. But anyway the reports compiler solved this problem for me without ordering the compilation steps ;)
cheers

Pro*c program causing core dump in 11g

Similar Messages

Maybe you are looking for