Re: [cx-oracle-users] Oracle crash with CLOB and threading

[Roger W. <rog...@to...>]

Thanks for trying the program.

As the next step we have recompiled everything (Python cx_Oracle) to
run under Solaris 10 64 Bit so that the breaking program can be run against
Oracle 10g.

The compilation was rather an adventure, but we eventually go a working Python
2.5. Cx_Oracle was more of a problem, and core dumped at the first cursor=20
manipulation (BUS_ADRALN an alignment problem).

I spent some time tracking the problem, and finally found it to be the =
retrieval of=20
named variables, the PyDict_Next() call that was puking. I consulted the python
documentation and everything looked OK, looking in the python header file=20
though showed the second parameter to PyDict_Next() (the counter) was not =
integer,=20
as in the python documentation and the cx_Oracle code, but Py_ssize_t. Changing =
the code to use this definition (I bet its not int on a 64 bit platform) fixed =
the problem of=20
course.

There are 3 instances of PyDict_Next() being used in cx_Oracle, all of them in =
Cursor.c,
and just changing the second parameter declaration to be Py_ssize_t does the =
trick, and
everything runs OK.

Having a working cx_Oracle, I ran the test program again, and got exactly the =
same problem
as on the 32 bit system. The only difference is that I need to run more threads =
to break it=20
now (20 instead of 10).=20

Checking the reason for the core dump shows an alignment problem again, so it =
can be
that something being passed to or from the OCI by reference is type mismatched =
(remember
you cant trust the Python documentation on this!). I would suggest that the =
Connection pool
is a good place to look, as the problem does not occur when individual =
connections are used.

I would like to go further with this, but I have a couple of pressing jobs that =
need to be done,=20
so unfortunately I cant do much right now. I hope to get back th this problem =
soon. If you have
time to take a peek at this in the meantime, I would be most grateful.

Just for the record, we get the problem on:

System 1:
	Oracle 9i
	Solaris 9 32 Bit
	Python 2.2
	Cx_Oracle 4.2.1

System 2:
	Oracle 10.2.0.1
	Solaris 10 64 Bit
	Python 2.5
	Cx_Oracle 4.2.1

Regards Roger

  >>  I finally had a chance to try your program and did not run into any
  >>  difficulties at all. The error you report is an Oracle crash and so is
  >>  likely due to your particular Oracle software configuration. My own
  >>  (which worked) was:

  >>  Python 2.3 and Python 2.5
  >>  Oracle Standard 9.2.0.5 (both server and client)
  >>  Linux - Fedora Core 6 32-bit (both server and client)

  >>  I would suggest scanning the Oracle bug database for the error you
  >>  encountered. During my own traversals of that databse I have seen a
  >>  number of problems related to CLOBs and segfaults like you indicated.
  >>  I know that patchset 9.2.0.8 has been released -- its possible your
  >>  issue has been addressed there.

  >>  I unfortunately do not have access to an installation of the
  >>  Enterprise edition running 64-bit anything -- so I can't help you in
  >>  your specific configuration. Perhaps someone else on the list knows
  >>  about this issue or can test it in an environment more similar to the
  >>  poster's?

  >>  On 1/26/07, Torsten Prange <Tor...@to...> wrote:
  >>  > Hello,
  >>  >
  >>  > my collegue sent this mail today but has not subscribed to the mailing
  >>   list
  >>  > probably.
  >>  >
  >>  >
  >>  > Mail from Rog...@to...:
  >>  >
  >>  > Hi,
  >>  >
  >>  > I am having some problems with cx_Oracle, threads and clob's and am
  >>   looking for
  >>  > some guidance.
  >>  >
  >>  > For the record:
  >>  >         The system is "SunOS tmxd01 5.9 Generic_112233-10 sun4u sparc"
  >>  >         cx_Oracle version is cx_Oracle-4.2.1
  >>  >         Oracle version is: Oracle9i Enterprise Edition Release=20
9.2.0.7.0
  >>   - 64bit
  >>  > Production
  >>  >         Python 2.2.2 (#10, Mar 19 2003, 14:11:47)
  >>  >
  >>  > When manipulating clobs in the database I occasionally got an Oracle
  >>   error:
  >>  >
  >>  >         OCI-21500: internal error code, arguments: [nnnnn], [], [], [],
  >>   [], [], [], []
  >>  >
  >>  > I have a test program that can now reproduce the problem at will, by
  >>   repeatedly
  >>  > inserting, selecting and deleting
  >>  > on a table containing a clob from several threads. The error output
  >>   looks like
  >>  > this:
  >>  >
  >>  > OCI-21500: internal error code, arguments: [17099], [], [], [], [], [],
  >>   [], []
  >>  > Errors in file :
  >>  > OCI-21500: internal error code, arguments: [17099], [], [], [], [], [],
  >>   [], []
  >>  >
  >>  > ----- Call Stack Trace -----
  >>  > NOTE: <PLT>+offset is used to represent that the
  >>  >       function being called is offset bytes from
  >>  >       the _PROCEDURE_LINKAGE_TABLE_.
  >>  > calling              call     entry                argument values in
  >>   hex
  >>  > location             type     point                (? means dubious
  >>   value)
  >>  > -------------------- -------- --------------------
  >>   ----------------------------
  >>  > Segmentation Fault(coredump)
  >>  >
  >>  > Note that Oracle coredumps trying to print the stack trace.
  >>  >
  >>  > Change the data type from clob to varchar, and the problem disappears.
  >>  >
  >>  > I can also get rid of the problem by opening connections discreetly
  >>   instead of
  >>  > using the
  >>  > cx_Oracle.SessionPool object, which surprised me rather.
  >>  >
  >>  > I am currently looking at the SessionPool, and clob object code in
  >>   cx_Oracle
  >>  > (Sadly, I am no expert with Python extensions),  maybe there is some
  >>   issue with
  >>  > reference counts?
  >>  >
  >>  > Any advice would be gratefully accepted.....
  >>  >
  >>  > The test program and sql script is attached to this e-mail
  >>   (thread_test_clob.py
  >>  > and tables_clob.sql)
  >>  >
  >>  > Thanks in advance...
  >>  >
  >>  > Roger
  >>  >
  >>  >
  >>  =20