hi, I have applied the patch yesterday only, but the problem still exists. The cursors are allocated and they continuously increase up to the maximum limit imposed by Oracle to the db.
I have analysed some of the queries allocating the cursors: there are some query to RADGROUPCHECK and RADGROUPREPLY tables, which are _*empty*_. Could it be those ones raising the problem? As we are not using those 2 tables , would it be possible to modify the cfg of Freeradius, so that it does no longer use them? I will also try to insert some dummy-values in the two RADGROUP... Thanks and regards Roberto > On Thu, Oct 14, 2004 at 11:13:40AM +0200, Roberto Re wrote: >> >> >> Kostas Zorbadelos wrote: >> >> >On Wed, Oct 13, 2004 at 06:25:25PM +0200, Roberto Re wrote: >> > >> >>First of all thanks for your attention, Alan >> >> >> >>My problem however seems to be more like this: >> >>http://lists.cistron.nl/pipermail/freeradius-devel/2002-December/004052.html >> >> >> >>I had already checked the working code, which includes that patch and >> it >> >>is exactly the following one: >> >> >> >>http://www.freeradius.org/cvs-log/radiusd/src/modules/rlm_sql/drivers/rlm_sql_oracle/sql_oracle.c >> >> >> >The code in this url does not include the patch Alan is reffering >> >to. Of course the patch in >> >http://bugs.freeradius.org/show_bug.cgi?id=128 addresses the >> >freeradius crash in case of Oracle errors in sql queries. This happens >> >with the Oracle 8i client libraries. I was told that Oracle 9 client >> >libs do not cause the freeradius crash (not tested my self). >> >> In my experience with Oracle 9 client (on a Linux RedHat Enterprise) the >> freeRADIUS dont crash, it dont realease cursors on the oracle side. >> >> Roberto >> > > OK, if the crashes do not happen on successive Oracle errors, try the > patch and let us know if it also solves your problem. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
