Seg-fault with proxy and fail-overs

[Chris Moules]

Please find attached the gdb output.

When running inside gdb, if I did not supply the '-X' arg then I just got something along the lines of 'the program terminated
normally' right away. I guess it forked off and gdb did not follow.

All this server is doing is reading a log file and sending it to the home server. This server is known to have issues and be
unresponsive at times. All accounting data is also stored locally.

Thanks for any help on this.

Chris

Alan DeKok wrote:
> Chris Moules wrote:
>> The system seems to run fine for some time. Then I get a Seg-Fault. I
>> was quickly able to isolate one clear cause for a
>> seg-fault, which was my 'copy-acct-to-home-server' setup. Disabling the
>> virtual server made the system run, apparently, fine.
>> Setting up this virtual server independently by duplicating and suitably
>> modifying the configuration and running with the '-d'
>> option I was able to watch this system run. It was happily reading from
>> the log file and sending the data to the home-server.
>> After a number of records, (I noted 50-300 on various runs), the
>> freeradius process would segfault. This happend, as far as I
>> could see, always after the home-server failed to respond within the
>> timeout (response_window) and so failed.
> 
>   Ugh.
> 
>   There are ways to track this down, but it involves re-building the
> server with debugging symbols.
> 
>> I have been trying to get a core file from the system without success
>> (very embarrassing):
>> ulimit -c -> unlimited
>> allow_core_dumps = yes
>> cat /proc/sys/kernel/core_pattern -> core
>> The freeradius user has write access to the location where I execute the
>> program.
> 
>   Run it in a "screen" output, under "gdb".  See doc/bugs for instructions.
> 
>> Doing an strace of the process was not very insightful:
> 
>   That won't tell you much,
> 
>> Doing a 'kill -TERM' to the process when _not_ processing data produced
>> this:
> ...
>> *** glibc detected *** freeradius: corrupted double-linked list:
>> 0x000000000083b1f0 ***
> ...
>> /usr/lib/freeradius/libfreeradius-radius-2.1.4.so(fr_hash_table_free+0x93)[0x7fbe1c69db63]
>> /usr/lib/freeradius/libfreeradius-radius-2.1.4.so(dict_free+0x7a)[0x7fbe1c69c1da]
> 
>   Hmm... that's not good.  It's not serious, but it's not good.
> 
>   The problem is I don't see that on my test systems.
> 
>   Some more output from "gdb" after a crash would be *enormously* helpful.
> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-radiusd.log
Type: text/x-log
Size: 2759 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20090304/e1f89df7/attachment.bin>