Re: radius 1.3 end with Abort

Anybody have any ideas on this?  I'm still stuck!

Thanks.

-Greg G

Greg G wrote:
> Greg G wrote:
>> Sergey Poznyakoff wrote:
>>> Greg G <[email protected]> wrote:
>>>
>>>  
>>>>  The bottom line on this is that radius seems to operate
>>>> normally up until it actually tries to get data from the database...
>>>>     
>>>
>>> It seems that  radius was built using header files from
>>> one version of mysql and libraries from the other one. Make sure
>>> header files used when building the package correspond to the libraries
>>> being used at the run time.
>>>
>>>   
>>   I don't believe that this is the case.  I only have the one 
>> installation of mysql.  I did check anyway, and the headers in 
>> /usr/include/mysql point to the installed-from-package (5.0.22) 
>> headers.  Same for the libraries.
>
> Here's more information.  After having to do some makefile surgery to 
> change "-g -O2" to "-g" do I could actually debug (--enable-debug 
> notwithstanding), I got the following out of gdb:
>
> (gdb) run -s -f -x=5 -y -z
> Starting program: /usr/local/sbin/radiusd -s -f -x=5 -y -z
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xff1331ac in strlen () from /usr/lib/libc.so.1
> (gdb) where
> #0  0xff1331ac in strlen () from /usr/lib/libc.so.1
> #1  0x7d274 in chop (str=0x556e6978 <Address 0x556e6978 out of 
> bounds>) at sql.c:140
> #2  0x7f6d8 in sql_cache_retrieve (conn=0x26a8b0,
>    query=0x2d12d8 "SELECT attr,value FROM attrib_pws WHERE 
> user_name='ggersh' AND op IS NULL") at sql.c:692
> #3  0x807bc in rad_sql_retrieve_pairs (conn=0x26a8b0,
>    query=0x2d12d8 "SELECT attr,value FROM attrib_pws WHERE 
> user_name='ggersh' AND op IS NULL", return_pairs=0xffbef4d8, op_too=0)
>    at sql.c:995
> #4  0x80a88 in radiusd_sql_reply_attr_query (req=0x271e60, 
> reply_pairs=0xffbef4d8) at sql.c:1052
> #5  0x57348 in user_find_sym (name=0x2735c8 "ggersh", req=0x271e60, 
> check_pairs=0xffbef4d4, reply_pairs=0xffbef4d8) at files.c:336
> #6  0x57814 in user_find (name=0x2735c8 "ggersh", req=0x271e60, 
> check_pairs=0xffbef4d4, reply_pairs=0xffbef4d8) at files.c:431
> #7  0x4c5b4 in sfn_init (m=0xffbef4d0) at auth.c:875
> #8  0x4c308 in rad_authenticate (radreq=0x271e60, activefd=4) at 
> auth.c:790
> #9  0x64a9c in radius_respond (req=0x271eb0) at radius.c:521
> #10 0x6aaac in request_respond (req=0x271eb0) at request.c:117
> #11 0x6ad98 in request_call_handler (handler=0x6aa68 
> <request_respond>, req=0x271eb0) at request.c:187
> #12 0x6bc80 in request_handle (req=0x271eb0, handler=0x6aa68 
> <request_respond>) at request.c:394
> #13 0x67454 in udp_input_handler (fd=4, data=0x2688e8) at radiusd.c:1075
> #14 0x5c774 in channel_handle (chan=0x2621d0) at input.c:137
> #15 0x5cd80 in input_select (input=0x2626e0, tv=0x0) at input.c:256
> #16 0x66ccc in radiusd_main_loop () at radiusd.c:852
> #17 0x66534 in radiusd_main () at radiusd.c:580
> #18 0x6654c in radiusd_start () at radiusd.c:589
> #19 0x6667c in main (argc=6, argv=0xffbefcbc) at radiusd.c:624
>
> I went directly to mysql and ran the query that sql_cache_retrieve 
> doesn't seem to like:
>
> mysql> SELECT attr,value FROM attrib_pws WHERE user_name='ggersh' AND 
> op IS NULL;
> +----------------+---------------------------------+
> | attr           | value                           |
> +----------------+---------------------------------+
> | Unix-FTP-GID   | 10                              |
> | Unix-FTP-Home  | /web2/httpd-users/htdocs/ggersh |
> | Unix-FTP-Shell | /bin/ftpshell                   |
> | Unix-FTP-UID   | 34490                           |
> +----------------+---------------------------------+
> 4 rows in set (0.01 sec)
>
> So, there's still something busted here.  Is there anything else I can 
> give to help debug this?
>
> Thanks.
>
> -Greg G
>
>
>
>
> _______________________________________________
> Help-gnu-radius mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/help-gnu-radius