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.

Similar Messages

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

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

_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

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.

OCI Connection error under w98

I have a little problem...
With some w98 os (not all) with a 8.1.7 oracle client (and correct TNS), i can't execute OLOG function without receive an error.
Login and password are correct.
I don't know why...

What type of error are you receiving?
This information may help in debugging the problem...
If you have any other information that may be relevant
you may also want to post that here.

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.

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.

XMLType table Core Dump using CLOB

I've created an object based XMLType table based on a valid XML Schema. The Schema has an element which has been declared as a CLOB.
<xs:element name="complete_entry" xdb:SQLType="CLOB" xdb:SQLName="complete_entry"/>
This registers ok with Oracle and the object that this element is in shows the element as a CLOB as expected.
However when performing a insert into this table, SQLPlus gives and end-of-communication error and the server core dumps.
A PL/SQL function retreives an XML file from the file system for insert, here is the code for the function:
create or replace function getClobDocument(
filename in varchar2,
charset in varchar2 default NULL)
return CLOB deterministic
is
file bfile := bfilename('DIR',filename);
charContent CLOB := ' ';
targetFile bfile;
lang_ctx number := DBMS_LOB.default_lang_ctx;
charset_id number := 0;
src_offset number := 1 ;
dst_offset number := 1 ;
warning number;
begin
if charset is not null then
charset_id := NLS_CHARSET_ID(charset);
end if;
targetFile := file;
DBMS_LOB.fileopen(targetFile, DBMS_LOB.file_readonly);
DBMS_LOB.LOADCLOBFROMFILE(charContent, targetFile,
DBMS_LOB.getLength(targetFile), src_offset, dst_offset,
charset_id, lang_ctx,warning);
DBMS_LOB.fileclose(targetFile);
return charContent;
end;
The function is called like so:
INSERT INTO boss_contracts
VALUES(XMLTYPE(getCLOBDocument('contract_82.xml','UTF8')));
This works perfectly when the element is declared as a string and Oracle converts it to a varchar2(4000), but core dumps when it is a CLOB.
I need this element to be able to handle more than 4k of data.
please help,
Paul Linney
[email protected]

void print_affect(struct oci_connection* conn, OCIStmt* sh) {
sb2 rowCount;
ub4 sizep = sizeof(sb2);
OCIAttrGet(sh, OCI_HTYPE_STMT,&rowCount,
&sizep,OCI_ATTR_ROW_COUNT, conn->err);OCI_ATTR_ROW_COUNT is a ub4 attribute, not a sb2 one.
ub4 rowCount = 0;
ub4 size = sizeof(rowCount);
--DD

Throws Core Dump for OCISessionBegin() on Linux for Oracle Client v10.2.0.2

hi,
The OCI method, OCISessionBegin() is throwing an core dump on 10g client in Linux on C++, but the same code works fine for 8i and 9i client. Core dumps for 10g Client. 10g tnsnames.ora file is same as of 9i. I just debeggued with the core and says failing in OCISessionBegin() method. I would like to know is there any problem with Oracle Client v10.2.0.2? or how does i can solve the issue? appriciate a quick help in this regard.
Thanks,
Sreeni

Have you looked in the Knowledge Base information at metalink? That would be the place to start.
If that does not work then the next step would be to remove this thread and post in the OCI - OCCI forum where there are people that can actually help you.

/opt/SUNWspro/prod/bin/acomp core dump!!

Recently, when I compile the ESP ghostscript 8.51 on Solaris 10 and Solaris 9, the progamm acomp (in /opt/SUNWspro/prod/bin/) cored dump, the errors is as follows:
cc:/opt/SUNWspro/prod/bin/acomp fatal error
status 139
*** Error code 139
make: Fatal error: Command failed for target `obj/gdevdjet.o'
there is no errors before the acomp cores dump, only some warning, why does the acomp core dump? what's meaning for the error code 139?

I add the -V -# compilation flags, then the output is as follows:
cc -DHAVE_MKSTEMP -DHAVE_HYPOT -O -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long" -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_DIRENT_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ERRNO_H=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MALLOC_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_ST_BLOCKS=1 -DTIME_WITH_SYS_TIME=1 -DSIZEOF_UNSIGNED_LONG_INT=4 -DSIZEOF_UNSIGNED_LONG_LONG=8 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBX11=1 -DHAVE_LIBXEXT=1 -DHAVE_LIBXT=1 -DHAVE_MKSTEMP=1 -DHAVE_HYPOT=1 -DHAVE_UNISTD_H=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 -DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DRETSIGTYPE=void -DLSTAT_FOLLOWS_SLASHED_SYMLINK=1 -DHAVE_VPRINTF=1 -DHAVE_DOPRNT=1 -DHAVE_BZERO=1 -DHAVE_DUP2=1 -DHAVE_FLOOR=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_MEMCHR=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MODF=1 -DHAVE_POW=1 -DHAVE_PUTENV=1 -DHAVE_RINT=1 -DHAVE_SETENV=1 -DHAVE_SQRT=1 -DHAVE_STRCHR=1 -DHAVE_STRERROR=1 -DHAVE_STRRCHR=1 -DHAVE_STRSPN=1 -DHAVE_STRSTR=1 -V - -I./obj -I./src -O -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long" -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_DIRENT_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ERRNO_H=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MALLOC_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_ST_BLOCKS=1 -DTIME_WITH_SYS_TIME=1 -DSIZEOF_UNSIGNED_LONG_INT=4 -DSIZEOF_UNSIGNED_LONG_LONG=8 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBX11=1 -DHAVE_LIBXEXT=1 -DHAVE_LIBXT=1 -DHAVE_MKSTEMP=1 -DHAVE_HYPOT=1 -DHAVE_UNISTD_H=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 -DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DRETSIGTYPE=void -DLSTAT_FOLLOWS_SLASHED_SYMLINK=1 -DHAVE_VPRINTF=1 -DHAVE_DOPRNT=1 -DHAVE_BZERO=1 -DHAVE_DUP2=1 -DHAVE_FLOOR=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_MEMCHR=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MODF=1 -DHAVE_POW=1 -DHAVE_PUTENV=1 -DHAVE_RINT=1 -DHAVE_SETENV=1 -DHAVE_SQRT=1 -DHAVE_STRCHR=1 -DHAVE_STRERROR=1 -DHAVE_STRRCHR=1 -DHAVE_STRSPN=1 -DHAVE_STRSTR=1 -V - -o ./obj/gdevdjet.o -c ./src/gdevdjet.c
cc: Sun C 5.7 2005/01/07
cc: Sun C 5.7 2005/01/07
acomp: Sun C 5.7 2005/01/07
acomp: Sun C 5.7 2005/01/07
"./src/gdevdjet.c", 130 : :
"./src/gdevdjet.c", 137 : :
"./src/gdevdjet.c", 144 : :
"./src/gdevdjet.c", 151 : :
"./src/gdevdjet.c", 158 : :
"./src/gdevdjet.c", 165 : :
"./src/gdevdjet.c", 172 : :
"./src/gdevdjet.c", 179 : :
"./src/gdevdjet.c", 186 : :
"./src/gdevdjet.c", 193 : :
"./src/gdevdjet.c", 200 : :
"./src/gdevdjet.c", 207 : :
"./src/gdevdjet.c", 214 : :
cc:/opt/SUNWspro/prod/bin/acomp
139
*** Error code 139
make: Fatal error: Command failed for target `obj/gdevdjet.o'
the line 130 to 214 is some warning, because my compiler supports Chinese font, the waring line cann't be show correctly here.
#uname -a
SunOS kf06-1 5.10 Generic sun4u sparc SUNW,Ultra-4
#whoami
ems

OCI connect error reported to cause core dump

Similar Messages

Maybe you are looking for