RE: rlm_perl problems]
Igor wrote:
I have tried 2.1.7 and got same error. I will try to compile it with --enable-developer and see if i can find out anything from gdb output. I realy don't know why would this happen because exactly the same setup worked on older releases. All i did was to compile the new version (2.1.6) and then copy old raddb dir.
I am not sure why i got so many "no debugging symbols found" but i did per doc/bugs instructions. This is gdb output: gdb radiusd GNU gdb Fedora (6.8-27.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) (gdb) set logging file gdb-radiusd.log (gdb) set logging on Copying output to gdb-radiusd.log. (gdb) set args -X -x -n radiusd_dialup -l /var/log/radius/dialup/radius.log (gdb) run Starting program: /usr/local/freeradius/sbin/radiusd -X -x -n radiusd_dialup -l /var/log/radius/dialup/radius.log (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 0xb7fe0ad0 (LWP 11159)] GOT CLONE -1208087856 0x9c56290 Program received signal SIGSEGV, Segmentation fault. 0x0041a0f5 in rlmperl_call (instance=0x9a0d5e0, request=0x9cad318, function_name=0x9a07258 "authorize") at rlm_perl.c:708 708 exitstatus = POPi; (gdb) info threads * 1 Thread 0xb7fe0ad0 (LWP 11159) 0x0041a0f5 in rlmperl_call (instance=0x9a0d5e0, request=0x9cad318, function_name=0x9a07258 "authorize") at rlm_perl.c:708 (gdb) thread apply all bt full Thread 1 (Thread 0xb7fe0ad0 (LWP 11159)): #0 0x0041a0f5 in rlmperl_call (instance=0x9a0d5e0, request=0x9cad318, function_name=0x9a07258 "authorize") at rlm_perl.c:708 sp = (SV **) 0x9cc8088 vp = <value optimized out> exitstatus = 0 n_a = 46 rad_reply_hv = (HV *) 0x9cb58a8 rad_check_hv = (HV *) 0x9c88500 rad_config_hv = <value optimized out> rad_request_hv = (HV *) 0x9c93e9c rad_request_proxy_hv = (HV *) 0x9c8bd68 rad_request_proxy_reply_hv = (HV *) 0x9cb58cc interp = <value optimized out> #1 0x08061834 in modcall () No symbol table info available. #2 0x0805e790 in indexed_modcall () No symbol table info available. #3 0x0805ea7c in module_authorize () No symbol table info available. #4 0x0804e37f in rad_authenticate () No symbol table info available. #5 0x0806c5fa in radius_handle_request () No symbol table info available. #6 0x0806450c in thread_pool_addrequest () No symbol table info available. #7 0x08069969 in event_socket_handler () No symbol table info available. #8 0x00154085 in fr_event_loop (el=0x9c528d8) at event.c:400 ef = (fr_event_fd_t *) 0x9c52988 i = 1 rcode = 1 when = {tv_sec = 1248559880, tv_usec = 267216} wake = <value optimized out> read_fds = {fds_bits = {1048576, 0 <repeats 31 times>}} #9 0x0806a666 in radius_event_process () No symbol table info available. #10 0x080625d6 in main () No symbol table info available. (gdb)
Program received signal SIGSEGV, Segmentation fault. 0x0041a0f5 in rlmperl_call (instance=0x9a0d5e0, request=0x9cad318, function_name=0x9a07258 "authorize") at rlm_perl.c:708 708 exitstatus = POPi;
I'm attaching the files I captured from the Seg Fault in rlm_perl @ line 708 (same as yours Igor). The zip file contains the debug output and the gdb output combined. I'm not an expert with gdb, but I'll try to dig into this to see if I can find the cause. If anyone else has any ideas or needs more Information, let me (and Igor) know. This is happening on my system with FreeBSD 7.2 & perl 5.8.9 and Igor's with CentOS & perl 5.8.8.
On Jul 26, 2009, at 12:59 AM, <sigor@blic.net> <sigor@blic.net> wrote:
Igor wrote:
I have tried 2.1.7 and got same error. I will try to compile it with --enable-developer and see if i can find out anything from gdb output. I realy don't know why would this happen because exactly the same setup worked on older releases. All i did was to compile the new version (2.1.6) and then copy old raddb dir.
I am not sure why i got so many "no debugging symbols found" but i did per doc/bugs instructions. This is gdb output:
Try attached patch. Best Regards, Boian Jordanov R&D Expert Orbitel - Next Generation Telecom tel. +359 2 4004 723 tel. +359 2 4004 002
Boian, SUCCESS! Thank you , thank you, thank you! I applied the patch to my test 2.1.6 system and it eliminated the Seg Fault and all of the strange behaviour. My perl scripts now function as they do in Production. I am extremely grateful for the time you spent debugging this issue and creating a patch in such a timely manner. I hope Igor experiences a similar euphoria.. Thanks again.. -----Original Message----- From: freeradius-users-bounces+neal.garber=energyeast.com@lists.freeradius.org [mailto:freeradius-users-bounces+neal.garber=energyeast.com@lists.freeradius.org] On Behalf Of Boian Jordanov Sent: Monday, July 27, 2009 10:09 AM To: sigor@blic.net; FreeRadius users mailing list Cc: Boian Jordanov Subject: Re: rlm_perl problems] On Jul 26, 2009, at 12:59 AM, <sigor@blic.net> <sigor@blic.net> wrote:
Igor wrote:
I have tried 2.1.7 and got same error. I will try to compile it with --enable-developer and see if i can find out anything from gdb output. I realy don't know why would this happen because exactly the same setup worked on older releases. All i did was to compile the new version (2.1.6) and then copy old raddb dir.
I am not sure why i got so many "no debugging symbols found" but i did per doc/bugs instructions. This is gdb output:
Try attached patch.
Boian Jordanov wrote:
On Jul 26, 2009, at 12:59 AM, <sigor@blic.net> <sigor@blic.net> wrote:
Igor wrote:
I have tried 2.1.7 and got same error. I will try to compile it with --enable-developer and see if i can find out anything from gdb output. I realy don't know why would this happen because exactly the same setup worked on older releases. All i did was to compile the new version (2.1.6) and then copy old raddb dir.
I am not sure why i got so many "no debugging symbols found" but i did per doc/bugs instructions. This is gdb output:
Try attached patch.
I didn't try it yet and i am not very good in C. Error that I and Neal had is something regarding OS or...? I don't see anyone else having this problem except me and Neal. Also, i didn't see any comment from Alan. If this is something that was already been discussed here i am sorry for bringing it up again, but i would realy like to hear Alan about this. Boian, would you like to explain what was the cause of this error? Thank you, Igor
I didn't try it yet and i am not very good in C. Error that I and Neal had is something regarding OS or...? I don't see anyone else having this problem except me and Neal. Also, i didn't see any comment from Alan. If this is something that was already been discussed here i am sorry for bringing it up again, but i would realy like to hear Alan about this.
Why? Alan is not the only developer. Read the copyright for rlm_perl code. Ivan Kalik Kalik Informatika ISP
Ivan Kalik wrote:
Why? Alan is not the only developer. Read the copyright for rlm_perl code. I know that Boian is responsible for making our life easier :) I was asking if this patch is going to be included in next release. That is the comment i was expecting. Sorry for misunderstanding.
Igor
On Jul 29, 2009, at 9:32 AM, Igor Smitran wrote:
know that Boian is responsible for making our life easier :) I was asking if this patch is going to be included in next release. That is the comment i was expecting. Sorry for misunderstanding.
Sure I will pull the changes back to repository.
I didn't try it yet and i am not very good in C. Error that I and Neal had is something regarding OS or...? I don't see anyone else having this problem except me and Neal.
The error is in rlm_perl and appears related to thread data management, not the O/S and not perl (I run FreeBSD and you run CentOS; we even have different versions of perl). Boian can explain the change far better than I can; but, my interpretation of the change is that the thread specific data key is now created upon perl module instantiation and stored with the instance data (so there's now a separate key for each perl instance we defined in FreeRadius). (Perhaps someone will correct me if I interpreted it incorrectly.) When you say you're not good in C, if you are mean you are unsure how to apply the patch, try this: 1. Put the .diff file in the directory with rlm_perl.c (src/modules/rlm_perl is the directory). 2. Then use the patch command to update rlm_perl.c (it creates rlm_perl.c.orig as a backup and updates rlm_perl.c): patch rlm_perl.c rlm_perl.diff 3. Rebuild/install FreeRadius from source 4. Test 5. Say thank you to Boian (and Ivan as he helped also)..
Garber, Neal wrote:
The error is in rlm_perl and appears related to thread data management, not the O/S and not perl (I run FreeBSD and you run CentOS; we even have different versions of perl). Boian can explain the change far better than I can; but, my interpretation of the change is that the thread specific data key is now created upon perl module instantiation and stored with the instance data (so there's now a separate key for each perl instance we defined in FreeRadius). (Perhaps someone will correct me if I interpreted it incorrectly.)
When you say you're not good in C, if you are mean you are unsure how to apply the patch, try this:
1. Put the .diff file in the directory with rlm_perl.c (src/modules/rlm_perl is the directory). 2. Then use the patch command to update rlm_perl.c (it creates rlm_perl.c.orig as a backup and updates rlm_perl.c): patch rlm_perl.c rlm_perl.diff 3. Rebuild/install FreeRadius from source 4. Test 5. Say thank you to Boian (and Ivan as he helped also)..
I know how to patch. I was just trying to find out what was the error. That's the part i was thinking of when i said "not good in C" :) You are right, i forgot to say thank you to all. :) Thank you Ivan, thank you Boian. Igor
I know how to patch. I was just trying to find out what was the error.
Igor: I hope you weren't offended by my assumption - I wasn't sure, based upon your comment, and I was just trying to help. If I offended you, I apologize. By the way, out of curiosity, did the patch work for you on 2.1.7 also?
Garber, Neal wrote:
Igor: I hope you weren't offended by my assumption - I wasn't sure, based upon your comment, and I was just trying to help. If I offended you, I apologize. By the way, out of curiosity, did the patch work for you on 2.1.7 also?
Don't worry, i wasn't offended at all. No need to apologize. I am often misunderstood because english is not my native language. I will try to patch 2.1.7 during weekend on my test server. 2.1.6 that i have problems with is on my production server. Recently i wanted to put some extra scripts into it and that's when i ran into rlm_perl problems. Beside rlm_problem server was working just fine. When it crashed because of rlm_perl i made a workaround by using one perl instance and defining different functions. Anyway, i will let you know about my 2.1.7 installation on saturday or sunday. Igor
participants (5)
-
Boian Jordanov -
Garber, Neal -
Igor Smitran -
Ivan Kalik -
sigor＠blic.net