Re: [cx-oracle-users] Oracle crash with CLOB and threading
Brought to you by:
atuining
Menu
▾
▴
Re: [cx-oracle-users] Oracle crash with CLOB and threading
|
From: Anthony T. <ant...@gm...> - 2007-02-02 14:52:13
|
On 2/2/07, Roger Wenham <rog...@to...> wrote: > Thanks for trying the program. You're welcome. I like to eliminate problems such as the one you discovered if I can at all do so. > 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 > manipulation (BUS_ADRALN an alignment problem). > > I spent some time tracking the problem, and finally found it to be the retrieval of > named variables, the PyDict_Next() call that was puking. I consulted the python > documentation and everything looked OK, looking in the python header file > though showed the second parameter to PyDict_Next() (the counter) was not integer, > 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 > course. Yes, I am aware of this problem. Its only a problem in 64-bit land, of course. I have made the necessary changes and intend to release it soon. I have been intending to release it for some time already but simply haven't found the necessary time to do so -- and there are a couple of other things I would like to address first. > 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. Correct. > 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 > now (20 instead of 10). Interesting. I should maybe try with a higher number of threads as well. Note that someone else discovered a problem with massive numbers of connects and disconnects. I don't think they were using session pooling, though. The solution for that will be in the next release as well. Note that the workaround was to avoid calling close() on the connection and instead let the normal reference counting mechanism close and free the connection as needed. > 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. Hmm, unless you have a specific suggestion to look at I'm not sure that is going to help since I can't reproduce the problem. > I would like to go further with this, but I have a couple of pressing jobs that need to be done, > 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. Understood. I'm not sure I'll have the time as well but I'll keep it in mind. > 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 You might want to indicate specific versions of both the client and the server. Occasionallly this information is critical. :-) > 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 > 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 > >> > > >> > > >> > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > cx-oracle-users mailing list > cx-...@li... > https://lists.sourceforge.net/lists/listinfo/cx-oracle-users > |
