Valts Mazurs <valts (AT) datatechlabs (DOT) comwrote:
I compiled freeradius with rlm_python and used sample script to test
rlm_python module.
After 214 calls to PC() it dies in ugly way.
There's a bug report on bugs.freeradius.org. See if the fix there
solves the problem.
Alan DeKok.
-
List info/subscribe/unsubscribe? See

Alan DeKok wrote:
Valts Mazurs <valts (AT) datatechlabs (DOT) comwrote:
>
>>I compiled freeradius with rlm_python and used sample script to test
>>rlm_python module.
>>After 214 calls to PC() it dies in ugly way.
>
>
There's a bug report on bugs.freeradius.org. See if the fix there
solves the problem.

Thanks, I will try this out and post a report when done.

Valts.

PGP SIGNATURE
Version: GnuPG v1.4.0 (FreeBSD)

TUmYSJAIpEf5xlw9XQZG14=
=QIfl
PGP SIGNATURE

Alan DeKok wrote:
>
>Valts Mazurs <valts (AT) datatechlabs (DOT) comwrote:
>>
I compiled freeradius with rlm_python and used sample script to test
rlm_python module.
After 214 calls to PC() it dies in ugly way.
>>
>>
>>
>There's a bug report on bugs.freeradius.org. See if the fix there
>solves the problem.
>>
>
Thanks, I will try this out and post a report when done.

Valts.

I took alook at bug report #227
Fixed rlm_python.c is helpful. Thanks.
To get rid of #227 bug rlm_python.c
() and
configure option are mandatory.

But there is also another small issue with rlm_python.
When I execute radiusd -X it is unkillalble witch ctrl+c but is killable
with `killall radiusd`. When ir runs as daemon it is not killable with
simple kill but is killable with `killall -9 radiusd`.

As I can see from radiusd -X output there is another memory leak with
python threads.

radiusd -X output:

Ready to process requests.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
Walking the entire request list
Nothing to do. Sleeping until we see a request.
[ there I typed killall radiusd ] <--
Exiting
rlm_perl::Detaching. Reloading. Done.
python_thread_restore start
python_thread_restore K
python_thread_save start
python_thread_save K
Fatal Python error: PyThreadState_Delete: tstate is still current
Abort (core dumped)

gdb output:

(gdb) bt
#0 0x2836c1d7 in kill () from /lib/libc.so.5
#1 0x281dfb93 in raise () from /usr/lib/libpthread.so.1
#2 0x283d3627 in abort () from /lib/libc.so.5
#3 0x28139427 in Py_FatalError () from /usr/local/lib/libpython2.4.so
#4 0x2813691d in PyThreadState_Delete () from
/usr/local/lib/libpython2.4.so
#5 0x0805bfeb in free_mainconfig ()
#6 0x08054a08 in detach_modules ()
#7 0x0804e1d5 in main ()

My environment:
FreeBSD 5.3-RELEASE
freeradius-1.0.2
/configure && make && make install
gcc version 3.4.2 [FreeBSD] 20040728

Regards,
Valts.

PGP SIGNATURE
Version: GnuPG v1.4.1 (FreeBSD)

xHYqqKKz9uAMzpmSIxmFo30=
=Vt
PGP SIGNATURE

Valts Mazurs wrote:
>Alan DeKok wrote:
>>
Valts Mazurs <valts (AT) datatechlabs (DOT) comwrote:

I compiled freeradius with rlm_python and used sample script to test
rlm_python module.
After 214 calls to PC() it dies in ugly way.

There's a bug report on bugs.freeradius.org. See if the fix there
solves the problem.

>>
>Thanks, I will try this out and post a report when done.
>>
>Valts.

I took alook at bug report #227
Fixed rlm_python.c is helpful. Thanks.
To get rid of #227 bug rlm_python.c
() and
configure option are mandatory.

But there is also another small issue with rlm_python.
When I execute radiusd -X it is unkillalble witch ctrl+c but is killable
with `killall radiusd`. When ir runs as daemon it is not killable with
simple kill but is killable with `killall -9 radiusd`.

As I can see from radiusd -X output there is another memory leak with
python threads.

radiusd -X output:

Ready to process requests.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
Walking the entire request list
Nothing to do. Sleeping until we see a request.
[ there I typed killall radiusd ] <--
Exiting
rlm_perl::Detaching. Reloading. Done.
python_thread_restore start
python_thread_restore K
python_thread_save start
python_thread_save K
Fatal Python error: PyThreadState_Delete: tstate is still current
Abort (core dumped)

gdb output:

(gdb) bt
#0 0x2836c1d7 in kill () from /lib/libc.so.5
#1 0x281dfb93 in raise () from /usr/lib/libpthread.so.1
#2 0x283d3627 in abort () from /lib/libc.so.5
#3 0x28139427 in Py_FatalError () from /usr/local/lib/libpython2.4.so
#4 0x2813691d in PyThreadState_Delete () from
/usr/local/lib/libpython2.4.so
#5 0x0805bfeb in free_mainconfig ()
#6 0x08054a08 in detach_modules ()
#7 0x0804e1d5 in main ()

My environment:
FreeBSD 5.3-RELEASE
freeradius-1.0.2
./configure && make && make install
gcc version 3.4.2 [FreeBSD] 20040728

Regards,
Valts.

Now I fixed this bug with some others. Can you test the new version of
module ?

>But there is also another small issue with rlm_python.
>When I execute radiusd -X it is unkillalble witch ctrl+c but is killable
>with `killall radiusd`. When ir runs as daemon it is not killable with
>simple kill but is killable with `killall -9 radiusd`.
>>
>As I can see from radiusd -X output there is another memory leak with
>python threads.
>>
>radiusd -X output:
>>
>Ready to process requests.
>^C Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>^C Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>^C Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>^C Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>[ there I typed killall radiusd ] <--
>Exiting
>rlm_perl::Detaching. Reloading. Done.
>python_thread_restore start
>python_thread_restore K
>python_thread_save start
>python_thread_save K
>Fatal Python error: PyThreadState_Delete: tstate is still current
>Abort (core dumped)
>>
>gdb output:
>>
>(gdb) bt
>#0 0x2836c1d7 in kill () from /lib/libc.so.5
>#1 0x281dfb93 in raise () from /usr/lib/libpthread.so.1
>#2 0x283d3627 in abort () from /lib/libc.so.5
>#3 0x28139427 in Py_FatalError () from /usr/local/lib/libpython2.4.so
>#4 0x2813691d in PyThreadState_Delete () from
>/usr/local/lib/libpython2.4.so
>#5 0x0805bfeb in free_mainconfig ()
>#6 0x08054a08 in detach_modules ()
>#7 0x0804e1d5 in main ()
>>
>>
>>
>>
>Regards,
>Valts.
>
>
>
Now I fixed this bug with some others. Can you test the new version of
module ?

Still core dumps :)

No offence, but leading "PyAPI:" in every radlog string is annoying. It
screws multiline output etc.
It is not hard to implement such feature in radlog wrapper written in
python if neccessary. I am sure that output formatting must be left up
to programmer as it is with many things in Python.
I suppose that all these "PYTHN" and "PyERRR" should be replaced with
module name which is responsible about creating this debug information
("rlm_python" in this case). That's why I admit putting "PyAPI" in every
radlog message because python module written by me may have different name.

I had to make small change in default example python module
radiusd_test.py in function detach() because it now takes 1 argument
(previously: none)

radiusd -X output:
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
Walking the entire request list
Nothing to do. Sleeping until we see a request.
Exiting
rlm_perl::Detaching. Reloading. Done.
PYTHN:detach: function call failed
Segmentation fault (core dumped)

gdb output:
(gdb) bt
#0 0x281d48a5 in lt_dlclose (handle=0x80d7d80) at ltdl.c:3274
#1 0x281d47ad in unload_deplibs (handle=0x80d7b80) at ltdl.c:2460
#2 0x281d48cc in lt_dlclose (handle=0x80d7b80) at ltdl.c:3286
#3 0x08054936 in detach_modules ()
#4 0x0804e125 in main ()

My environment:
FreeBSD 5.3-RELEASE
freeradius-1.0.2
./configure && make && make install
gcc version 3.4.2 [FreeBSD] 20040728
Python 2.4.1

Regards,
Valts.

PGP SIGNATURE
Version: GnuPG v1.4.1 (FreeBSD)

84KYl+XA/RMkrPNNwnI+iqI=
=rk3b
PGP SIGNATURE

Valts Mazurs wrote:

Still core dumps :)

No offence, but leading "PyAPI:" in every radlog string is annoying. It
screws multiline output etc.
It is not hard to implement such feature in radlog wrapper written in
python if neccessary. I am sure that output formatting must be left up
to programmer as it is with many things in Python.
I suppose that all these "PYTHN" and "PyERRR" should be replaced with
module name which is responsible about creating this debug information
("rlm_python" in this case). That's why I admit putting "PyAPI" in every
radlog message because python module written by me may have different name.

, I changed "PYTHN" to "rlm_python" and "PyERRR" to
"rlm_python:EXCEPT" for mark unhandled exceptions. I used "PyAPI" for
debug reasons only and now it is removed.

Thanks for you critiques.

I had to make small change in default example python module
radiusd_test.py in function detach() because it now takes 1 argument
(previously: none)

radiusd -X output:
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
^C Walking the entire request list
Nothing to do. Sleeping until we see a request.
Walking the entire request list
Nothing to do. Sleeping until we see a request.
Exiting
rlm_perl::Detaching. Reloading. Done.
PYTHN:detach: function call failed
Segmentation fault (core dumped)

gdb output:
(gdb) bt
#0 0x281d48a5 in lt_dlclose (handle=0x80d7d80) at ltdl.c:3274
#1 0x281d47ad in unload_deplibs (handle=0x80d7b80) at ltdl.c:2460
#2 0x281d48cc in lt_dlclose (handle=0x80d7b80) at ltdl.c:3286
#3 0x08054936 in detach_modules ()
#4 0x0804e125 in main ()

Maybe another loadable module made core dump. I think it because
rlm_python is static and cannot be unloaded.
You can try to find module name in gdb:
// Null pointer or not
(gdb) printf "%p", handle
// What is a name of module
(gdb) printf "%s\n", handle->name

My environment:
FreeBSD 5.3-RELEASE
freeradius-1.0.2
./configure && make && make install
gcc version 3.4.2 [FreeBSD] 20040728
Python 2.4.1

Regards,
Valts.

Vladimir Yu. Stepanov wrote:
, I changed "PYTHN" to "rlm_python" and "PyERRR" to
"rlm_python:EXCEPT" for mark unhandled exceptions. I used "PyAPI" for
debug reasons only and now it is removed.

Thanks for you critiques.

Thank you very much.

Regarding core dumps:
>>
>radiusd -X output:
>^C Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>^C Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>^C Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>^C Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>^C Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>Walking the entire request list
>Nothing to do. Sleeping until we see a request.
>Exiting
>rlm_perl::Detaching. Reloading. Done.
>PYTHN:detach: function call failed
>Segmentation fault (core dumped)
>>
>>
>gdb output:
>(gdb) bt
>#0 0x281d48a5 in lt_dlclose (handle=0x80d7d80) at ltdl.c:3274
>#1 0x281d47ad in unload_deplibs (handle=0x80d7b80) at ltdl.c:2460
>#2 0x281d48cc in lt_dlclose (handle=0x80d7b80) at ltdl.c:3286
>#3 0x08054936 in detach_modules ()
>#4 0x0804e125 in main ()
>
>
Maybe another loadable module made core dump. I think it because
rlm_python is static and cannot be unloaded.
You can try to find module name in gdb:
// Null pointer or not
(gdb) printf "%p", handle
// What is a name of module
(gdb) printf "%s\n", handle->name

// not null
(gdb) printf "%p\n", handle
0x80d7d80
// no name
(gdb) printf "%s\n", handle->name
There is no member named name.

I have no idea.
I am very sorry but I am not expirienced enough with gdb to figure out
what other output would be neccessary for you.

>>
>>
>My environment:
>FreeBSD 5.3-RELEASE
>freeradius-1.0.2
>./configure && make && make install
>gcc version 3.4.2 [FreeBSD] 20040728
>Python 2.4.1

PGP SIGNATURE
Version: GnuPG v1.4.1 (FreeBSD)

UTok9fYoJ/3ivouLpJvg9+g=
=
PGP SIGNATURE

Valts Mazurs wrote:

// not null
(gdb) printf "%p\n", handle
0x80d7d80
// no name
(gdb) printf "%s\n", handle->name
There is no member named name.

Sorry. I wrong. Must be:
(gdb) printf "%s\n", handle->info.filename
or
(gdb) printf "%s\n", handle->info.name

I have no idea.
I am very sorry but I am not expirienced enough with gdb to figure out
what other output would be neccessary for you.

My environment:
FreeBSD 5.3-RELEASE
freeradius-1.0.2
./configure && make && make install
gcc version 3.4.2 [FreeBSD] 20040728
Python 2.4.1

Vladimir Yu. Stepanov wrote:
Sorry. I wrong. Must be:
(gdb) printf "%s\n", handle->info.filename
or
(gdb) printf "%s\n", handle->info.name

It doesn't get any better :/

(gdb) printf "%s\n", handle->info.filename
Cannot access memory at address 0x0
(gdb) printf "%s\n", handle->info.name
Cannot access memory at address 0x0

My environment:
FreeBSD 5.3-RELEASE
freeradius-1.0.2
./configure && make && make install
gcc version 3.4.2 [FreeBSD] 20040728
Python 2.4.1
GNU gdb 6.1.1 [FreeBSD]

Valts.

PGP SIGNATURE
Version: GnuPG v1.4.1 (FreeBSD)

cPqzuH+HXRUS82D+dWJDw=
=hqkC
PGP SIGNATURE

Valts Mazurs wrote:
Vladimir Yu. Stepanov wrote:

>Sorry. I wrong. Must be:
>(gdb) printf "%s\n", handle->info.filename
>or
>(gdb) printf "%s\n", handle->info.name

It doesn't get any better :/

(gdb) printf "%s\n", handle->info.filename
Cannot access memory at address 0x0
(gdb) printf "%s\n", handle->info.name
Cannot access memory at address 0x0

Can you try setup from ports collection of libltdl15
(/usr/ports/devel/libltdl15) and add some options in configure script
for freeradius:
"/usr/local/include" \
"/usr/local/lib" \
\
\

First two options may be help to fix this bug :)

My environment:
FreeBSD 5.3-RELEASE
freeradius-1.0.2
./configure && make && make install
gcc version 3.4.2 [FreeBSD] 20040728
Python 2.4.1
GNU gdb 6.1.1 [FreeBSD]

Valts.

Vladimir Yu. Stepanov wrote:
Can you try setup from ports collection of libltdl15
(/usr/ports/devel/libltdl15) and add some options in configure script
for freeradius:
"/usr/local/include" \
"/usr/local/lib" \

It was not helpful.
Crashed with core dump when I called "killall radiusd".

gdb bt output:
(gdb) bt
#0 0x280f6b0b in PyType_IsSubtype () from /usr/local/lib/libpython2.4.so
#1 0x2812d800 in PyImport_Cleanup () from /usr/local/lib/libpython2.4.so
#2 0x2813651c in Py_Finalize () from /usr/local/lib/libpython2.4.so
#3 0x0805b160 in free_mainconfig ()
#4 0x08054968 in detach_modules ()
#5 0x0804e135 in main ()

\

enabled by default imho.

\

It is not neccessary. I use

With freeradius server crashes with core dump when
received first request.

gdb bt output:
(gdb) bt
#0 0x28668e2c in rad_mangle (data=0x816aec0, request=0x8091f00)
at rlm_preprocess.c:186
#1 0x2866922f in preprocess_authorize (instance=0x816aec0,
request=0x8091f00)
at rlm_preprocess.c:497
#2 0x08055ac2 in modcall (component=1, c=0x816ae00, request=0x8091f00)
at modcall.c:219
#3 0x08055cbf in modcall (component=1, c=0x816af80, request=0x8091f00)
at modcall.c:252
#4 0x080550fc in indexed_modcall (comp=1, idx=134815488, request=0x8091f00)
at modules.c:469
#5 0x080527c7 in rad_authenticate (request=0x8091f00) at auth.c:578
#6 0x0804ca26 in rad_respond (request=0x8091f00,
fun=0x8052738 <rad_authenticate>) at radiusd.c:1672
#7 0x0804e0b4 in main (argc=2, argv=0xbfbfe828) at radiusd.c:1457

NTE that all these bugs appear only if python module is enabled in
configuration files.

First two options may be help to fix this bug :)
>
>>
>My environment:
>FreeBSD 5.3-RELEASE
>freeradius-1.0.2
>./configure && make && make install
>gcc version 3.4.2 [FreeBSD] 20040728
>Python 2.4.1
>GNU gdb 6.1.1 [FreeBSD]
>>
>Valts.
-
List info/subscribe/unsubscribe? See
PGP SIGNATURE
Version: GnuPG v1.4.1 (FreeBSD)

EoxjtWtc6jy+uF82R3etSg=
=urD6
PGP SIGNATURE

Valts Mazurs wrote:
Vladimir Yu. Stepanov wrote:

>Can you try setup from ports collection of libltdl15
>(/usr/ports/devel/libltdl15) and add some options in configure script
>for freeradius:
>"/usr/local/include" \
>"/usr/local/lib" \

It was not helpful.
Crashed with core dump when I called "killall radiusd".

gdb bt output:
(gdb) bt
#0 0x280f6b0b in PyType_IsSubtype () from /usr/local/lib/libpython2.4.so
#1 0x2812d800 in PyImport_Cleanup () from /usr/local/lib/libpython2.4.so
#2 0x2813651c in Py_Finalize () from /usr/local/lib/libpython2.4.so
#3 0x0805b160 in free_mainconfig ()
#4 0x08054968 in detach_modules ()
#5 0x0804e135 in main ()

>\

enabled by default imho.

>\

It is not neccessary. I use

With freeradius server crashes with core dump when
received first request.

gdb bt output:
(gdb) bt
#0 0x28668e2c in rad_mangle (data=0x816aec0, request=0x8091f00)
at rlm_preprocess.c:186
#1 0x2866922f in preprocess_authorize (instance=0x816aec0,
request=0x8091f00)
at rlm_preprocess.c:497
#2 0x08055ac2 in modcall (component=1, c=0x816ae00, request=0x8091f00)
at modcall.c:219
#3 0x08055cbf in modcall (component=1, c=0x816af80, request=0x8091f00)
at modcall.c:252
#4 0x080550fc in indexed_modcall (comp=1, idx=134815488,
request=0x8091f00)
at modules.c:469
#5 0x080527c7 in rad_authenticate (request=0x8091f00) at auth.c:578
#6 0x0804ca26 in rad_respond (request=0x8091f00,
fun=0x8052738 <rad_authenticate>) at radiusd.c:1672
#7 0x0804e0b4 in main (argc=2, argv=0xbfbfe828) at radiusd.c:1457

NTE that all these bugs appear only if python module is enabled in
configuration files.

I tested rlm_python module many times for ia32/amd64 machines on FreeBSD
5.3-RELEASE with Python 2.4.1. It is worked very well (without any
memory leaks and crash problems).

I do not have ideas more :(

You can try to test new version:

My environment:
FreeBSD 5.3-RELEASE
freeradius-1.0.2
./configure && make && make install
gcc version 3.4.2 [FreeBSD] 20040728
Python 2.4.1
GNU gdb 6.1.1 [FreeBSD]

Valts.

-
List info/subscribe/unsubscribe? See

-
List info/subscribe/unsubscribe? See

Vladimir Yu. Stepanov wrote:
I tested rlm_python module many times for ia32/amd64 machines on
FreeBSD
5.3-RELEASE with Python 2.4.1. It is worked very well (without any
memory leaks and crash problems).

I do not have ideas more :(

You can try to test new version:

I am on amd athlon (CPU: AMD Athlon(tm) XP 2800+ (2088.08-MHz 686-class
CPU))

I will try to test rlm_python on all our servers to see whether the
problem exists.
Thank you in advance :)

Valts
-
List info/subscribe/unsubscribe? See
PGP SIGNATURE
Version: GnuPG v1.4.1 (FreeBSD)

DbPUDINboM9KnBq4456xgNY=
=RsBk
PGP SIGNATURE