[Kamailio-Users] registrar lookups without reason

[Daniel-Constantin Mierla]

On 02.09.2009 10:46 Uhr, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>  > you can put abort() in some if conditions - e.g., based on src ip, some 
>  > header/uri value.
>
> daniel,
>
> i tried that on my own system and got a core dump from normal lookup()
> call.  however, when i look at the core, it doesn't tell me much why
> this normal lookup() was executed:
>   

from the trace seems that lot of nested IFs are executed on true branch 
(action.c:746) and then lookup (action.c:874).

Just got a new idea -- print the line for each executed action -- in 
action.c, in function do_action() add at beginning:

LM_ERR("***** executing action at line: %d\n", a->line);

That should give the trace of cfg lines which were executed.

Cheers,
Daniel

> #0  0xb7f00424 in __kernel_vsyscall ()
> #1  0xb7c07640 in raise () from /lib/i686/cmov/libc.so.6
> #2  0xb7c09018 in abort () from /lib/i686/cmov/libc.so.6
> #3  0xb78817ae in lookup (_m=0x821c848, _t=0xb3437370 "@sC?", _s=0x0)
>     at lookup.c:80
> #4  0x080564e1 in do_action (a=0x81ce2a0, msg=0x821c848) at action.c:874
> #5  0x08055518 in run_action_list (a=0x81c9878, msg=0x821c848) at action.c:145
> #6  0x080578a0 in do_action (a=0x81bfda0, msg=0x821c848) at action.c:120
> #7  0x08055518 in run_action_list (a=0x81befe8, msg=0x821c848) at action.c:145
> #8  0x08057b0d in do_action (a=0x81bfe70, msg=0x821c848) at action.c:746
> #9  0x08055518 in run_action_list (a=0x81bd468, msg=0x821c848) at action.c:145
> #10 0x080578a0 in do_action (a=0x81abb80, msg=0x821c848) at action.c:120
> #11 0x08055518 in run_action_list (a=0x81aa6d8, msg=0x821c848) at action.c:145
> #12 0x08057b0d in do_action (a=0x81abc50, msg=0x821c848) at action.c:746
> #13 0x08055518 in run_action_list (a=0x81a9ed8, msg=0x821c848) at action.c:145
> #14 0x080578a0 in do_action (a=0x818ed40, msg=0x821c848) at action.c:120
> #15 0x08055518 in run_action_list (a=0x818b8b0, msg=0x821c848) at action.c:145
> #16 0x08057b0d in do_action (a=0x818ee10, msg=0x821c848) at action.c:746
> #17 0x08055518 in run_action_list (a=0x81877e0, msg=0x821c848) at action.c:145
> #18 0x080578a0 in do_action (a=0x8186b80, msg=0x821c848) at action.c:120
> #19 0x08055518 in run_action_list (a=0x8185400, msg=0x821c848) at action.c:145
> #20 0x080588d1 in run_top_route (a=0x8185400, msg=0x821c848) at action.c:120
> #21 0x08086c0d in receive_msg (
>     buf=0x8156180 "INVITE sip:test at test.fi SIP/2.0\r\nRecord-Route: <sip:192.98.101.10;lr;ftag=rxruz>\r\nVia: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bK6c7e.6e29b5d.0\r\nVia: SIP/2.0/UDP 87.95.45.109:5074;received=87.95.45.1"..., 
>     len=1178, rcv_info=0xbfc1a2d0) at receive.c:175
> #22 0x080b60bf in udp_rcv_loop () at udp_server.c:449
> #23 0x0806c38c in main (argc=15, argv=0xbfc1a454) at main.c:774
>
> does it tell to you, i.e., does it make sense to make this exercise in
> production system where the problem occurs?
>
> -- juha
>   

-- 
Daniel-Constantin Mierla
* http://www.asipto.com/