On Thu, Dec 20, 2001 at 03:40:06PM -0500, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > This is gdb out of 'bt'
> > +++ START
> > #0 0x4001a96d in sql_userparse () at eval.c:88
> > #1 0x4001aa61 in sql_getvpdata () at eval.c:88
>
> There is NO 'eval.c' anywhere in the server source tree.
>
> The server is STILL using old libraries. Find them, delete them,
> re-install, and the problem will go away.
>
> Alan DeKok.
Hi!
I believe that problem still exists. Running FreeBSD-4.5-PRERELEASE, but
it doesn't matter much in this case...
radiusd with PostgreSQL support is crashing _very_ frequently when it's
started as
radiusd -d /usr/local/etc/raddb
It takes a little longer when it's running in foreground in debug
mode (with -X )
And about an hour - under gdb. But it crashes anyway in the end :(
Here's my log:
Screen output:
sql_set_user: escaped user --> 'icnk4'
radius_xlat: 'SELECT id,UserName,Attribute,Value FROM radcheck WHERE Username =
'icnk4' ORDER BY id'
query: SELECT id,UserName,Attribute,Value FROM radcheck WHERE Username = 'icnk4'
ORDER BY id
rlm_postgresql Status: PGRES_TUPLES_OK
sql_postgresql: affected rows =
Program received signal SIGSEGV, Segmentation fault.
0x281f06e5 in sql_userparse (first_pair=0xbfbfca60, row=0x8118060, mode=1)
at sql.c:266
266 if (row[4] != NULL && strlen(row[4]) > 0) {
gdb:
(gdb) bt
#0 0x281f06e5 in sql_userparse (first_pair=0xbfbfca60, row=0x8118060, mode=1) at
sql.c:266
#1 0x281f07d5 in sql_getvpdata (inst=0x80b28c0, sqlsocket=0x80b2b20, pair=0xbfbfca60,
query=0xbfbfcc6c "SELECT id,UserName,Attribute,Value FROM radcheck WHERE User name =
'icnk4' ORDER BY id", mode=1) at sql.c:298
#2 0x281ef7ec in rlm_sql_authorize (instance=0x80b28c0, request=0x8095600) at
rlm_sql.c:216
#3 0x8054d22 in call_modsingle (component=1, sp=0x809dac0, request=0x8095600,
default_result=6) at modcall.c:205
#4 0x8054e74 in modcall (component=1, c=0x809dac0, request=0x8095600) at modcall.c:288
#5 0x8054d73 in call_modgroup (component=1, g=0x809da00, request=0x8095600,
default_result=6) at modcall.c:227
#6 0x8054e33 in modcall (component=1, c=0x809da00, request=0x8095600) at modcall.c:281
#7 0x8054633 in indexed_modcall (comp=1, idx=0, request=0x8095600) at modules.c:456
#8 0x8054959 in module_authorize (request=0x8095600) at modules.c:631
#9 0x8051764 in rad__authenticate (request=0x8095600) at auth.c:524
#10 0x804d394 in rad_respond (request=0x8095600, fun=0x8051604 <rad_authenticate>) at
radiusd.c:1492
#11 0x804d008 in rad_process (request=0x8095600, dospawn=0) at radiusd.c:1252
#12 0x804ccf1 in main (argc=2, argv=0xbfbffac0) at radiusd.c:1060
#13 0x804b989 in _start ()
Regards,
--
Igor A. Karpov phone: +380(44)238-0624
Unix System Administrator
A heap is just a stack that tipped over.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
