Wang, Yu wrote:
I installed FR 2.2.1 from git on one of our radius servers on April 22.
After installation, I ran valgrind memcheck against radiusd binary and
it showed no memory leak. A few days later now, I ran valgrind again. It
showed memory leak.
Code doesn't magically change
mailing list
Subject: Re: Valgrind memcheck FR 2.2.1shows memory leak
Wang, Yu wrote:
I installed FR 2.2.1 from git on one of our radius servers on April 22.
After installation, I ran valgrind memcheck against radiusd binary and
it showed no memory leak. A few days later now, I ran valgrind again
Hello,
I installed FR 2.2.1 from git on one of our radius servers on April 22. After
installation, I ran valgrind memcheck against radiusd binary and it showed no
memory leak. A few days later now, I ran valgrind again. It showed memory leak.
I am not sure what caused it. I have valgrind
with the latest updated today (i noticed the
userparse() in valuepair.c has updated) and the memory leak still the
same.
(same memory growth in VmRSS and same valgrind log.)
OK.
FR_TOKEN userparse(const char *buffer, VALUE_PAIR **list)
Why? Just... why? There is NO need to post code here
kao quadrantx wrote:
Hi,
i rebuild freeradius with the latest updated on git v2.x.x and attach
the valgrind log.
If you need anything else, please feel free to ask me.
Did you run with radiusd -m ? That is needed in order to get the
debugging symbols in the modules.
Alan DeKok.
-
List
kao quadrantx wrote:
new log with radiusd -m
Which still shows for many symbol names. Are you sure you're
running the latest v2.x.x from git?
Please try to simplify the issue down to a small configuration, and
email it to me. That will let me reproduce the problem, and fix it.
kao quadrantx wrote:
i rebuild freeradius with the latest updated today (i noticed the
userparse() in valuepair.c has updated) and the memory leak still the same.
(same memory growth in VmRSS and same valgrind log.)
OK.
FR_TOKEN userparse(const char *buffer, VALUE_PAIR **list)
Why
Hi,
i got the same issue in freeradius memory issue
http://freeradius.1045715.n5.nabble.com/Memory-leak-in-FR-2-1-10-and-2-2-0-tt5717545.html#a5717576
My test ENV:
eapol_test with md5 to do AUTH (client) - freeradius 2.2.0 to
proxy the client request (proxy
Have you tried the latest 2.2 GIT release? Many code updates
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Alan,
i download from here http://freeradius.org/download.html
Version 2.2.0:
tar.gzftp://ftp.freeradius.org/pub/freeradius/freeradius-server-2.2.0.tar.gz
(PGP
Signature)ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-2.2.0.tar.gz.sig
This version should be the latest version. Am
Hi,
i download from here http://freeradius.org/download.html
Version 2.2.0: tar.gz (PGP Signature)
This version should be the latest version. Am i right?
as per the download page:
http://git.freeradius.org/
that will be the 'latest 2.2.x version'
2.2.0 is the latest RELEASE
.nabble.com/Memory-leak-in-FR-2-1-10-and-2-2-0-tt5717545.html#a5717576
My test ENV:
eapol_test with md5 to do AUTH (client) - freeradius 2.2.0 to
proxy the client request (proxy) - freeradius
2.2.0
More request more memory (VmRSS) consumed by radiusd (proxy
On 06.03.2013 11:43, kao quadrantx wrote:
Hi,
I try to test with the latest version of freeradius in git 2.x.x and
still get the same behavior.
Seems the envp variable in radius_exec_program function (exec.c) not clean?
To help the developers to identify the bug, could you follow the
kao quadrantx wrote:
I try to test with the latest version of freeradius in git 2.x.x and
still get the same behavior.
$ git pull
Then rebuild.
Seems the envp variable in radius_exec_program function (exec.c) not clean?
No. It looks like the userparse() function isn't cleaning up
Hi,
i rebuild freeradius with the latest updated today (i noticed the
userparse() in valuepair.c has updated) and the memory leak still the same.
(same memory growth in VmRSS and same valgrind log.)
FR_TOKEN userparse(const char *buffer, VALUE_PAIR **list)
{
VALUE_PAIR *vp, *head
today (i noticed the
userparse() in valuepair.c has updated) and the memory leak still the same.
(same memory growth in VmRSS and same valgrind log.)
FR_TOKEN userparse(const char *buffer, VALUE_PAIR **list)
{
VALUE_PAIR *vp, *head, **tail;
const char *p
-Debian-packages
process get killed by kernel in less than 36 hours.
As I cannot reproduce this on my test environment by using eapol_test, I suspect alcatel
frames to trigger a kind of memory leak in freeradius.
I collected different things :
- pcap of eap-md5 exchange between freeradius
On 08/01/13 08:37, Philippe MARASSE wrote:
- valgrind log on my production server
What did the valgrind log show? It's normally pretty good at catching
actual leaks.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
alcatel frames to trigger a kind of memory leak in freeradius.
Possible.
I collected different things :
- pcap of eap-md5 exchange between freeradius and a switch
- valgrind log on my production server
- pidstat showing memory usage of freeradius process
So... what were the results?
Did
cannot reproduce this on my test environment by using eapol_test, I
suspect alcatel frames to trigger a kind of memory leak in freeradius.
Possible.
I collected different things :
- pcap of eap-md5 exchange between freeradius and a switch
- valgrind log on my production server
- pidstat
Philippe MARASSE wrote:
As the complete log is pretty big (around 1 Mb) I did not post the
entire result (and it exceeds 500kb limit of pastebin), but I can send
by mail valgrind log, pcap and other possibly useful things.
For this, send valgrind logs to me personally.
I've never used
Le 08/01/2013 16:24, Alan DeKok a écrit :
Philippe MARASSE wrote:
As the complete log is pretty big (around 1 Mb) I did not post the
entire result (and it exceeds 500kb limit of pastebin), but I can send
by mail valgrind log, pcap and other possibly useful things.
For this, send valgrind
Philippe MARASSE wrote:
I'm a bit confused : I built debian package with rules provided in
tarball, configure options are :
It should work. If it doesn't, check that there aren't *other*
modules on the system. They could have been built without debugging
symbols.
Alan DeKok.
-
List
Le 08/01/2013 21:56, Alan DeKok a écrit :
Philippe MARASSE wrote:
I'm a bit confused : I built debian package with rules provided in
tarball, configure options are :
It should work. If it doesn't, check that there aren't *other*
modules on the system. They could have been built without
All,
We recently upgraded to 2.1.12 and I have at the same time enabled SSL
fast session resumption; in the last 6 days, FreeRADIUS on the server
that is currently handling most of our auth has consumed 27% of the RAM.
Is anyone else running fast session resumption and seeing these
Hi,
We recently upgraded to 2.1.12 and I have at the same time enabled SSL
fast session resumption; in the last 6 days, FreeRADIUS on the server
that is currently handling most of our auth has consumed 27% of the RAM.
Is anyone else running fast session resumption and seeing these
Phil Mayers wrote:
All,
We recently upgraded to 2.1.12 and I have at the same time enabled SSL
fast session resumption; in the last 6 days, FreeRADIUS on the server
that is currently handling most of our auth has consumed 27% of the RAM.
Is anyone else running fast session resumption and
On 13/10/11 13:31, Alan DeKok wrote:
Phil Mayers wrote:
All,
We recently upgraded to 2.1.12 and I have at the same time enabled SSL
fast session resumption; in the last 6 days, FreeRADIUS on the server
that is currently handling most of our auth has consumed 27% of the RAM.
Is anyone else
Phil Mayers wrote:
I am wondering if it's actually unrelated to fast session resumption;
the CPU use has jumped alarmingly too, and doesn't drop back when I
disable session resumption.
Hmm... I don't recall any new use tons of CPU code in 2.1.12.
Alan DeKok.
-
List
On 13/10/11 14:49, Alan DeKok wrote:
Phil Mayers wrote:
I am wondering if it's actually unrelated to fast session resumption;
the CPU use has jumped alarmingly too, and doesn't drop back when I
disable session resumption.
Hmm... I don't recall any new use tons of CPU code in 2.1.12.
Alan Buxey a.l.m.bu...@lboro.ac.uk wrote:
We recently upgraded to 2.1.12 and I have at the same time enabled SSL
fast session resumption; in the last 6 days, FreeRADIUS on the server
that is currently handling most of our auth has consumed 27% of the RAM.
Is anyone else running fast
Hi,
well, due to the way the log files and logrotate clash, our servers
have a daily restart right now so this masks any such issue so
cant say :-|
I probably asked this already but why not syslog-ng and mmdd.log as
an output?
because the system should be as vanilla as
I noticed something in rlm_sql.c function rlm_sql_process_groups().
group_list is allocated at the top of the function, but
sql_grouplist_free(group_list) is only called at the end. All the various
error exits don't call it.
ISTM that's going to leak memory in event of errors, but perhaps I
Brian Candler wrote:
I noticed something in rlm_sql.c function rlm_sql_process_groups().
group_list is allocated at the top of the function, but
sql_grouplist_free(group_list) is only called at the end. All the various
error exits don't call it.
ISTM that's going to leak memory in event
Derek Chee wrote:
I have a FreeRADIUS 2.1.9 installation (compiled from source) running on
Solaris 10 Sparc and I've run into a memory leak issue when reloading the
configuration with a HUP signal. I have a very simple RADIUS setup with just
an authorize and a users file. The users file
On Aug 25, 2010, at 3:14 AM, Alan DeKok wrote:
Derek Chee wrote:
I have a FreeRADIUS 2.1.9 installation (compiled from source) running on
Solaris 10 Sparc and I've run into a memory leak issue when reloading the
configuration with a HUP signal. I have a very simple RADIUS setup with
just
Hi,
I have a FreeRADIUS 2.1.9 installation (compiled from source) running on
Solaris 10 Sparc and I've run into a memory leak issue when reloading the
configuration with a HUP signal. I have a very simple RADIUS setup with just
an authorize and a users file. The users file is rather large
Zhang, Ge (Gina) wrote:
Thanks for your advise. I ran radiusd with valgrind. The only leak when
processing a request is in rlm_wimax.
After I fixed it, I still see RES memory increases with each request
processing. Could you please help with
the following questions?
1. Where does the
=alcatel-lucent@lists.freeradius.org
[mailto:freeradius-users-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org]
On Behalf Of Alan DeKok
Sent: Thursday, March 25, 2010 6:58 PM
To: FreeRadius users mailing list
Subject: Re: Memory Leak on version 2.1.3
Zhang, Ge (Gina) wrote:
I tried 2.1.8
Hi,
The server is in production and we won't upgrade for a while.
but you're willing to patch and recompile the old/obsolete 2.1.3 version?
whats the difference? its pretty much the same situation. go for 2.1.8.
alan
-
List info/subscribe/unsubscribe? See
: Thursday, March 25, 2010 4:42 AM
To: FreeRadius users mailing list
Subject: Re: Memory Leak on version 2.1.3
Hi,
The server is in production and we won't upgrade for a while.
but you're willing to patch and recompile the old/obsolete 2.1.3 version?
whats the difference? its pretty much the same
Hi,
Alan,
Does 2.1.8 have the fix for the problem?
its got many fixes - check the source code.
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
]
On Behalf Of Alan Buxey
Sent: Thursday, March 25, 2010 4:42 AM
To: FreeRadius users mailing list
Subject: Re: Memory Leak on version 2.1.3
Hi,
The server is in production and we won't upgrade for a while.
but you're willing to patch and recompile the old/obsolete 2.1.3 version?
whats
Zhang, Ge (Gina) wrote:
I tried 2.1.8 and it leaks memory exactly like 2.1.3. Any other suggestions?
Are you sure it's a memory leak?
The server *is* supposed to use memory for various kinds of caching.
See valgrind for tracking down memory leaks.
Alan DeKok.
-
List info/subscribe
Hi,
I am using 2.1.3 freeradius server and found memory leak.
I use ttls+mschapv2 for authentication. After each authentication, the memory
usage increases.
Is there a patch fix for this?
Thanks,
Gina Zhang
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
freeradius-users@lists.freeradius.org
Sent: Wed Mar 24 18:24:54 2010
Subject: Memory Leak on version 2.1.3
Hi,
I am using 2.1.3 freeradius server and found memory leak.
I use ttls+mschapv2 for authentication. After each authentication, the memory
usage increases.
Is there a patch fix
-lucent@lists.freeradius.org]
On Behalf Of Gary Gatten
Sent: Wednesday, March 24, 2010 6:31 PM
To: 'freeradius-users@lists.freeradius.org'
Subject: Re: Memory Leak on version 2.1.3
there are at least 3 newer versions. Have you tried the latest and/or read the
changelog?
- Original Message
-bounces+gina.zhang=alcatel-lucent@lists.freeradius.org]
On Behalf Of Gary Gatten
Sent: Wednesday, March 24, 2010 6:31 PM
To: 'freeradius-users@lists.freeradius.org'
Subject: Re: Memory Leak on version 2.1.3
there are at least 3 newer versions. Have you tried the latest and/or read
Stefan A. wrote:
I still see the memory consumption rising over the time
Output from top every 5 Minutes:
SIZE/RES
16M/13M
34M/32M
53M/51M
71M/69M
...it rises about 3-4 MB per Minutes.
Ugh.
I read about some issues and tried 2.1.7... still the same.
Because the code in rlm_sql.c
Hi all,
I have been asking this in October 2008, while using 2.0.4
FR is eating Memory and I do not know how to troubleshoot this.
It takes about 1 MB/ Minute which was about 3.5 GB over
some Days, before we
rcognized this.
Alan: There were issues with older versions of the
Alan DeKok al...@deployingradius.com wrote:
I am running freeradius-2.1.6 with all AAA logick hidden in perl module,
thus using rlm_perl.
Having about 1000-1 client connections per day radiusd consumes about
1Gb of memory per day (I restart it daily).
The only (possibly) important
Alexander Clouter
Alan DeKok al...@deployingradius.com wrote:
I am running freeradius-2.1.6 with all AAA logick hidden in perl
module,
thus using rlm_perl.
Having about 1000-1 client connections per day radiusd consumes
about
1Gb of memory per day (I restart it daily).
The only
Hello, all.
I am running freeradius-2.1.6 with all AAA logick hidden in perl module,
thus using rlm_perl.
Having about 1000-1 client connections per day radiusd consumes about
1Gb of memory per day (I restart it daily).
The only (possibly) important thing - I am using several external
Mihail Vasiliev wrote:
Hello, all.
I am running freeradius-2.1.6 with all AAA logick hidden in perl module,
thus using rlm_perl.
Having about 1000-1 client connections per day radiusd consumes about
1Gb of memory per day (I restart it daily).
The only (possibly) important thing - I
On Oct 7, 2009, at 8:58 PM, Mihail Vasiliev wrote:
thread pool {
start_servers = 5
max_servers = 32
min_spare_servers = 3
max_spare_servers = 10
max_requests_per_server = 300
}
Try run it with fixed pool size. This will reduce memory consumption.
Best
On Fri, Sep 04, 2009 at 02:27:13PM +0200, Alan DeKok wrote:
Can you re-build the rlm_sql module with debugging symbols? (-g, and
DELETE any -O2 flags you find). That way, it will print out line
numbers like the following:
I can't make valgrind print file lines from modules for some reason.
Szymon Roczniak wrote:
The one that uses leaking memory returns Auth-Type : Accept from
: ? What's that?
authorize_check_query = SELECT 1,'notused','Auth-Type','Accept',':' FROM
That's the issue. The operator is wrong. Use :=, not :
It shouldn't leak memory, so that still needs to
Szymon Roczniak wrote:
It's odd, but it looks like it doesn't matter what operator is used in this
place. In fact it still works even without one (I've just tested it with some
random 'operators' and with the operator field set to ).
Yes... I saw that, and just fixed it.
There are some
On Tue, Sep 08, 2009 at 01:59:05PM +0200, Alan DeKok wrote:
Szymon Roczniak wrote:
authorize_check_query = SELECT 1,'notused','Auth-Type','Accept',':' FROM
That's the issue. The operator is wrong. Use :=, not :
That's an error, the production configuration has ':=' in the
operator
On Thu, Sep 03, 2009 at 03:02:23PM +0200, Alan DeKok wrote:
You should add -m to the radiusd command line, so that it will try
to clean up as much memory as possible before exiting.
Output with -m and some more debugging information:
34,944 bytes in 112 blocks are definitely lost in loss
Szymon Roczniak wrote:
Output with -m and some more debugging information:
OK, that helps...
34,944 bytes in 112 blocks are definitely lost in loss record 38 of 44
at 0x4C20809: malloc (vg_replace_malloc.c:149)
by 0x4E38DCE: pairalloc (in
Hi,
This could be related to a similar problem reported a couple of weeks ago.
We have a FreeRADIUS 2.1.6 installation running on 64bit CentOS 5.3. The
radiusd process is allocating more and more memory with time (around 0.5GB a
day). There are only around 5-6 requests/s and other than chewing
Szymon Roczniak wrote:
I've followed the advise from the previous thread and run radiusd under
valgrind for around 10-15 minutes with some generated traffic and
the output is:
valgrind --tool=memcheck --leak-check=full /usr/sbin/radiusd -f
You should add -m to the radiusd command line, so
Gurus,
in my radiusd.log, I can see lots of these errors:
Wed Sep 24 09:40:54 2008 : Info: rlm_sql (sql_accounting): There are no DB
handles to use! skipped 0, tried to connect 0
Wed Sep 24 09:40:55 2008 : Info: rlm_sql (sql_accounting): There are no DB
handles to use! skipped 0, tried to connect
1 .Maybe max_connections in the MySQL config file should also be
increased and Mysql be restarted.
2. No idea except upgrading.
Norbert Wegener
Stefan A. schrieb:
Gurus,
in my radiusd.log, I can see lots of these errors:
Wed Sep 24 09:40:54 2008 : Info: rlm_sql (sql_accounting): There are no
Stefan A. wrote:
in my radiusd.log, I can see lots of these errors:
Wed Sep 24 09:40:54 2008 : Info: rlm_sql (sql_accounting): There are no DB
handles to use! skipped 0, tried to connect 0
Your database is probably slow. Do you have indexes?
FR is eating Memory and I do not know how to
nikitha george wrote:
On 5/23/07, nikitha george [EMAIL PROTECTED] wrote:
Please find the valgrind output below. It shows so much memory is still
reachable.
That's because the server doesn't clean up memory on exit. Run it
with the -m flag on the command line, and it will try to clean up
On 5/23/07, nikitha george [EMAIL PROTECTED] wrote:
Please find the valgrind output below. It shows so much memory is still
reachable.
I guess we are not cleaning up the all the expired cached session at
regular interval.
==21844== 7,456 bytes in 29 blocks are still reachable in loss record
nikitha george wrote:
On 5/20/07, Alan DeKok [EMAIL PROTECTED] wrote:
If valgrind doesn't say that the memory is lost, then the memory is
very likely still being used. i.e. It's likely needed for something.
something..?
Did you read my earlier explanations?
Why do radiusd need to hold
Do you have any idea what kind of malloc/free implementation on our system
will work out in this scenario?
Thanks,
Nikitha
On 5/19/07, Alan DeKok [EMAIL PROTECTED] wrote:
nikitha george wrote:
So why is it happening in my case then? I can see all the requests gets
cleaned up ( log message
trashes, you may
have detected a memory leak.
But to make sure a leak happens, usually tools like Valgrind helps
better than looking at what the kernel reports, as there is a lot more
hidden than what shows.
- --
== +-+
Martin Gadbois
but still reachable are more. I think this is the one
which is leaking memory. I dont have access to the log files today, i
will post it by tomorrow for your reference.
You seem pretty sure you've got a memory leak. As Alan has said, we're
pretty sure there are no major leaks in the server core, so
nikitha george wrote:
The memory usage of radiusd in our system went from 6687KB to 160MB
which is 50.1% of memory of our system and radiusd got re-started.
160Mb does sound like a lot.
I had run the Valgrind to see the resource leak. Definitely lost memory
was 380 Bytes but still
On 5/20/07, Alan DeKok [EMAIL PROTECTED] wrote:
If valgrind doesn't say that the memory is lost, then the memory is
very likely still being used. i.e. It's likely needed for something.
something..?
Why do radiusd need to hold the memory even after cleaning up the request?
Even after stopping
nikitha george wrote:
I am seeing a very serious memory leak issue with freeradius-1.1.6. The
memory usage of freeradius gone from 3386Byte to 64MB when i was trying
to connect 16 clients with roaming interval of 1 second. More
Access-Requests are coming and we keep saving those requests until
and
clients entry added newly.
Hoping to get some positive reply.
Thanks,
Nikitha
On 5/18/07, Alan DeKok [EMAIL PROTECTED] wrote:
nikitha george wrote:
I am seeing a very serious memory leak issue with freeradius-1.1.6. The
memory usage of freeradius gone from 3386Byte to 64MB when i was trying
nikitha george wrote:
So why is it happening in my case then? I can see all the requests gets
cleaned up ( log message was put) but still so much memory is consumed
by radiusd.
When the server caches the requests, it uses memory to do that. When
it frees the requests, the memory does *not*
a day, it should be the same the following
week.
If the RES raise linearly for days until the system trashes, you may
have detected a memory leak.
But to make sure a leak happens, usually tools like Valgrind helps
better than looking at what the kernel reports, as there is a lot more
hidden than
Hi,
I am seeing a very serious memory leak issue with freeradius-1.1.6. The
memory usage of freeradius gone from 3386Byte to 64MB when i was trying to
connect 16 clients with roaming interval of 1 second. More Access-Requests
are coming and we keep saving those requests until cleanup_delay
Hi,
I just configured radius 1.1.3 and found that there are some memory leaks
in it.
Here is the output of Valgrind
==30841== ERROR SUMMARY: 4365 errors from 82 contexts (suppressed: 44 from 2)
==30841== malloc/free: in use at exit: 1,354,452 bytes in 25,976 blocks.
==30841==
Hi, all.
I'm using FreeRadius 1.0.1 with rlm_perl under Linux kernel 2.4.27
rlm_perl module using DBI makes AAA.
BUT, I found it increases its memory usage from 8Mb to 500Mb, so, what
will be the next??
And why?
Best regards,
AL
--
Best regards,
Serg Shipaev, IP TELephony EXchange Ltd.
e-mail:
Hi!
I wrote about this leak sometime ago.
There was leakless rlm_perl in version 0.9.3.
In previous and in all 1.0.X versions memory leak exists.
So, now i use this rlm_perl with 1.0.1.
Attached version also have a little improvement - it
modifies all 3 items - reply, config but request.
Hi
Hi,
Thank you. I'll try to rebuild this module.
Is't works normally after?
AL
[EMAIL PROTECTED] wrote:
Hi!
I wrote about this leak sometime ago.
There was leakless rlm_perl in version 0.9.3.
In previous and in all 1.0.X versions memory leak exists.
So, now i use this rlm_perl with 1.0.1.
Attached
On Thu, Nov 11, 2004 at 09:40:01PM +0300, Admin wrote:
Hi, all.
I'm using FreeRadius 1.0.1 with rlm_perl under Linux kernel 2.4.27
rlm_perl module using DBI makes AAA.
BUT, I found it increases its memory usage from 8Mb to 500Mb, so, what
will be the next??
And why?
Look at
On Mon, 25 Oct 2004 10:27:14 +0200
Nils Rønhovde [EMAIL PROTECTED] wrote:
On Tue, 14 Sep 2004 13:29:23 -0400
Alan DeKok [EMAIL PROTECTED] wrote:
=?ISO-8859-1?Q?Jo=E3o_S=E1?= [EMAIL PROTECTED] wrote:
Until now everything is fine but now I need to use a module in
perl to do credit
Hi,
I'm using freeradius 0.9.3.
Until now everything is fine but now I need to use a module in perl to
do credit control.
I verified that when I start, the freeradius process begins with about
26 Mb in memory growing until I eat all memory available (I already
had a process with 400 Mb).
In
=?ISO-8859-1?Q?Jo=E3o_S=E1?= [EMAIL PROTECTED] wrote:
Until now everything is fine but now I need to use a module in perl to
do credit control.
I verified that when I start, the freeradius process begins with about
26 Mb in memory growing until I eat all memory available (I already
had a
.
Regards,
Nik
- Original Message -
From: Yasser Ahmed Hosny [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 03, 2004 2:50 PM
Subject: Memory Leak for Accounting using Oracle
Dear All
I am using Freeradius 1.0.0 pre03 version running on Sun Solaris 8 and I
am connecting
Yasser Ahmed Hosny [EMAIL PROTECTED] wrote:
I am using Freeradius 1.0.0 pre03 version running on Sun Solaris 8 and I
am connecting to an Oracle DB for accounting. My Oracle DB is located on
another Sun Solaris server 8i and I am using oracle client version
8.1.7.4. I realized that I am loosing
--__--__--
Message: 4
Date: Tue, 03 Aug 2004 12:50:13 +0400
From: Yasser Ahmed Hosny [EMAIL PROTECTED]
Subject: Memory Leak for Accounting using Oracle
To: [EMAIL PROTECTED]
Organization: Emirates Internet Multimedia
Reply-To: [EMAIL PROTECTED]
Dear All
I am using Freeradius 1.0.0 pre03 version
Dear All
I am using Freeradius 1.0.0 pre03 version running on Sun Solaris 8 and I
am connecting to an Oracle DB for accounting. My Oracle DB is located on
another Sun Solaris server 8i and I am using oracle client version
8.1.7.4. I realized that I am loosing memory on the DB machine after
pushing
hi,
When the module rlm_perl is used, and freeradius is restarted multiple times
by using kill -1 radiusd-pid, then the heap of the radiusd process
grows. After a few restarts all memory is used up. My c is rusty, so I don't
see what causes this memory leak. Anyone else?
loz
-
List info
causes this memory leak. Anyone else?
Try to find a patch that i send to freeradius-devel and apply it on CVS
version of rlm_perl. Just tell me if you can't find it, i will send it
directly to you.
--
Best Regards,
Boian Jordanov
SNE
Orbitel - the Internet Company
tel. +359 2 937 07 23
-
List
At 04:07 AM 1/26/2004, Bhaskar Bhattarai wrote:
Hello all:
I am running FreeRadius-0.9.3 on RedHat Linux 9. When I run Memory
Profiler (MemProf) I see a lot of memory leaks being reported. Don't mean
to be annoying, but I have dumped all the reported memory leak cases below
for analysis
Hello all:
I'm running freeradius-0.9.3 on RedHat Linux 9.
Recently I ran MemProf (Memory Profiler) against freeradius. It showed
quite a *number* of instances of memory leak (involving ip_getaddr() ).
Below is one snapshot.
Leaked 0x80f85d8 (40 bytes)
[0x40018809]
__i686
Hello:
I'm using the ORACLE module (rlm_sql - rlm_sql_oracle) to do AAA with
freeradius-0.9.3.
The function OCILogon() is leaking memory (sltsmxi routine).
I did encounter some similar posts, but could not find a solution patch
anywhere.
Anybody with a similar issue found a solution?
Response
96 matches
Mail list logo
