Re: radius 1.3 end with Abort

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