Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#368 core dump on BYE using validate_dialog

1.6.x
closed-invalid
modules (454)
5
2011-07-10
2011-04-04
Richard Revels
No

I will add to this ticket as I collect new information about it. Right now I know that validate_dialog has some problems when two legs of the same call are run through the same proxy. user a --> proxy a --> proxy b --> proxy a --> user b. The biggest problem I have found is on the BYE when user a hangs up first. The call to validate_dialog results in one of the route headers being removed which, in my config, results in an error response from proxy b. I don't remember why but that's not the big problem anyway. When the second BYE hits proxy a from user b, a segfault occurs on proxy a in strtoint called from dlg_validate_dialog.

Here is a backtrace:

#0 0x00002b52e538f210 in str2int (req=0x84fa00, dlg=0x2b52e8262030) at ../tm/../../ut.h:434
#1 dlg_validate_dialog (req=0x84fa00, dlg=0x2b52e8262030) at dlg_handlers.c:1257
#2 0x00002b52e5384e2b in w_validate_dialog (req=0x84fa00) at dialog.c:773
#3 0x000000000040f817 in do_action (a=0x7ae600, msg=0x84fa00) at action.c:1195
#4 0x0000000000413369 in run_action_list (a=<value optimized out>, msg=0x84fa00) at action.c:140
#5 0x000000000046aa08 in eval_elem (e=0x7ae6d8, msg=0x84fa00, val=0x0) at route.c:1354
#6 0x000000000046d1aa in eval_expr (e=0x1, msg=0x84fa00, val=0x0) at route.c:1696
#7 0x000000000046d16b in eval_expr (e=0x7ae728, msg=0x84fa00, val=0x0) at route.c:1712
#8 0x000000000046d09b in eval_expr (e=0x7ae778, msg=0x84fa00, val=0x0) at route.c:1717
#9 0x000000000040ea75 in do_action (a=0x7aeaa8, msg=0x84fa00) at action.c:802
#10 0x0000000000413369 in run_action_list (a=<value optimized out>, msg=0x84fa00) at action.c:140
#11 0x0000000000410fef in do_action (a=0x7aeb80, msg=0x84fa00) at action.c:819
#12 0x0000000000413369 in run_action_list (a=<value optimized out>, msg=0x84fa00) at action.c:140
#13 0x0000000000410fef in do_action (a=0x7b5470, msg=0x84fa00) at action.c:819
#14 0x0000000000413369 in run_action_list (a=<value optimized out>, msg=0x84fa00) at action.c:140
#15 0x0000000000411fc3 in do_action (a=0x7ceae8, msg=0x84fa00) at action.c:1173
#16 0x0000000000413369 in run_action_list (a=<value optimized out>, msg=0x84fa00) at action.c:140
#17 0x00000000004136bb in run_actions (a=0x7a60b8, msg=0x84fa00) at action.c:120
#18 run_top_route (a=0x7a60b8, msg=0x84fa00) at action.c:181
#19 0x000000000045a175 in receive_msg (
buf=0x76b040 "BYE sip:...

Here is a snippet from the config:

#if( (VAR_TRUSTED_TAG !~ "is_a_carrier") && ($DLG_status > "3") )
#{
# if( !validate_dialog() )
# {
# xlog( "fixing route set for $ci in $rm block \n" );
# fix_route_dialog();
# }
#}

Here is a little more detail from the backtrace:

#1 dlg_validate_dialog (req=0x84fa00, dlg=0x2b52e8262030) at dlg_handlers.c:1257
1257 if ( str2int( &((get_cseq(req))->number), &n)!=0 ||

$3 = {type = HDR_CSEQ_T, name = {
s = 0x76b224 "CSeq: 3 BYE\r\n..., len = 4}, body = {
s = 0x76b22a "3 BYE\r\n..., len = 5}, len = 13, parsed = 0x850b38, next = 0x856cd0, sibling = 0x0}

Richard

Discussion

  • Anca Vamanu
    Anca Vamanu
    2011-04-05

    • assigned_to: nobody --> vladut-paiu
     
  • Hello Richard,

    The CSeq header field in the SIP message seems OK, the parsed field is filled ( 0x850b38 ) but still, OpenSIPS crashes when it tries to access the number from the parsed structure, which is odd.

    It seems there is a memory corruption, If you still have the core dump, you could do
    p ((struct cseq_body*)(p_msg)->cseq->parsed)->number
    and check if the pointer in the number structure is invalid.

    If this is the case, what you can do is to compile with memory debugging support - in
    Makefile.defs search -DDBG_QM_MALLOC line, uncomment it, move it above
    -DF_MALLOC line and comment this line with -DF_MALLOC. Then recompile and
    reinstall all. Also set mem_dump=1 in your config.
    And when you have a crash again, look in the log for the lines above 'core was
    generated' for the process that crashed and send them.

    Secondly, validate_dialog() does not do any modifications to the SIP message so, on it's own, it can't trigger the removal of a Route header. Are you also calling fix_route_dialog() inside your script ?

     
    • status: open --> closed-invalid
     
  • The cseq part in dialog module was reworked, so this report is not valid anymore - please use the latest SVN version. If by chance, the problem persists, please open a new report.

    Thanks and regards,
    Bogdan