Problem with custom accounting module.

[Bill Schoolfield]

Well, I tried it on 2.2.4 and same thing. I have compared the setup to 
other sites and I can't see any difference. Here is gdb at the point 
this function is called:

> #0  billmax_accounting (instance=0x8222a88, request=0x82415e0) at rlm_billmax.c:662
> #1  0x0806534b in call_modsingle (request=<value optimized out>, component=3, depth=1, entry=0xbffff21c) at modcall.c:305
> #2  modcall_recurse (request=<value optimized out>, component=3, depth=1, entry=0xbffff21c) at modcall.c:579
> #3  0x080646a7 in modcall_child (request=<value optimized out>, component=<value optimized out>, depth=1, entry=0xbffff210, c=0x8239530, result=0xbffff1dc) at modcall.c:423
> #4  0x0806487c in modcall_recurse (request=<value optimized out>, component=3, depth=0, entry=0xbffff210) at modcall.c:628
> #5  0x080658a9 in modcall (component=3, c=0x8239570, request=0x82415e0) at modcall.c:877
> #6  0x08060e80 in indexed_modcall (comp=3, idx=0, request=0x82415e0) at modules.c:750
> #7  0x0806121c in module_accounting (acct_type=0, request=0x82415e0) at modules.c:1617
> #8  0x0804e38c in rad_accounting (request=0x82415e0) at acct.c:94
> #9  0x08072c75 in radius_handle_request (request=0x82415e0, fun=0x804e2d0 <rad_accounting>) at event.c:3838
> #10 0x0806978f in thread_pool_addrequest (request=0x82415e0, fun=0x804e2d0 <rad_accounting>) at threads.c:948
> #11 0x08074182 in event_socket_handler (xel=<value optimized out>, fd=18, ctx=0x8240ad0) at event.c:3485
> #12 0x00129b12 in fr_event_loop (el=0x823d180) at event.c:415
> #13 0x0806f206 in radius_event_process () at event.c:3824
> #14 0x080661fe in main (argc=2, argv=0xbffff804) at radiusd.c:488
> (gdb) print request
> $1 = (REQUEST *) 0x82415e0
> (gdb) print *request
> $2 = {magic = 136582416, packet = 0x0, proxy = 0x82416a0, reply = 0x0, proxy_reply = 0x0, config_items = 0x8241748, username = 0x0, password = 0x808fcc0, root = 0x0,
>   data = 0x81d51e0, client = 0x0, thread_id = 1397840998, timestamp = 0, number = 136579792, listener = 0x0, proxy_listener = 0x0, simul_max = 0, simul_count = 0, simul_mpp = 2,
>   options = 136340544, module = 0x8087b0a "accounting", component = 0x53515c66 <Address 0x53515c66 out of bounds>, received = {tv_sec = 351944, tv_usec = 1397840999}, when = {
>     tv_sec = 351944, tv_usec = 1000000}, delay = 1, master_state = 2, child_state = 3, priority = 136582952, ev = 0x0, next_when = {tv_sec = 0, tv_usec = 0}, next_callback = 0x1,
>   in_request_hash = 0, in_proxy_hash = 0, home_server = 0x0, home_pool = 0x0, proxy_when = {tv_sec = 0, tv_usec = 0}, num_proxied_requests = 0, num_proxied_responses = 0,
>   server = 0x0, parent = 0x805eed0, radlog = 0, coa = 0x0, num_coa_requests = 0}

Maybe somehow the configuration is different or the test accounting data 
is causing this. Again, let me know what data (logs/listings) I need to 
send that will help identify the problem.

Thanks again for your assistance.


On 4/18/2014 6:45 AM, Phil Mayers wrote:
> On 18/04/2014 05:03, Bill Schoolfield wrote:
>
>> Could this be a thread issue? How can I debug this further?
>
> Why would you bother? If it's a code bug, you will inevitably have to
> patch and rebuild. Deploying a patched 2.1.12 is madness. Try again on
> 2.x.x HEAD and see if it's still present. If not, deploy 2.2.4 or 2.2.5
> if it's out by then. If it is still present, then debug.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/devel.html