hi, latest git pull (clean clone) <snip> Making all in src/modules/rlm_sqlippool... Making all in src/modules/rlm_unix... Making all in src/modules/rlm_utf8... Making all in src/modules/rlm_wimax... Making all in src/main... /usr/src/freeradius-server/libtool --quiet --mode=link gcc -export-dynamic -dlopen self \ -o radiusd acct.lo auth.lo client.lo conffile.lo crypt.lo exec.lo files.lo listen.lo log.lo mainconfig.lo modules.lo modcall.lo radiusd.lo stats.lo soh.lo connection.lo session.lo threads.lo util.lo valuepair.lo version.lo xlat.lo process.lo realms.lo evaluate.lo vmps.lo detail.lo cb.lo tls.lo \ /usr/src/freeradius-server/src/lib/libfreeradius-radius.la -lnsl -lresolv -lpthread \ -lcrypt /usr/src/freeradius-server/libltdl/libltdl.la -lcrypto -lssl -lcrypto .libs/listen.o: In function `listen_bind': /usr/src/freeradius-server/src/main/listen.c:2070: undefined reference to `memcset' collect2: ld returned 1 exit status gmake[4]: *** [radiusd] Error 1 gmake[3]: *** [main] Error 2 gmake[2]: *** [all] Error 2 gmake[1]: *** [src] Error 2 make: *** [all] Error 2 guessing this is a typo on line 2070 of listen.c memcset > memset ? alan
On 18 Nov 2011, at 23:53, Alan Buxey wrote:
hi,
latest git pull (clean clone)
<snip> Making all in src/modules/rlm_sqlippool... Making all in src/modules/rlm_unix... Making all in src/modules/rlm_utf8... Making all in src/modules/rlm_wimax... Making all in src/main... /usr/src/freeradius-server/libtool --quiet --mode=link gcc -export-dynamic -dlopen self \ -o radiusd acct.lo auth.lo client.lo conffile.lo crypt.lo exec.lo files.lo listen.lo log.lo mainconfig.lo modules.lo modcall.lo radiusd.lo stats.lo soh.lo connection.lo session.lo threads.lo util.lo valuepair.lo version.lo xlat.lo process.lo realms.lo evaluate.lo vmps.lo detail.lo cb.lo tls.lo \ /usr/src/freeradius-server/src/lib/libfreeradius-radius.la -lnsl -lresolv -lpthread \ -lcrypt /usr/src/freeradius-server/libltdl/libltdl.la -lcrypto -lssl -lcrypto .libs/listen.o: In function `listen_bind': /usr/src/freeradius-server/src/main/listen.c:2070: undefined reference to `memcset' collect2: ld returned 1 exit status gmake[4]: *** [radiusd] Error 1 gmake[3]: *** [main] Error 2 gmake[2]: *** [all] Error 2 gmake[1]: *** [src] Error 2 make: *** [all] Error 2
guessing this is a typo on line 2070 of listen.c memcset > memset ?
Looks like it. Pushed a fix... -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
hi, Making all in src/modules/rlm_jradius... CC rlm_jradius.c CC rlm_jradius.c rlm_jradius.c: In function 'pack_vps': rlm_jradius.c:650: error: 'VALUE_PAIR' has no member named 'lvalue' rlm_jradius.c:653: error: 'VALUE_PAIR' has no member named 'lvalue' rlm_jradius.c:657: error: 'VALUE_PAIR' has no member named 'lvalue' rlm_jradius.c: In function 'read_vps': rlm_jradius.c:820: error: 'VALUE_PAIR' has no member named 'lvalue' rlm_jradius.c:825: error: 'VALUE_PAIR' has no member named 'lvalue' rlm_jradius.c:831: error: 'VALUE_PAIR' has no member named 'lvalue' gmake[6]: *** [rlm_jradius.lo] Error 1 gmake[5]: *** [rlm_jradius] Error 2 gmake[4]: *** [all] Error 2 gmake[3]: *** [modules] Error 2 gmake[2]: *** [all] Error 2 gmake[1]: *** [src] Error 2 make: *** [all] Error 2 alan
Hi,
Alan Buxey wrote:
hi,
Making all in src/modules/rlm_jradius...
Fixed && pushed.
still failes. VALUE_PAIR issue line 659 in rlm_jradius.c guess that: case PW_TYPE_DATE: if (pack_uint32(ba, vp->vp_datex) == -1) return -1; break; should be: case PW_TYPE_DATE: if (pack_uint32(ba, vp->vp_date) == -1) return -1; break; alan
hi, hmmm. latest GIT doesnt get far when running....it just appears to lock/freeze up after initiaing the SQL module and importing the list of clients - this is with postgreSQL . last line of output with radiusd -X is just rlm_sql (postgresdb): Released connection (9) postgresdb is our name for the SQL instance noted that there had been some process.c changes - this could cause this behaviour? ...what would the server be doing after this? I disabled the buffered-sql virtual server - but then it froze the same when instantiating the sql module in one of the other virtual servers instead....so something not quite right in the 'i'm done!' part of the module ? alan
Alan Buxey wrote:
hmmm. latest GIT doesnt get far when running....it just appears to lock/freeze up after initiaing the SQL module and importing the list of clients - this is with postgreSQL .
Hmm... it could be the changes I made to minimize the size of the VALUE_PAIR structure. The previous code made certain... odd... assumptions that may no longer be true. I may have missed one or two places where it still does something odd. Maybe reverting change b14fc9d3d9781186 might help. If so, I'll have to take a deeper look at the changes. Alan DeKok.
Hi,
Alan Buxey wrote:
hmmm. latest GIT doesnt get far when running....it just appears to lock/freeze up after initiaing the SQL module and importing the list of clients - this is with postgreSQL .
Hmm... it could be the changes I made to minimize the size of the VALUE_PAIR structure. The previous code made certain... odd... assumptions that may no longer be true. I may have missed one or two places where it still does something odd.
Maybe reverting change b14fc9d3d9781186 might help.
being naive here, git revert -n b14fc9d3d9781186 ?? doesnt seem to change anything. by the way, realms.c line 1634 if (!auth_pool || auth_pool_name && (strcmp(auth_pool_name, acct_pool_name) != 0) ) { do_print = TRUE; } assume that should read: if (!auth_pool || (auth_pool_name && (strcmp(auth_pool_name, acct_pool_name) != 0) )) { do_print = TRUE; } ? alan
Hi, aha! looks like something in the connection tracker... git revert -n 40fb9e21a9da5de3f3742c5f9a99e5a4db1e1b6a git revert -n d73391a9c48460efc27f7c7ec592281d5e4491e9 make clean make make install radiusd -fxx -l stdout all works again PS love 'radiusd -xv' - thats a useful list of functionality! :-)
Alan Buxey wrote:
looks like something in the connection tracker...
OK... which modules are you using? IIRC, only the redis module in 3.0 uses the connection tracker. It sounds like a mutex lock issue. Can you get a gdb backtrace when it's locked?
PS love 'radiusd -xv' - thats a useful list of functionality! :-)
Yup. It was needed for a while, I think. Alan DeKok.
Hi,
It sounds like a mutex lock issue. Can you get a gdb backtrace when it's locked?
Might be. Try "git pull".
looks like it is working. server starts rather than hanging at that stage. however, like my run from last night - which i was goign to report - it dies after receiving the first request - with a Segmentation fault - will do a debug of it... ..and here you go: [New Thread 0x9075db90 (LWP 30226)] Detaching after fork from child process 30227. Detaching after fork from child process 30228. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x9115eb90 (LWP 30225)] 0x0012756a in paircopyvp (vp=0x29) at valuepair.c:377 377 if (!vp->flags.unknown_attr) { 65 Thread 0x9075db90 (LWP 30226) 0x00468402 in __kernel_vsyscall () * 64 Thread 0x9115eb90 (LWP 30225) 0x0012756a in paircopyvp (vp=0x29) at valuepair.c:377 63 Thread 0x91b5fb90 (LWP 30224) 0x00468402 in __kernel_vsyscall () 62 Thread 0x92560b90 (LWP 30223) 0x00468402 in __kernel_vsyscall () 61 Thread 0x92f61b90 (LWP 30222) 0x00468402 in __kernel_vsyscall () 60 Thread 0x93962b90 (LWP 30221) 0x00468402 in __kernel_vsyscall () 59 Thread 0x94363b90 (LWP 30220) 0x00468402 in __kernel_vsyscall () 58 Thread 0x94d64b90 (LWP 30219) 0x00468402 in __kernel_vsyscall () 57 Thread 0x95765b90 (LWP 30218) 0x00468402 in __kernel_vsyscall () 56 Thread 0x96166b90 (LWP 30217) 0x00468402 in __kernel_vsyscall () 55 Thread 0x96b67b90 (LWP 30216) 0x00468402 in __kernel_vsyscall () 54 Thread 0x97568b90 (LWP 30215) 0x00468402 in __kernel_vsyscall () 53 Thread 0x97f69b90 (LWP 30214) 0x00468402 in __kernel_vsyscall () 52 Thread 0x9896ab90 (LWP 30213) 0x00468402 in __kernel_vsyscall () 51 Thread 0x9936bb90 (LWP 30212) 0x00468402 in __kernel_vsyscall () 50 Thread 0x99d6cb90 (LWP 30211) 0x00468402 in __kernel_vsyscall () 49 Thread 0x9a76db90 (LWP 30210) 0x00468402 in __kernel_vsyscall () 48 Thread 0x9b16eb90 (LWP 30209) 0x00468402 in __kernel_vsyscall () 47 Thread 0x9bb6fb90 (LWP 30208) 0x00468402 in __kernel_vsyscall () 46 Thread 0x9c570b90 (LWP 30207) 0x00468402 in __kernel_vsyscall () 45 Thread 0x9cf71b90 (LWP 30206) 0x00468402 in __kernel_vsyscall () 44 Thread 0x9d972b90 (LWP 30205) 0x00468402 in __kernel_vsyscall () 43 Thread 0x9e373b90 (LWP 30204) 0x00468402 in __kernel_vsyscall () 42 Thread 0x9ed74b90 (LWP 30203) 0x00468402 in __kernel_vsyscall () 41 Thread 0x9f775b90 (LWP 30202) 0x00468402 in __kernel_vsyscall () 40 Thread 0xa0176b90 (LWP 30201) 0x00468402 in __kernel_vsyscall () 39 Thread 0xa0b77b90 (LWP 30200) 0x00468402 in __kernel_vsyscall () 38 Thread 0xa1578b90 (LWP 30199) 0x00468402 in __kernel_vsyscall () 37 Thread 0xa1f79b90 (LWP 30198) 0x00468402 in __kernel_vsyscall () 36 Thread 0xa297ab90 (LWP 30197) 0x00468402 in __kernel_vsyscall () 35 Thread 0xa337bb90 (LWP 30196) 0x00468402 in __kernel_vsyscall () 34 Thread 0xa3d7cb90 (LWP 30195) 0x00468402 in __kernel_vsyscall () 33 Thread 0xa477db90 (LWP 30194) 0x00468402 in __kernel_vsyscall () 32 Thread 0xa517eb90 (LWP 30193) 0x00468402 in __kernel_vsyscall () 31 Thread 0xa5b7fb90 (LWP 30192) 0x00468402 in __kernel_vsyscall () 30 Thread 0xa6580b90 (LWP 30191) 0x00468402 in __kernel_vsyscall () 29 Thread 0xa6f81b90 (LWP 30190) 0x00468402 in __kernel_vsyscall () 28 Thread 0xa7982b90 (LWP 30189) 0x00468402 in __kernel_vsyscall () 27 Thread 0xa8383b90 (LWP 30188) 0x00468402 in __kernel_vsyscall () 26 Thread 0xa8d84b90 (LWP 30187) 0x00468402 in __kernel_vsyscall () 25 Thread 0xa9785b90 (LWP 30186) 0x00468402 in __kernel_vsyscall () 24 Thread 0xaa186b90 (LWP 30185) 0x00468402 in __kernel_vsyscall () 23 Thread 0xaab87b90 (LWP 30184) 0x00468402 in __kernel_vsyscall () 22 Thread 0xab588b90 (LWP 30183) 0x00468402 in __kernel_vsyscall () 21 Thread 0xabf89b90 (LWP 30182) 0x00468402 in __kernel_vsyscall () 20 Thread 0xac98ab90 (LWP 30181) 0x00468402 in __kernel_vsyscall () 19 Thread 0xad38bb90 (LWP 30180) 0x00468402 in __kernel_vsyscall () 18 Thread 0xadd8cb90 (LWP 30179) 0x00468402 in __kernel_vsyscall () 17 Thread 0xae78db90 (LWP 30178) 0x00468402 in __kernel_vsyscall () 16 Thread 0xaf18eb90 (LWP 30177) 0x00468402 in __kernel_vsyscall () 15 Thread 0xafb8fb90 (LWP 30176) 0x00468402 in __kernel_vsyscall () 14 Thread 0xb0590b90 (LWP 30175) 0x00468402 in __kernel_vsyscall () 13 Thread 0xb0f91b90 (LWP 30174) 0x00468402 in __kernel_vsyscall () 12 Thread 0xb1992b90 (LWP 30173) 0x00468402 in __kernel_vsyscall () 11 Thread 0xb2393b90 (LWP 30172) 0x00468402 in __kernel_vsyscall () 10 Thread 0xb2d94b90 (LWP 30171) 0x00468402 in __kernel_vsyscall () 9 Thread 0xb3795b90 (LWP 30170) 0x00468402 in __kernel_vsyscall () 8 Thread 0xb4196b90 (LWP 30169) 0x00468402 in __kernel_vsyscall () 7 Thread 0xb4b97b90 (LWP 30168) 0x00468402 in __kernel_vsyscall () 6 Thread 0xb5598b90 (LWP 30167) 0x00468402 in __kernel_vsyscall () 5 Thread 0xb5f99b90 (LWP 30166) 0x00468402 in __kernel_vsyscall () 4 Thread 0xb699ab90 (LWP 30165) 0x00468402 in __kernel_vsyscall () 3 Thread 0xb739bb90 (LWP 30164) 0x00468402 in __kernel_vsyscall () 2 Thread 0xb7d9cb90 (LWP 30163) 0x00468402 in __kernel_vsyscall () 1 Thread 0xb7ff16d0 (LWP 30150) 0x00468402 in __kernel_vsyscall () Thread 64 (Thread 0x9115eb90 (LWP 30225)): #0 0x0012756a in paircopyvp (vp=0x29) at valuepair.c:377 n = <value optimized out> #1 0x0012765a in paircopy2 (vp=0x29, attr=0, vendor=0) at valuepair.c:426 first = 0x9ddf880 n = <value optimized out> last = 0x9ddf9ac #2 0x001276bd in paircopy (vp=0x9991c08) at valuepair.c:441 No locals. #3 0x006c8f4f in perl_store_vps (vp=0x9991c08, rad_hv=0x9d68978) at rlm_perl.c:555 nvp = 0x6c8f0d vpa = 0x8885f0 vpn = <value optimized out> av = 0x9aed040 namebuf = "P\243\305\t\000\006\342\000@\022\211\000\001\000\000\000\344\317\025\221\230\317\025\221\214h2\000(Ю\t\000\000\000\000h\317\025\221\001\334&\000\200\370\335\t\214h2\000 \320\025\221x\272\231\b\264zl\000\001\000\000\000\064\335/\000\214h2\000D\000R2\000\000\000\000\000\000\000\000#\206(\000\240\375\230\t(\000\000\000\000\000\000\000ef\"\000\240\375\230\t@Ю\t'\264\060\000\000\000\000\000\000\000\000\000x\006\325\t\370\317\025\221\033\207(\000(Ю\t\240\375\230\t\370\317\025\221U\211(\000\240\375\230\t(Ю\t\030, \000(\277\231\b\005\000\000\000\377\377\377\377\300\017\211\000\264sl\000x\272\231\b0\320\025\221\270.\210\000\060\274\231\b\000\000\000\000\001\000\000\000\000\006\342\000\214h2\000\001\000\000\000\240\375\230\tH\320\025\221ۻ!\000\240\375\230\t\302\310l\000\001\000\000\000\v\000\000\000\270\320\025\221" name = 0x9115cb78 "DBI:^z'" buffer = "p\241\236\000DBI::\000\236\000x\313\025\221\310\314\025\221\240\375\230\t@\241\236\000\310\314\025\221\000\000\000\000D\307\317\tx\313\025\221\070\323\342\t@\241\236\000,\307\317\t \000\000\000\004\000\000\000 \000\000\000DBI:^z'\000\t\000\000\000k\366\217\000\364\217\236\000@\241\236\000@\323\342\t\350\313\025\221\246\004\220\000\350Z\334\t\000\000\000\000\000\000\000\000l_\335\t\240\375\230\t\b\000\000\000\220\276\324\t\350\272\326\t\000\000\000\000\212\020d\000\300\017\211\000\v\000\000(^z'\000L\314\025\221\375\351\207\000\370\313\025\000\214h2\000\311\315\025\221\b\000\000\000\b\314\025\221\230d\331\t\000\000\000\000\000\000\000\000@Ю\t^z'\000\n\000\000\000\360\343\333\th\340\256\t\000\000\000\000\240\375\230\tl_\335\t\v\000\000(\244$\301\t\000\000\000\000\000\000\000\000@Ю\t\240\375\230\t\v\000\000\000\300\212\301\th\340\256\t\000\000\000\000\270\314\025\221\n\000\000\000\v\000\000(\b\000\000\000\000\000\000\000\270:\225\b\310\315\025\000\214h2"... len = <value optimized out> #4 0x006c976e in rlmperl_call (instance=0x899ca68, request=0x996f0d0, function_name=0x899cdd0 "post_auth") at rlm_perl.c:708 sp = 0x9e26d70 vp = <value optimized out> exitstatus = 1 n_a = <value optimized out> rad_reply_hv = 0x9d68978 rad_check_hv = 0x9dbc4f4 rad_config_hv = 0x9d68dc8 rad_request_hv = 0x9d68ad4 rad_request_proxy_hv = 0x9dda840 rad_request_proxy_reply_hv = 0x9dfbd84 interp = <value optimized out> #5 0x08067788 in call_modsingle (component=7, c=0x94109f0, request=0x996f0d0) at modcall.c:298 No locals. #6 modcall (component=7, c=0x94109f0, request=0x996f0d0) at modcall.c:783 myresult = <value optimized out> stack = {pointer = 0, priority = {0, 3, 0 <repeats 11 times>, 3, 3, 0 <repeats 17 times>}, result = {7, 2, 0 <repeats 11 times>, 2, 2, 6, 0 <repeats 16 times>}, children = {0x94109f0, 0x9410a40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x93ff0d0, 0x0 <repeats 19 times>}, start = { 0x0, 0x9410988, 0x0 <repeats 11 times>, 0x93ff120, 0x940fb80, 0x0 <repeats 17 times>}} parent = 0x94109f0 child = 0x9410a40 if_taken = 0 was_if = 0 #7 0x08063f2c in indexed_modcall (comp=7, idx=0, request=0x996f0d0) at modules.c:781 rcode = <value optimized out> list = 0x94109f0 server = 0x0 #8 0x0806414c in module_post_auth (postauth_type=0, request=0x996f0d0) at modules.c:1700 No locals. #9 0x08050b6f in rad_postauth (request=0x996f0d0) at auth.c:432 result = <value optimized out> postauth_type = 41 vp = 0x0 #10 0x080512ac in rad_authenticate (request=0x996f0d0) at auth.c:801 namepair = 0x998f8a8 check_item = 0x0 auth_item = 0x99734b8 module_msg = <value optimized out> tmp = 0x9991ab0 result = 0 autz_retry = <value optimized out> autz_type = <value optimized out> #11 0x08075ed3 in request_running (request=0x996f0d0, action=1) at process.c:1156 __FUNCTION__ = "request_running" #12 0x0806d775 in request_handler_thread (arg=0x9947778) at threads.c:536 No locals. #13 0x009fb832 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #14 0x0096646e in clone () from /lib/libc.so.6 No symbol table info available. alan
Alan Buxey wrote:
looks like it is working. server starts rather than hanging at that stage.
Good.
however, like my run from last night - which i was goign to report - it dies after receiving the first request - with a Segmentation fault - will do a debug of it...
Ugh. I have my suspicions. Revert the previous commit I mentioned b14fc9d3d, and see if that helps. Alan DeKok.
Hi,
Ugh. I have my suspicions. Revert the previous commit I mentioned b14fc9d3d, and see if that helps.
b14fc9d3d978118617dfce7689f2ea154883c993 yep - looks to be 'normal' now. requests being dealt with straight away no segfault, poller for detail file operating etc alan
Alan Buxey wrote:
yep - looks to be 'normal' now.
Arg.
requests being dealt with straight away no segfault, poller for detail file operating etc
I've pushed a fix, and some more changes which start (again) going down the path of decreasing memory usage. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell