cx-oracle-users — Primary discussion list for users (and developers) of cx_Oracle

Re: [cx-oracle-users] callproc and ref cursors.-

[Jim B. <jb...@zy...>]

SGVyZSdzIGFuIGV4YW1wbGUgYmFzZWQgb24gVG9tIEt5dGUncyBhcnRpY2xlIG9uIHdvcmtpbmcg
d2l0aCBzdG9yZWQKcHJvY2VkdXJlcyBhbmQgZnVuY3Rpb25zIHdpdGggcmVmY3Vyc29ycyBpbiB2
YXJpb3VzIGxhbmd1YWdlcywgYmVzaWRlcwpQeXRob24gKGh0dHA6Ly9hc2t0b20ub3JhY2xlLmNv
bS90a3l0ZS9SZXN1bHRTZXRzL2luZGV4Lmh0bWwgKS4gIFJlZmVyIHRvCnRoZSBhcnRpY2xlIGZv
ciB0aGUgbmVjZXNzYXJ5IGV4YW1wbGUgRERMLgoKSSB3YXMgZ29pbmcgdG8gYXNrIFRvbSB0byBp
bmNsdWRlIHRoZSBmb2xsb3dpbmcgZm9yIFB5dGhvbiwgYnV0IGhlIGFsd2F5cwpzZWVtIHRvIGhh
dmUgdGhlICIqU29ycnkqIEkgaGF2ZSBhIGxhcmdlIGJhY2tsb2cgcmlnaHQgbm93LCBwbGVhc2Ug
YXNrIGEKcXVlc3Rpb24gbGF0ZXIiIG1lc3NhZ2UgdXAuCgotIEppbQoKaW1wb3J0IGN4X09yYWNs
ZQoKc2Vzc2lvbiA9IGN4X09yYWNsZS5jb25uZWN0KCJzY290dC90aWdlciIpCgojIGZpcnN0IG1h
a2UgYSBjdXJzb3IgdGhhdCB3ZSBjYW4gdXNlIHRvIGNhbGwgc3RvcmVkIHByb2NlZHVyZXMgYW5k
CiMgZnVuY3Rpb25zCgpjID0gc2Vzc2lvbi5jdXJzb3IoKQoKIyBjeF9PcmFjbGUgY2FuJ3QgZGV0
ZXJtaW5lIHRoZSByZXR1cm4gdHlwZSBmb3IgdXMgaW4gYWR2YW5jZSBvZiB0aGUKIyBtZXRob2Qg
Y2FsbCwgc28gd2UgaGF2ZSB0byBzZXQgaXQgdG8gd2hhdCBpdCBpcywgaW4gdGhpcyBjYXNlIHRo
ZSB0eXBlCiMgY3hfT3JhY2xlLkNVUlNPUgoKbGlzdF9lbXBfcmVmY3Vyc29yID0gYy5jYWxsZnVu
Yygic3BfbGlzdEVtcCIsIHJldHVyblR5cGU9Y3hfT3JhY2xlLkNVUlNPUikKcHJpbnQgbGlzdChs
aXN0X2VtcF9yZWZjdXJzb3IpCgojIGFzIHdlIHNhdyBhYm92ZSwgYSByZWZjdXJzb3IgaXMganVz
dCBhIHJlZ3VsYXIgY3Vyc29yLCBzbyBtYWtlIG9uZQojIGZvciB0aGUgaW4tb3V0IHBhcmFtZXRl
cgoKYW5vdGhlcl9saXN0X2VtcF9yZWZjdXJzb3IgPSBzZXNzaW9uLmN1cnNvcigpCgojIFRoZSBt
ZXRob2QgY2FsbHByb2MoKSByZXR1cm5zIGFsbCBwYXJhbWV0ZXJzIGFzIGEgbGlzdCwgc3VwcG9y
dGluZwojICpvdXQqIGFuZCAqaW4tb3V0KiwgYnV0IHdlIGFyZSBiaW5kaW5nIHRvCiMgYGFub3Ro
ZXJfbGlzdF9lbXBfcmVmY3Vyc29yYCBhbnl3YXksIHNvIGZvciB0aGlzIGNhc2UsIGp1c3QgaWdu
b3JlCiMgdGhlIHJldHVybiB2YWx1ZQoKYy5jYWxscHJvYygiZ2V0ZW1wcyIsIHBhcmFtZXRlcnM9
W2Fub3RoZXJfbGlzdF9lbXBfcmVmY3Vyc29yXSkKcHJpbnQgbGlzdChhbm90aGVyX2xpc3RfZW1w
X3JlZmN1cnNvcikKCk9uIDMvMjkvMDcsIE1hcmlhbm8gTWFyYSA8bW1hcmFAZmliZXJ0ZWwuY29t
LmFyPiB3cm90ZToKPgo+ICBQYXVsIE1vb3JlIGVzY3JpYmnDszoKPgo+IEhpLCBQYXVsLiBUaGFu
a3MgZm9yIHlvdXIgaW5wdXQuCj4KPiBUd28gcHJvYmxlbXMuIFlvdSd2ZSB1c2VkIHNlbGYucmMg
dHdpY2UgLSBvbmNlIGFzIGEgY3Vyc29yIGFuZCBvbmNlIGFzCj4gYSBtZXRob2QuCj4KPiAgWWVh
aCwgc29ycnkgZm9yIHRoYXQsIGp1c3QgdHJ5aW5nIHRvIGZpbmQgaXQgdGhhdCB3YXMgd2hhdCBB
bnRob255IG1lYW50Lgo+IE9idmlvdXNseSBpdCB3YXNuJ3QuCj4KPiAgVHJ5IHRoaXMgKHVudGVz
dGVkKToKPgo+ICAgICBjbGFzcyB1dGkob2JqZWN0KToKPgo+ICAgLi4uICAgICBkZWYgX19pbml0
X18oc2VsZiwgY29ubik6Cj4gLi4uICAgICAgICAgc2VsZi5jdXIgPSBjb25uLmN1cnNvcigpCj4g
Li4uICAgICBkZWYgcmMoc2VsZik6Cj4gLi4uICAgICAgICAgclNldCA9IHNlbGYuY3VyLmNhbGxw
cm9jKCJ0ZXN0aW5nX3JjLnByb2NfcmMiLCAoMTQxLAo+IC4uLiAgICAgICAgIDE2MiwgNCwgZGF0
ZXRpbWUuZGF0ZXRpbWUoMjAwNiwgMiwgMTMsIDAsIDAsIDApLAo+IC4uLiAgICAgICAgIGRhdGV0
aW1lLmRhdGV0aW1lKDIwMDcsIDIsIDEzLCAwLCAwLCAwKSwgMTEsIHNlbGYuY3VyKSkKPiAuLi4g
ICAgICAgICBmb3Igcm93IGluIHNlbGYuY3VyOgo+IC4uLiAgICAgICAgICAgICBwcmludCByb3cK
PiAuLi4KPgo+ICAgeDEgPSB1dGkoY29uKQo+IHgxLnJjKCkKPgo+Cj4gTm93IEknbSBnZXR0aW5n
Ogo+ID4+PiB4MS5yYygpCj4gVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxsIGxhc3QpOgo+ICAg
RmlsZSAiPHN0ZGluPiIsIGxpbmUgMSwgaW4gPwo+ICAgRmlsZSAiPHN0ZGluPiIsIGxpbmUgNSwg
aW4gcmMKPiBjeF9PcmFjbGUuRGF0YWJhc2VFcnJvcjogT1JBLTAxMDM2OiBpbGxlZ2FsIHZhcmlh
YmxlIG5hbWUvbnVtYmVyCj4KPiBBY2NvcmRpbmcgdG8gb2VyciBpdCBtZWFuczoKPgo+ICQgb2Vy
ciBvcmEgMTAzNgo+IDAxMDM2LCAwMDAwMCwgImlsbGVnYWwgdmFyaWFibGUgbmFtZS9udW1iZXIi
Cj4gLy8gKkNhdXNlOiBVbmFibGUgdG8gZmluZCBiaW5kIGNvbnRleHQgb24gdXNlciBzaWRlCj4g
Ly8gKkFjdGlvbjogTWFrZSBzdXJlIHRoYXQgdGhlIHZhcmlhYmxlIGJlaW5nIGJvdW5kIGlzIGlu
IHRoZSBzcWwKPiBzdGF0ZW1lbnQuCj4KPiBJIGNoYW5nZWQgdGhlIGRhdGV0aW1lLmRhdGV0aW1l
KCkgaW5wdXRzIHRvIG9yYS5EYXRlKCkganVzdCB0byBiZSBzdXJlIHRoZQo+IHByb2JsZW0gd2Fz
IG5vdCBzb21ld2hlcmUgZWxzZSBidXQgSSBnb3QgdGhlIGVycm9yIGFueXdheS4gU28gSSBndWVz
cyBJJ20KPiBzdGlsbCBpbiB0cm91YmxlIHdpdGggdGhlIHJlZiBjdXJzb3IuCj4KPiBUaGFua3Mg
Zm9yIHlvdXIgcGF0aWVuY2UgKGxlYXJuaW5nIG5vb2Igb3ZlciBoZXJlKSBhbmQgdGhhbmtzIGEg
bG90IGZvcgo+IGFueSB0aXAuCj4KPgo+Cj4KPgo+Cj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGFr
ZSBTdXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0aGUgRnV0dXJlIG9mIElUCj4gSm9pbiBT
b3VyY2VGb3JnZS5uZXQncyBUZWNoc2F5IHBhbmVsIGFuZCB5b3UnbGwgZ2V0IHRoZSBjaGFuY2Ug
dG8gc2hhcmUKPiB5b3VyCj4gb3BpbmlvbnMgb24gSVQgJiBidXNpbmVzcyB0b3BpY3MgdGhyb3Vn
aCBicmllZiBzdXJ2ZXlzLWFuZCBlYXJuIGNhc2gKPiBodHRwOi8vd3d3LnRlY2hzYXkuY29tL2Rl
ZmF1bHQucGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZDSUQ9REVWREVWCj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBjeC1vcmFjbGUtdXNl
cnMgbWFpbGluZyBsaXN0Cj4gY3gtb3JhY2xlLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+
IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2N4LW9yYWNsZS11
c2Vycwo+Cj4KCgotLSAKSmltIEJha2VyCmpiYWtlckBiaXZpby5iaXoK

Re: [cx-oracle-users] callproc and ref cursors.-

[Mariano M. <mm...@fi...>]

Paul Moore escribio':

Hi, Paul. Thanks for your input.
> Two problems. You've used self.rc twice - once as a cursor and once as
> a method. 
Yeah, sorry for that, just trying to find it that was what Anthony 
meant. Obviously it wasn't.

> Try this (untested):
>
>   
>>>> class uti(object):
>>>>         
> ...     def __init__(self, conn):
> ...         self.cur = conn.cursor()
> ...     def rc(self):
> ...         rSet = self.cur.callproc("testing_rc.proc_rc", (141,
> ...         162, 4, datetime.datetime(2006, 2, 13, 0, 0, 0),
> ...         datetime.datetime(2007, 2, 13, 0, 0, 0), 11, self.cur))
> ...         for row in self.cur:
> ...             print row
> ...
>   
>>>> x1 = uti(con)
>>>> x1.rc()
>>>>         

Now I'm getting:
 >>> x1.rc()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 5, in rc
cx_Oracle.DatabaseError: ORA-01036: illegal variable name/number

According to oerr it means:

$ oerr ora 1036
01036, 00000, "illegal variable name/number"
// *Cause: Unable to find bind context on user side
// *Action: Make sure that the variable being bound is in the sql statement.

I changed the datetime.datetime() inputs to ora.Date() just to be sure 
the problem was not somewhere else but I got the error anyway. So I 
guess I'm still in trouble with the ref cursor.

Thanks for your patience (learning noob over here) and thanks a lot for 
any tip.

Re: [cx-oracle-users] callproc and ref cursors.-

[Paul M. <p.f...@gm...>]

On 29/03/07, Mariano Mara <mm...@fi...> wrote:
> >>> class uti(object):
> ...     def __init__(self, conn):
> ...         self.cur = conn.cursor()
> ...         self.rc = conn.cursor()
> ...     def rc(self):
> ...         rSet = self.cur.callproc("testing_rc.proc_rc", (141,
> ...         162, 4, datetime.datetime(2006, 2, 13, 0, 0, 0),
> ...         datetime.datetime(2007, 2, 13, 0, 0, 0), 11, self.rc))
> ...         print rSet
> ...
> >>> x1 = uti(con)
> >>> x1.rc()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: 'OracleCursor' object is not callable

Two problems. You've used self.rc twice - once as a cursor and once as
a method. Then, you do "print rSet" when I guess you want to rpint the
rows of the cursor. You need to use the cursor method fetchall() to
get the data - or iterate over the cursor.

Try this (untested):

>>> class uti(object):
...     def __init__(self, conn):
...         self.cur = conn.cursor()
...     def rc(self):
...         rSet = self.cur.callproc("testing_rc.proc_rc", (141,
...         162, 4, datetime.datetime(2006, 2, 13, 0, 0, 0),
...         datetime.datetime(2007, 2, 13, 0, 0, 0), 11, self.cur))
...         for row in self.cur:
...             print row
...
>>> x1 = uti(con)
>>> x1.rc()

Paul.

Re: [cx-oracle-users] callproc and ref cursors.-

[Mariano M. <mm...@fi...>]

Anthony Tuininga escribió:
> Sure. You need to simply create a cursor and pass it directly to the
> procedure, not the type cx_Oracle.CURSOR. If that doesn't help, let me
> know and I'll try to be a little more precise. :-)
>   
Anthony, thanks for your quick reply.
I would accept your offering and I ask if you can be more precise.
When you say "/simply create a cursor/", how? On oracle's side?

I tried a few variations and for sure I messed it more than it was:

 >>> class uti(object):
...     def __init__(self, conn):
...         self.cur = conn.cursor()
...     def rc(self):
...         xrc = ora.CURSOR
...         rSet = self.cur.callproc("testing_rc.proc_rc", (141,
...         162, 4, datetime.datetime(2006, 2, 13, 0, 0, 0),
...         datetime.datetime(2007, 2, 13, 0, 0, 0), 11, xrc))
...         print rSet
...
 >>> x1 = uti(con)
 >>> x1.rc()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 6, in rc
cx_Oracle.NotSupportedError: Variable_TypeByValue(): unhandled data type 
type
 >>> class uti(object):
...     def __init__(self, conn):
...         self.cur = conn.cursor()
...         self.rc = conn.cursor()
...     def rc(self):
...         rSet = self.cur.callproc("testing_rc.proc_rc", (141,
...         162, 4, datetime.datetime(2006, 2, 13, 0, 0, 0),
...         datetime.datetime(2007, 2, 13, 0, 0, 0), 11, self.rc))
...         print rSet
...
 >>> x1 = uti(con)
 >>> x1.rc()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'OracleCursor' object is not callable

Thanks in advance.

Re: [cx-oracle-users] callproc and ref cursors.-

[Anthony T. <ant...@gm...>]

Sure. You need to simply create a cursor and pass it directly to the
procedure, not the type cx_Oracle.CURSOR. If that doesn't help, let me
know and I'll try to be a little more precise. :-)

On 3/28/07, Mariano Mara <mm...@fi...> wrote:
> Hi, good night.
>
> Sorry to bother you with this little question but I'm stuck in this
> error and I exhausted every option I could find without luck.
>  I'm trying to get the results of a weak ref cursor but I keep stumbling
> no matter what combination I use.
>  I'm using cx_Oracle 4.2 against an Oracle 10g R2 client, Ubuntu 6.10
> and Python 2.4.4c1
>
> Find below a (not) working example (one of the incarnations I tried):
>
> first the plsql code:
>
> create or replace package testing_rc
> is
>  type rc_typ is ref cursor;
>
>  procedure proc_rc(p1 in number, p2 in number,
>                   p3 in number, p4 in date,
>                   p5 in date, p6 in number,
>                   p7 out rc_typ);
> end;
> /
> create or replace package body testing_rc
> is
>  procedure proc_rc(p1 in number, p2 in number,
>                   p3 in number, p4 in date,
>                   p5 in date, p6 in number,
>                   p7 out rc_typ)
>  is
>  begin
>  open p7 for
>    select 1 uno, 2 dos, 3 tres from dual;
>  end proc_rc;
> end testing_rc;
> /
>
> now the python code:
>
> import cx_Oracle as ora
> import datetime
> con = ora.connect(u, p, d)
>
> class uti(object):
>     def __init__(self, conn):
>         self.cur = conn.cursor()
>
>     def rc(self):
>         rSet = self.cur.callproc("testing_rc.proc_rc", (141,
>         162, 4, datetime.datetime(2006, 2, 13, 0, 0, 0),
>         datetime.datetime(2007, 2, 13, 0, 0, 0), 11, ora.CURSOR))
>         print rSet
>
> x1 = uti(con)
> x1.rc()
>
> The error:
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "<stdin>", line 6, in rc
> cx_Oracle.NotSupportedError: Variable_TypeByValue(): unhandled data type
> type
>
> Can you guys suggest a way out?
>
> Thanks in advance.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] callproc and ref cursors.-

[Mariano M. <mm...@fi...>]

Hi, good night.

Sorry to bother you with this little question but I'm stuck in this 
error and I exhausted every option I could find without luck.
 I'm trying to get the results of a weak ref cursor but I keep stumbling 
no matter what combination I use.
 I'm using cx_Oracle 4.2 against an Oracle 10g R2 client, Ubuntu 6.10 
and Python 2.4.4c1

Find below a (not) working example (one of the incarnations I tried):

first the plsql code:

create or replace package testing_rc
is
 type rc_typ is ref cursor;

 procedure proc_rc(p1 in number, p2 in number,
                  p3 in number, p4 in date,
                  p5 in date, p6 in number,
                  p7 out rc_typ);
end;
/
create or replace package body testing_rc
is
 procedure proc_rc(p1 in number, p2 in number,
                  p3 in number, p4 in date,
                  p5 in date, p6 in number,
                  p7 out rc_typ)
 is
 begin
 open p7 for
   select 1 uno, 2 dos, 3 tres from dual;
 end proc_rc;
end testing_rc;
/

now the python code:

import cx_Oracle as ora
import datetime
con = ora.connect(u, p, d)

class uti(object):
    def __init__(self, conn):
        self.cur = conn.cursor()
   
    def rc(self):
        rSet = self.cur.callproc("testing_rc.proc_rc", (141,
        162, 4, datetime.datetime(2006, 2, 13, 0, 0, 0),
        datetime.datetime(2007, 2, 13, 0, 0, 0), 11, ora.CURSOR))
        print rSet

x1 = uti(con)
x1.rc()

The error:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 6, in rc
cx_Oracle.NotSupportedError: Variable_TypeByValue(): unhandled data type 
type

Can you guys suggest a way out?

Thanks in advance.

[cx-oracle-users] Compilation under Mac OS X

[Nicolas R. <nic...@ca...>]

Hi,

I'm trying to compile cx_Oracle under mac OS X 10.4.9

I have downloaded instantclient from Oracle and can connect to a  
remote Oracle database with sqlplus and using DeeBeex (using  
instantclient).

To compile cx_Oracle, I had to create a sym link for libclntsh.dylib. 
10.0 as libclntsh.dylib.

cx_Oracle compiles, but when I load the cx_oracle module into python  
(2.5), I have this error:

Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/cx_Oracle.so, 2): Symbol not found:  
_OCINumberFromInt
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/cx_Oracle.so
   Expected in: dynamic lookup


Anyone has a clue on what's happening ?

Thanks

nicolas

Re: [cx-oracle-users] seg faults appears to be oracle libraries not cx_oracle

[Anthony T. <ant...@gm...>]

Hmm, the line numbers provided do not correspond to line numbers in
the source code that I have. Did you make some changes? Are you
calling connection.close() at any point?

FYI, OCIStmtPrepare2() will __change__ the statement handle as needed.
That does not explain changes in the pointers to Python objects,
though. Something bizarre is definitely going on.... :-)

On 3/27/07, Nicholas Milkovits <nmi...@gm...> wrote:
> Following up on my recent posts about segmentation faults in apache2
> (prefork or worker) with mod python 3.3.1, python 2.5 and cx_oracle
> 4.3, I've moved from looking at coredumps to running apache under gdb
> with a script sending the requests.  It appears the seg fault is not
> in cx_oracle at all but in the underlying oracle library. The
> addresses for the cursor pointer are indeed the same between the calls
> to Cursor_Execute and Cursor_internalPrepare. It is not until after
> the segmention fault that the pointers appear to be different when
> looking at the backtrace.  Is it possible that the seg fault would
> cause the pointer values (self and statement in InternalPrepare, args
> and keywordArgs in Execute) to be incorrect in the coredumps and the
> backtraces?
>
> ---------About 50 successful requests that look like the 3 below--------------
>
> Breakpoint 3, Cursor_Execute (self=0xac0f6910, args=0x4a0550,
>     keywordArgs=0xac08d64c) at Cursor.c:1381
> 1381    in Cursor.c
> Continuing.
>
> Breakpoint 4, Cursor_InternalPrepare (self=0xac0f6910, statement=0x94ca820)
>     at Cursor.c:1055
> 1055    in Cursor.c
> Continuing.
>
> Breakpoint 3, Cursor_Execute (self=0xac0f6910, args=0x4a0550,
>     keywordArgs=0xac08d64c) at Cursor.c:1381
> 1381    in Cursor.c
> Continuing.
>
> Breakpoint 4, Cursor_InternalPrepare (self=0xac0f6910, statement=0xada9e0c8)
>     at Cursor.c:1055
> 1055    in Cursor.c
> Continuing.
>
> Breakpoint 3, Cursor_Execute (self=0xac0f6910, args=0x4a0550,
>     keywordArgs=0xac08d64c) at Cursor.c:1381
> 1381    in Cursor.c
> Continuing.
>
> Breakpoint 4, Cursor_InternalPrepare (self=0xac0f6910, statement=0x94caa00)
>     at Cursor.c:1055
> 1055    in Cursor.c
> Continuing.
> [Switching to Thread -1337578576 (LWP 3883)]
>
> Breakpoint 3, Cursor_Execute (self=0xac0f69c0, args=0x4a0550,
>     keywordArgs=0xac08d64c) at Cursor.c:1381
> 1381    in Cursor.c
> Continuing.
>
> Breakpoint 4, Cursor_InternalPrepare (self=0xac0f69c0, statement=0xac0b30e0)
>     at Cursor.c:1055
> 1055    in Cursor.c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xace22ba5 in kpureq2 ()
>    from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
> #1  0xacf01dc3 in OCIStmtPrepare2 ()
>    from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
> #2  0x061a18b3 in Cursor_InternalPrepare (self=0x9620428, statement=0x960a9f4)
>     at Cursor.c:1085
> 1085    in Cursor.c
> #3  0x061a286d in Cursor_Execute (self=0xac0f69c0, args=0x1774,
>     keywordArgs=0x960a9f4) at Cursor.c:1415
> 1415    in Cursor.c
> type:$1 = 0x62782c6 "OracleCursor"
> Continuing.
>
> Breakpoint 4, Cursor_InternalPrepare (self=0xac17fcd8, statement=0xacceb910)
>     at Cursor.c:1055
> 1055    in Cursor.c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xaceabbaf in kpureq2 ()
>    from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
> #0  0xaceabbaf in kpureq2 ()
>    from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
> #1  0xacf8adc3 in OCIStmtPrepare2 ()
>    from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
> #2  0x02f038b3 in Cursor_InternalPrepare (self=0x9939478, statement=0x993586c)
>     at Cursor.c:1085
> 1085    in Cursor.c
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] seg faults appears to be oracle libraries not cx_oracle

[Nicholas M. <nmi...@gm...>]

Following up on my recent posts about segmentation faults in apache2
(prefork or worker) with mod python 3.3.1, python 2.5 and cx_oracle
4.3, I've moved from looking at coredumps to running apache under gdb
with a script sending the requests.  It appears the seg fault is not
in cx_oracle at all but in the underlying oracle library. The
addresses for the cursor pointer are indeed the same between the calls
to Cursor_Execute and Cursor_internalPrepare. It is not until after
the segmention fault that the pointers appear to be different when
looking at the backtrace.  Is it possible that the seg fault would
cause the pointer values (self and statement in InternalPrepare, args
and keywordArgs in Execute) to be incorrect in the coredumps and the
backtraces?

---------About 50 successful requests that look like the 3 below--------------

Breakpoint 3, Cursor_Execute (self=0xac0f6910, args=0x4a0550,
    keywordArgs=0xac08d64c) at Cursor.c:1381
1381	in Cursor.c
Continuing.

Breakpoint 4, Cursor_InternalPrepare (self=0xac0f6910, statement=0x94ca820)
    at Cursor.c:1055
1055	in Cursor.c
Continuing.

Breakpoint 3, Cursor_Execute (self=0xac0f6910, args=0x4a0550,
    keywordArgs=0xac08d64c) at Cursor.c:1381
1381	in Cursor.c
Continuing.

Breakpoint 4, Cursor_InternalPrepare (self=0xac0f6910, statement=0xada9e0c8)
    at Cursor.c:1055
1055	in Cursor.c
Continuing.

Breakpoint 3, Cursor_Execute (self=0xac0f6910, args=0x4a0550,
    keywordArgs=0xac08d64c) at Cursor.c:1381
1381	in Cursor.c
Continuing.

Breakpoint 4, Cursor_InternalPrepare (self=0xac0f6910, statement=0x94caa00)
    at Cursor.c:1055
1055	in Cursor.c
Continuing.
[Switching to Thread -1337578576 (LWP 3883)]

Breakpoint 3, Cursor_Execute (self=0xac0f69c0, args=0x4a0550,
    keywordArgs=0xac08d64c) at Cursor.c:1381
1381	in Cursor.c
Continuing.

Breakpoint 4, Cursor_InternalPrepare (self=0xac0f69c0, statement=0xac0b30e0)
    at Cursor.c:1055
1055	in Cursor.c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xace22ba5 in kpureq2 ()
   from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
#1  0xacf01dc3 in OCIStmtPrepare2 ()
   from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
#2  0x061a18b3 in Cursor_InternalPrepare (self=0x9620428, statement=0x960a9f4)
    at Cursor.c:1085
1085	in Cursor.c
#3  0x061a286d in Cursor_Execute (self=0xac0f69c0, args=0x1774,
    keywordArgs=0x960a9f4) at Cursor.c:1415
1415	in Cursor.c
type:$1 = 0x62782c6 "OracleCursor"
Continuing.

Breakpoint 4, Cursor_InternalPrepare (self=0xac17fcd8, statement=0xacceb910)
    at Cursor.c:1055
1055	in Cursor.c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xaceabbaf in kpureq2 ()
   from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
#0  0xaceabbaf in kpureq2 ()
   from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
#1  0xacf8adc3 in OCIStmtPrepare2 ()
   from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
#2  0x02f038b3 in Cursor_InternalPrepare (self=0x9939478, statement=0x993586c)
    at Cursor.c:1085
1085	in Cursor.c

Re: [cx-oracle-users] cursor execute() seg faults under heavy load

[Nicholas M. <nmi...@gm...>]

Forgot to mention that the server is 10g (I believe) and the client is 10.2.0.

On 3/23/07, cx-...@li...
<cx-...@li...> wrote:
> Send cx-oracle-users mailing list submissions to
>         cx-...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> or, via email, send a message with subject or body 'help' to
>         cx-...@li...
>
> You can reach the person managing the list at
>         cx-...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cx-oracle-users digest..."
>
>
> Today's Topics:
>
>    1. cursor execute() seg faults under heavy load (Nicholas Milkovits)
>    2. Re: cursor execute() seg faults under heavy load
>       (Anthony Tuininga)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 23 Mar 2007 12:33:12 -0400
> From: "Nicholas Milkovits" <nmi...@gm...>
> Subject: [cx-oracle-users] cursor execute() seg faults under heavy
>         load
> To: cx-...@li...
> Message-ID:
>         <71a...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I have been running into an occasional segmentation fault when testing
> an apache2 + modpython 3.1 application. I have narrowed it down to the
> actual execute call on the cursor object. This only happens when
> testing under heavy loads.  Has anyone seen behavior like this before
> or have any idea what might be causing the problem? This happens with
> both cx_Oracle 4.2.1 and 4.3. Please note that apache is being run in
> prefork mode so the requests are being handled by single threaded
> child processes. Any thoughts or comments?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 23 Mar 2007 11:05:16 -0600
> From: "Anthony Tuininga" <ant...@gm...>
> Subject: Re: [cx-oracle-users] cursor execute() seg faults under heavy
>         load
> To: cx-...@li...
> Message-ID:
>         <703...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Nothing obvious comes to mind. We have used cx_Oracle with very heavy
> loads in both threaded and single threaded applications and never run
> into any difficulties. Another user did run into occasional segfaults
> but this was during object cleanup, not cursor.execute(). This problem
> has also been addressed in 4.3 so it is not likely to be related. You
> might want to specify which version of Python, which version of the
> Oracle server and which version of the Oracle client you are using as
> well.
>
> The only thing I can suggest is, even though you in a single threaded
> application, try setting "threaded = True" in the constructor of your
> connection. This will reduce performance by about 10-15% but may work.
>
> Do you have a backtrace from gdb that indicates the problem is
> occurring in cursor.execute()? Do you have a small script that can
> consistently replicate the problem? Anything else you can think of
> that might help me diagnose the problem or replicate it here?
>
> On 3/23/07, Nicholas Milkovits <nmi...@gm...> wrote:
> > I have been running into an occasional segmentation fault when testing
> > an apache2 + modpython 3.1 application. I have narrowed it down to the
> > actual execute call on the cursor object. This only happens when
> > testing under heavy loads.  Has anyone seen behavior like this before
> > or have any idea what might be causing the problem? This happens with
> > both cx_Oracle 4.2.1 and 4.3. Please note that apache is being run in
> > prefork mode so the requests are being handled by single threaded
> > child processes. Any thoughts or comments?
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > cx-oracle-users mailing list
> > cx-...@li...
> > https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> >
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> ------------------------------
>
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>
> End of cx-oracle-users Digest, Vol 10, Issue 5
> **********************************************
>

Re: [cx-oracle-users] cursor execute() seg faults under heavy load

[Nicholas M. <nmi...@gm...>]

I will try passing threaded=True in the connection constructor today
and see if that helps. This application is intended to provide restful
webservices, basically a thin database abstraction layer. The script I
have to test is a ruby script which randomly picks 1 of the urls to
call, waits a some time and makes another call. The seg faults  always
occur regardless of how much delay I put between the calls. The longer
the delay the longer (the more calls) it will take but on average I
see at least one seg fault per 100 calls. Each url maps on to a
different database action. Some of the queries are selects, some
inserts, and some updates. Every service except for 3 runs only 1
query. The other 3 actually perform 4 or 5 statement transactions. The
segmentation faults are not limited to any one or group of queries and
I have not noticed any patterns. I have provided a gdb backtrace
below. It appears as though the statement and cursors objects have
negative reference count for some reason.
Your help is greatly appreciated.


Apache 2.0.59 (Tried running under both Prefork and Worker)
mod_python 3.3.1
Python 2.5
cx_Oracle 4.3

#0  0xad7c4ba5 in kpureq2 ()
   from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
#1  0xad8a3dc3 in OCIStmtPrepare2 ()
   from /usr/vendor/pkg/oracle/product/10.2.0/lib/libclntsh.so.10.1
#2  0x06bbe873 in Cursor_InternalPrepare (self=0x9888ec8, statement=0x997dddc)
    at Cursor.c:1073
#3  0x06bbf82d in Cursor_Execute (self=0xaca73f40, args=0x1774,
    keywordArgs=0x997dddc) at Cursor.c:1397
#4  0x00674561 in PyCFunction_Call (func=0xacaa728c, arg=0xad61348c,
    kw=0xae30910c) at Objects/methodobject.c:77
#5  0x006a9ff6 in PyEval_EvalFrameEx (f=0x986e22c, throwflag=0)
    at Python/ceval.c:3566
#6  0x006aaff3 in PyEval_EvalFrameEx (f=0x986dd54, throwflag=0)
    at Python/ceval.c:3652
#7  0x006aaff3 in PyEval_EvalFrameEx (f=0x984d3d4, throwflag=0)
    at Python/ceval.c:3652
#8  0x006aaff3 in PyEval_EvalFrameEx (f=0x98196bc, throwflag=0)
    at Python/ceval.c:3652
#9  0x006aaff3 in PyEval_EvalFrameEx (f=0x97f3b0c, throwflag=0)
    at Python/ceval.c:3652

#4  0x00674561 in PyCFunction_Call (func=0xacaa728c, arg=0xad61348c,
    kw=0xae30910c) at Objects/methodobject.c:77
77	Objects/methodobject.c: No such file or directory.
	in Objects/methodobject.c
p *arg
$3 = {ob_refcnt = 1, ob_type = 0x73f8e0}
p * kw
$4 = {ob_refcnt = 6004, ob_type = 0x1778}

#3  0x06bbf82d in Cursor_Execute (self=0xaca73f40, args=0x1774,
    keywordArgs=0x997dddc) at Cursor.c:1397
1397	Cursor.c: No such file or directory.
	in Cursor.c
p *self
$1 = {ob_refcnt = 2, ob_type = 0x6cae740, handle = 0x0,
  connection = 0xaca49410, environment = 0xaca3dc80, statement = 0xacaa9da0,
  bindVariables = 0x0, fetchVariables = 0x0, arraySize = 1,
  bindArraySize = 1, fetchArraySize = 0, numbersAsStrings = 0,
  setInputSizes = 0, outputSize = -1, outputSizeColumn = -1, rowCount = 0,
  actualRows = 0, rowNum = 0, statementType = -1, isDML = 0, isOpen = 1,
  isOwned = 0}
p *self
Cannot access memory at address 0x1774
p *keywordsArgs
$2 = {ob_refcnt = -118891829, ob_type = 0x300

#2  0x06bbe873 in Cursor_InternalPrepare (self=0x9888ec8, statement=0x997dddc)
    at Cursor.c:1073
1073	Cursor.c: No such file or directory.
	in Cursor.c
p *self
$5 = {ob_refcnt = -118891829, ob_type = 0x201, handle = 0x98a8040,
  connection = 0x98a8040, environment = 0x0, statement = 0x0,
  bindVariables = 0x0, fetchVariables = 0x0, arraySize = 0,
  bindArraySize = 0, fetchArraySize = 0, numbersAsStrings = 0,
  setInputSizes = 0, outputSize = 0, outputSizeColumn = 0,
  rowCount = 159945596, actualRows = 0, rowNum = 0, statementType = 0,
  isDML = 0, isOpen = 0, isOwned = 0}
p *statement
$6 = {ob_refcnt = -118891829, ob_type = 0x300


On 3/23/07, cx-...@li...
<cx-...@li...> wrote:
> Send cx-oracle-users mailing list submissions to
>         cx-...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> or, via email, send a message with subject or body 'help' to
>         cx-...@li...
>
> You can reach the person managing the list at
>         cx-...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cx-oracle-users digest..."
>
>
> Today's Topics:
>
>    1. cursor execute() seg faults under heavy load (Nicholas Milkovits)
>    2. Re: cursor execute() seg faults under heavy load
>       (Anthony Tuininga)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 23 Mar 2007 12:33:12 -0400
> From: "Nicholas Milkovits" <nmi...@gm...>
> Subject: [cx-oracle-users] cursor execute() seg faults under heavy
>         load
> To: cx-...@li...
> Message-ID:
>         <71a...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I have been running into an occasional segmentation fault when testing
> an apache2 + modpython 3.1 application. I have narrowed it down to the
> actual execute call on the cursor object. This only happens when
> testing under heavy loads.  Has anyone seen behavior like this before
> or have any idea what might be causing the problem? This happens with
> both cx_Oracle 4.2.1 and 4.3. Please note that apache is being run in
> prefork mode so the requests are being handled by single threaded
> child processes. Any thoughts or comments?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 23 Mar 2007 11:05:16 -0600
> From: "Anthony Tuininga" <ant...@gm...>
> Subject: Re: [cx-oracle-users] cursor execute() seg faults under heavy
>         load
> To: cx-...@li...
> Message-ID:
>         <703...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Nothing obvious comes to mind. We have used cx_Oracle with very heavy
> loads in both threaded and single threaded applications and never run
> into any difficulties. Another user did run into occasional segfaults
> but this was during object cleanup, not cursor.execute(). This problem
> has also been addressed in 4.3 so it is not likely to be related. You
> might want to specify which version of Python, which version of the
> Oracle server and which version of the Oracle client you are using as
> well.
>
> The only thing I can suggest is, even though you in a single threaded
> application, try setting "threaded = True" in the constructor of your
> connection. This will reduce performance by about 10-15% but may work.
>
> Do you have a backtrace from gdb that indicates the problem is
> occurring in cursor.execute()? Do you have a small script that can
> consistently replicate the problem? Anything else you can think of
> that might help me diagnose the problem or replicate it here?
>
> On 3/23/07, Nicholas Milkovits <nmi...@gm...> wrote:
> > I have been running into an occasional segmentation fault when testing
> > an apache2 + modpython 3.1 application. I have narrowed it down to the
> > actual execute call on the cursor object. This only happens when
> > testing under heavy loads.  Has anyone seen behavior like this before
> > or have any idea what might be causing the problem? This happens with
> > both cx_Oracle 4.2.1 and 4.3. Please note that apache is being run in
> > prefork mode so the requests are being handled by single threaded
> > child processes. Any thoughts or comments?
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > cx-oracle-users mailing list
> > cx-...@li...
> > https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> >
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> ------------------------------
>
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>
> End of cx-oracle-users Digest, Vol 10, Issue 5
> **********************************************
>

Re: [cx-oracle-users] SPAM: cursor execute() seg faults under heavy load

[matilda m. <ma...@gr...>]

Hi Nicholas,

you know that your question is very generic.=20
So I really can only give hints for narrowing the bug/problem:

1) You have to tell more about the apache/mod_perl/Oracle stack you use.
Versions, distribution, self compiled or not, etc.

2) What load do you mean? Apache load or database load or are both
components on the same machine?

3) In which point of the child process lifecycle does this
segmentation fault occure? Directly after forking or after
using a child for some requests? (Memory leak?)

4) What other mod_xxx are you using or loading even when not using?
Background: We had segfaults exactly after trying to fulfill a
Oracle request via perl DBI (mod_perl) on a child process which
served a php request on a mysql database before. We never found
which part caused the segfault. We just compiled all components
with newest versions on our own. (Yes, it's ugly, especially if
you have a distribution). So my hint: Throw anything in this
stack away what you don't need.

5) I read you're in a test environment. So, enable Oracle tracing
on the mod_perl sessions and see how many requests are served before
the client dies. Look on the statments and on the session/connection
creation pattern.

6) As Anthony said. Enable writing of core dump files and look at the
stack trace dump with gdb. Where does the process die? Is it really=20
cx_Oracle?

7) It's possible that the usage of cx_Oracle is only the catayst
for raising the segfault caused by another component.

8) mod_perl 3.1 is rather old. If I look at the change log, i see
there are some bugs related to memory handling. So, why do you
use this old version?

9) Apache on its own had some bugs. So check this version too.

10) Beside of this thoughts: You must give the people here in
this mailing list a feeling of=20
a) What overall knowledge do you have?
b) What investigations have you done until now?
c) What conclusions led to the point that you think the problem
is caused by cx_Oracle and not by any other component of the
whole system?

I'm interested to know if you find the bug. Probably my thoughts
help you to dig in the right direction.


Best regards
Andreas Mock



>>> "Nicholas Milkovits" <nmi...@gm...> 03/23/07 5:33 PM >>>
I have been running into an occasional segmentation fault when testing
an apache2 + modpython 3.1 application. I have narrowed it down to the
actual execute call on the cursor object. This only happens when
testing under heavy loads.  Has anyone seen behavior like this before
or have any idea what might be causing the problem? This happens with
both cx_Oracle 4.2.1 and 4.3. Please note that apache is being run in
prefork mode so the requests are being handled by single threaded
child processes. Any thoughts or comments?

Re: [cx-oracle-users] cursor execute() seg faults under heavy load

[Anthony T. <ant...@gm...>]

Nothing obvious comes to mind. We have used cx_Oracle with very heavy
loads in both threaded and single threaded applications and never run
into any difficulties. Another user did run into occasional segfaults
but this was during object cleanup, not cursor.execute(). This problem
has also been addressed in 4.3 so it is not likely to be related. You
might want to specify which version of Python, which version of the
Oracle server and which version of the Oracle client you are using as
well.

The only thing I can suggest is, even though you in a single threaded
application, try setting "threaded = True" in the constructor of your
connection. This will reduce performance by about 10-15% but may work.

Do you have a backtrace from gdb that indicates the problem is
occurring in cursor.execute()? Do you have a small script that can
consistently replicate the problem? Anything else you can think of
that might help me diagnose the problem or replicate it here?

On 3/23/07, Nicholas Milkovits <nmi...@gm...> wrote:
> I have been running into an occasional segmentation fault when testing
> an apache2 + modpython 3.1 application. I have narrowed it down to the
> actual execute call on the cursor object. This only happens when
> testing under heavy loads.  Has anyone seen behavior like this before
> or have any idea what might be causing the problem? This happens with
> both cx_Oracle 4.2.1 and 4.3. Please note that apache is being run in
> prefork mode so the requests are being handled by single threaded
> child processes. Any thoughts or comments?
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] cursor execute() seg faults under heavy load

[Nicholas M. <nmi...@gm...>]

I have been running into an occasional segmentation fault when testing
an apache2 + modpython 3.1 application. I have narrowed it down to the
actual execute call on the cursor object. This only happens when
testing under heavy loads.  Has anyone seen behavior like this before
or have any idea what might be causing the problem? This happens with
both cx_Oracle 4.2.1 and 4.3. Please note that apache is being run in
prefork mode so the requests are being handled by single threaded
child processes. Any thoughts or comments?

Re: [cx-oracle-users] SessionPool_Init crashing on cxOracle-4.3-win32-python2.5-Oracle10g-InstantClient 10.2.3

[Anthony T. <ant...@gm...>]

Great! Thanks for the tip. I've checked that in now.

On 3/20/07, Amaury Forgeot d'Arc <ama...@gm...> wrote:
> Hello,
>
> Anthony Tuininga wrote:
> > I'll take your word for it. Some compilers are indeed more picky than
> > others and since your suggested code works for the picky one as well
> > as the less picky one I'll take it. :-)
> >
> > Here is the change I propose to make. Can you confirm that it works
> > for you as well? Thank you.
> >
> > --- SessionPool.c       14 Aug 2006 20:53:08 -0000      1.15
> > +++ SessionPool.c       20 Mar 2007 15:03:09 -0000
> > @@ -171,8 +171,8 @@
> >      const char *username, *password, *dsn, *poolName;
> >      unsigned minSessions, maxSessions, sessionIncrement;
> >      PyTypeObject *connectionType;
> > +    int threaded, getModeArg;
> >      PyObject *threadedObj;
> > -    int threaded;
> >      sword status;
> >      ub1 getMode;
> >
> > @@ -184,12 +184,12 @@
> >      threaded = 0;
> >      threadedObj = NULL;
> >      connectionType = &g_ConnectionType;
> > -    getMode = OCI_SPOOL_ATTRVAL_NOWAIT;
> > +    getModeArg = OCI_SPOOL_ATTRVAL_NOWAIT;
> >      if (!PyArg_ParseTupleAndKeywords(args, keywordArgs, "s#s#s#iii|OOi",
> >              keywordList, &username, &usernameLength, &password,
> >              &passwordLength, &dsn, &dsnLength, &minSessions,
> >              &maxSessions, &sessionIncrement, &connectionType, &threadedObj,
> > -            &getMode))
> > +            &getModeArg))
> >          return -1;
> >      if (!PyType_Check(connectionType)) {
> >          PyErr_SetString(g_ProgrammingErrorException,
> > @@ -260,6 +260,7 @@
> >          return -1;
> >
> >      // set the mode on the pool
> > +    getMode = (ub1) getModeArg;
> >      status = OCIAttrSet(self->handle, OCI_HTYPE_SPOOL, (dvoid*) &getMode, 0,
> >              OCI_ATTR_SPOOL_GETMODE, self->environment->errorHandle);
> >      if (Environment_CheckForError(self->environment, status,
> >
> >
>
> May I suggest another way to get the correct behaviour?
> the 'b' format code is supposed to fill an unsigned char:
>       if (!PyArg_ParseTupleAndKeywords(args, keywordArgs, "s#s#s#iii|OOi",
> becomes
>       if (!PyArg_ParseTupleAndKeywords(args, keywordArgs, "s#s#s#iii|OOb",
> Only one letter to change!
>
> --
> Amaury Forgeot d'Arc
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

Re: [cx-oracle-users] SessionPool_Init crashing on cxOracle-4.3-win32-python2.5-Oracle10g-InstantClient 10.2.3

[Amaury F. d'A. <ama...@gm...>]

Hello,

Anthony Tuininga wrote:
> I'll take your word for it. Some compilers are indeed more picky than
> others and since your suggested code works for the picky one as well
> as the less picky one I'll take it. :-)
>
> Here is the change I propose to make. Can you confirm that it works
> for you as well? Thank you.
>
> --- SessionPool.c       14 Aug 2006 20:53:08 -0000      1.15
> +++ SessionPool.c       20 Mar 2007 15:03:09 -0000
> @@ -171,8 +171,8 @@
>      const char *username, *password, *dsn, *poolName;
>      unsigned minSessions, maxSessions, sessionIncrement;
>      PyTypeObject *connectionType;
> +    int threaded, getModeArg;
>      PyObject *threadedObj;
> -    int threaded;
>      sword status;
>      ub1 getMode;
>
> @@ -184,12 +184,12 @@
>      threaded = 0;
>      threadedObj = NULL;
>      connectionType = &g_ConnectionType;
> -    getMode = OCI_SPOOL_ATTRVAL_NOWAIT;
> +    getModeArg = OCI_SPOOL_ATTRVAL_NOWAIT;
>      if (!PyArg_ParseTupleAndKeywords(args, keywordArgs, "s#s#s#iii|OOi",
>              keywordList, &username, &usernameLength, &password,
>              &passwordLength, &dsn, &dsnLength, &minSessions,
>              &maxSessions, &sessionIncrement, &connectionType, &threadedObj,
> -            &getMode))
> +            &getModeArg))
>          return -1;
>      if (!PyType_Check(connectionType)) {
>          PyErr_SetString(g_ProgrammingErrorException,
> @@ -260,6 +260,7 @@
>          return -1;
>
>      // set the mode on the pool
> +    getMode = (ub1) getModeArg;
>      status = OCIAttrSet(self->handle, OCI_HTYPE_SPOOL, (dvoid*) &getMode, 0,
>              OCI_ATTR_SPOOL_GETMODE, self->environment->errorHandle);
>      if (Environment_CheckForError(self->environment, status,
>
>

May I suggest another way to get the correct behaviour?
the 'b' format code is supposed to fill an unsigned char:
      if (!PyArg_ParseTupleAndKeywords(args, keywordArgs, "s#s#s#iii|OOi",
becomes
      if (!PyArg_ParseTupleAndKeywords(args, keywordArgs, "s#s#s#iii|OOb",
Only one letter to change!

-- 
Amaury Forgeot d'Arc

Re: [cx-oracle-users] SessionPool_Init crashing on cxOracle-4.3-win32-python2.5-Oracle10g-InstantClient 10.2.3

[Anthony T. <ant...@gm...>]

I'll take your word for it. Some compilers are indeed more picky than
others and since your suggested code works for the picky one as well
as the less picky one I'll take it. :-)

Here is the change I propose to make. Can you confirm that it works
for you as well? Thank you.

--- SessionPool.c       14 Aug 2006 20:53:08 -0000      1.15
+++ SessionPool.c       20 Mar 2007 15:03:09 -0000
@@ -171,8 +171,8 @@
     const char *username, *password, *dsn, *poolName;
     unsigned minSessions, maxSessions, sessionIncrement;
     PyTypeObject *connectionType;
+    int threaded, getModeArg;
     PyObject *threadedObj;
-    int threaded;
     sword status;
     ub1 getMode;

@@ -184,12 +184,12 @@
     threaded = 0;
     threadedObj = NULL;
     connectionType = &g_ConnectionType;
-    getMode = OCI_SPOOL_ATTRVAL_NOWAIT;
+    getModeArg = OCI_SPOOL_ATTRVAL_NOWAIT;
     if (!PyArg_ParseTupleAndKeywords(args, keywordArgs, "s#s#s#iii|OOi",
             keywordList, &username, &usernameLength, &password,
             &passwordLength, &dsn, &dsnLength, &minSessions,
             &maxSessions, &sessionIncrement, &connectionType, &threadedObj,
-            &getMode))
+            &getModeArg))
         return -1;
     if (!PyType_Check(connectionType)) {
         PyErr_SetString(g_ProgrammingErrorException,
@@ -260,6 +260,7 @@
         return -1;

     // set the mode on the pool
+    getMode = (ub1) getModeArg;
     status = OCIAttrSet(self->handle, OCI_HTYPE_SPOOL, (dvoid*) &getMode, 0,
             OCI_ATTR_SPOOL_GETMODE, self->environment->errorHandle);
     if (Environment_CheckForError(self->environment, status,


On 3/19/07, Aris Motas <ari...@gm...> wrote:
>
> Whenever we create a new SessionPool with getmode specified, my
> apache/mod-python crashes.
> Looking through the code in SessionPool_Init, I think I found the cause:
>
> The getMode local variable was declare as a ub1, but in the call to
> PyArg_ParseTupleAndKeywords, the getmode gets mapped to an int.  This could
> overwrite the stack variable as it is only allocated one-byte (AFAIK, mvc7.1
> compiled with full optimization Ox can  be really sensitive on local
> variable types).
>
> To overcome this issue, I changed the type from ub1 to int and then I
> declared another variable of type ub1 which I used as the variable for the
> OCIAttrSet call:
>
> 178:    int getMode = 0;
> 179:   ub1 ub1getmode = 0;
>
>
> 264:    // set the mode on the pool
> 265:    ub1getmode = (ub1)getMode;
> 266:    status = OCIAttrSet(self->handle, OCI_HTYPE_SPOOL, (dvoid*)
> &ub1getmode, 0,
>
> After rebuilding cx_Oracle, the crashes disappeared.
>
> Can anyone on  development verify this bugfix and check it in for the next
> version, please?
>
> Cheers,
> Aris
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>

[cx-oracle-users] SessionPool_Init crashing on cxOracle-4.3-win32-python2.5-Oracle10g-InstantClient 10.2.3

[Aris M. <ari...@gm...>]

Whenever we create a new SessionPool with getmode specified, my
apache/mod-python crashes.
Looking through the code in SessionPool_Init, I think I found the cause:

The getMode local variable was declare as a ub1, but in the call to
PyArg_ParseTupleAndKeywords, the getmode gets mapped to an int.  This could
overwrite the stack variable as it is only allocated one-byte (AFAIK,
mvc7.1compiled with full optimization Ox can  be really sensitive on
local
variable types).

To overcome this issue, I changed the type from ub1 to int and then I
declared another variable of type ub1 which I used as the variable for the
OCIAttrSet call:

178:    int getMode = 0;
179:   ub1 ub1getmode = 0;


264:    // set the mode on the pool
265:    ub1getmode = (ub1)getMode;
266:    status = OCIAttrSet(self->handle, OCI_HTYPE_SPOOL, (dvoid*)
&ub1getmode, 0,

After rebuilding cx_Oracle, the crashes disappeared.

Can anyone on  development verify this bugfix and check it in for the next
version, please?

Cheers,
Aris

Re: [cx-oracle-users] process killing and invalid sessions

[Nicholas M. <nmi...@gm...>]

We have moved to apache 2 worker mode in our development environment
which is what I am working with. But the problem is occurring in our
production environment were the services were originally written using
the prefork version of apache. I think I have tracked down the problem
to a circular reference which may be preventing the session pools from
being garbage collected.

On 3/19/07, cx-...@li...
<cx-...@li...> wrote:
> Send cx-oracle-users mailing list submissions to
>         cx-...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> or, via email, send a message with subject or body 'help' to
>         cx-...@li...
>
> You can reach the person managing the list at
>         cx-...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cx-oracle-users digest..."
>
>
> Today's Topics:
>
>    1. process killing and invalid sessions (Nicholas Milkovits)
>    2. Re: process killing and invalid sessions (Anthony Tuininga)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 19 Mar 2007 12:41:00 -0400
> From: "Nicholas Milkovits" <nmi...@gm...>
> Subject: [cx-oracle-users] process killing and invalid sessions
> To: cx-...@li...
> Message-ID:
>         <71a...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> If a process using cx_oracle gets killed, say by apache as it scales
> down the number of active child processes, does cx_oracle or the OCI
> layer know to send a message to the database saying that it is done
> with the session? My oracle db is keeping a lot of sessions open,
> marking them as invalid but never closing them as (I am told by my db
> guru friends) that it is waiting for the client to tell it to kill the
> session.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 19 Mar 2007 11:06:53 -0600
> From: "Anthony Tuininga" <ant...@gm...>
> Subject: Re: [cx-oracle-users] process killing and invalid sessions
> To: cx-...@li...
> Message-ID:
>         <703...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hmm, if the process running cx_Oracle is killed how can it do
> anything?? :-) On Linux and other Unix flavors you have the option of
> specifying a signal handler but cx_Oracle certainly has not done so.
> I'm not sure if Oracle has done so -- maybe someone else knows about
> that.
>
> You could switch to using threads instead of processes -- that would
> solve this problem but may not work for you.
>
> On 3/19/07, Nicholas Milkovits <nmi...@gm...> wrote:
> > If a process using cx_oracle gets killed, say by apache as it scales
> > down the number of active child processes, does cx_oracle or the OCI
> > layer know to send a message to the database saying that it is done
> > with the session? My oracle db is keeping a lot of sessions open,
> > marking them as invalid but never closing them as (I am told by my db
> > guru friends) that it is waiting for the client to tell it to kill the
> > session.
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > cx-oracle-users mailing list
> > cx-...@li...
> > https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
> >
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> ------------------------------
>
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
>
> End of cx-oracle-users Digest, Vol 10, Issue 3
> **********************************************
>

Re: [cx-oracle-users] process killing and invalid sessions

[Anthony T. <ant...@gm...>]

Hmm, if the process running cx_Oracle is killed how can it do
anything?? :-) On Linux and other Unix flavors you have the option of
specifying a signal handler but cx_Oracle certainly has not done so.
I'm not sure if Oracle has done so -- maybe someone else knows about
that.

You could switch to using threads instead of processes -- that would
solve this problem but may not work for you.

On 3/19/07, Nicholas Milkovits <nmi...@gm...> wrote:
> If a process using cx_oracle gets killed, say by apache as it scales
> down the number of active child processes, does cx_oracle or the OCI
> layer know to send a message to the database saying that it is done
> with the session? My oracle db is keeping a lot of sessions open,
> marking them as invalid but never closing them as (I am told by my db
> guru friends) that it is waiting for the client to tell it to kill the
> session.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] process killing and invalid sessions

[Nicholas M. <nmi...@gm...>]

If a process using cx_oracle gets killed, say by apache as it scales
down the number of active child processes, does cx_oracle or the OCI
layer know to send a message to the database saying that it is done
with the session? My oracle db is keeping a lot of sessions open,
marking them as invalid but never closing them as (I am told by my db
guru friends) that it is waiting for the client to tell it to kill the
session.

Re: [cx-oracle-users] Invalid handle after reconnecting

[Anthony T. <ant...@gm...>]

A couple of things come to mind:

1) You are not using threaded mode and you have multiple threads
accessing the same connection -- this can cause strange behavior. Use
threaded = True in the creation of your session pool if this is the
case.

2) You are releasing the connection explicitly rather than letting
that happen when the variable goes out of scope. Upgrade to version
4.3 in which a similar problem was resolved.

If that doesn't solve the problem then I'm not sure how much help I
can be. Perhaps someone else on this list has seen something similar
running Apache?

On 3/14/07, Nicholas Milkovits <nmi...@gm...> wrote:
> Hello,
>
> I have been experiencing a very strange problem with cx_oracle 4.2 and
> an oracle 9i r2 database.  I have a apache2 plus mod_python 3.1.4
> application.  Apache is running in prefork mode and 5 child process
> are being started. As requests come in if the process already has not
> established a persistent connection to the database it does so an
> stores it in a global variable so it is persisted between requests.
> Within a few minutes to an hour, one of the connections is guaranteed
> to raise a DatabaseError: Invalid Handle!.  Even if I delete the
> connection and reconnect I get this same error.  The connection is
> actually established through a sessionpool and I delete and recreate
> the entire sessionpool. Because we have not moved over to apache
> worker mode yet the pool min size is set at 1 and only one will ever
> be used as each child process is single threaded.  What could be
> causing this error and why doesn't a reconnect work? Any help would be
> appreciated.
>
> Thanks,
>
> Nick
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Invalid handle after reconnecting

[Nicholas M. <nmi...@gm...>]

Hello,

I have been experiencing a very strange problem with cx_oracle 4.2 and
an oracle 9i r2 database.  I have a apache2 plus mod_python 3.1.4
application.  Apache is running in prefork mode and 5 child process
are being started. As requests come in if the process already has not
established a persistent connection to the database it does so an
stores it in a global variable so it is persisted between requests.
Within a few minutes to an hour, one of the connections is guaranteed
to raise a DatabaseError: Invalid Handle!.  Even if I delete the
connection and reconnect I get this same error.  The connection is
actually established through a sessionpool and I delete and recreate
the entire sessionpool. Because we have not moved over to apache
worker mode yet the pool min size is set at 1 and only one will ever
be used as each child process is single threaded.  What could be
causing this error and why doesn't a reconnect work? Any help would be
appreciated.

Thanks,

Nick

Re: [cx-oracle-users] Antw: cx_Oracle 4.3

[Anthony T. <ant...@gm...>]

On 3/8/07, matilda matilda <ma...@gr...> wrote:
> Hi Anthony,
>
> thank you very much for the new release of cx_Oracle.
> The list of enhancements is long and I can imagine how
> much work was done for that.

You're welcome.

> I write this comment because of the following reasons:
> 1) A requested feature was implemented.  :-))
> 2) The way someone can communicate and interact with you
> is just fun.
>  - I always got a answer in time.
>  - Answers were alsways polite and helpful even when my questions
>    were probably a little bit crazy.
>  - You were open minded for patches as a starting point for
>    probably more correct implementations of your own. Yes, at first
>    it's your project and code. :-)
>  - All together gave me the certainty to even think about trying
>    to read, to partially understand the code and to provide a patch.
>
> In my opinion this kind of direct and personal interacting is really
> seldom in the internet meanwhile.

Thank you for your kind words. I do my best but I'm glad to hear that
at least in one case my attempts are appreciated. :-)

> I'm looking forward to version 4.4 of cx_Oracle. ;-)

Naturally. I take suggestions.....and of course, patches! :-)

> Best regards
> Andreas Mock
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

[cx-oracle-users] Antw: cx_Oracle 4.3

[matilda m. <ma...@gr...>]

Hi Anthony,

thank you very much for the new release of cx_Oracle.
The list of enhancements is long and I can imagine how
much work was done for that.

I write this comment because of the following reasons:
1) A requested feature was implemented.  :-))
2) The way someone can communicate and interact with you=20
is just fun.=20
 - I always got a answer in time.
 - Answers were alsways polite and helpful even when my questions
   were probably a little bit crazy.
 - You were open minded for patches as a starting point for
   probably more correct implementations of your own. Yes, at first
   it's your project and code. :-)
 - All together gave me the certainty to even think about trying
   to read, to partially understand the code and to provide a patch.

In my opinion this kind of direct and personal interacting is really
seldom in the internet meanwhile.

I'm looking forward to version 4.4 of cx_Oracle. ;-)

Best regards
Andreas Mock