[sr-dev] kamailio 4.1.6 (x86_64/linux) 010d57 Crash

Kristian Kielhofner kris at kriskinc.com
Fri Oct 31 23:19:56 CET 2014


Hi Daniel,

  Well as they say "that was easy".

  We'll install from git 4.1 branch and respond with how it goes.

  As always, thanks!

On Fri, Oct 31, 2014 at 5:53 PM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Hello,
>
> it looks like a bug fixed after release of 4.1.6 (the bug was also in
> older releases, but is happening in a rather corner case -- iirc, a call
> not getting the ACK for 2min or so). Can you install from git branch 4.1?
>
> I was considering releasing 4.1.7 for a while now, most probably it will
> happen next week.
>
> Cheers,
> Daniel
>
> On 31/10/14 20:23, Kristian Kielhofner wrote:
>> Indeed, thanks!
>>
>> Fortunately (and as a testament to the stability of Kamailio), I don't
>> have much experience debugging Kamailio crashes. The real bt:
>>
>> #0  0x00002acddbc507f2 in update_dlg_timer (tl=0x58, timeout=10) at
>> dlg_timer.c:203
>> #1  0x00002acddbc3dc6c in dlg_clean_run (ti=23926498) at dlg_hash.c:253
>> #2  0x00002acddbc28c41 in dlg_clean_timer_exec (ticks=23926498,
>> param=0x0) at dialog.c:1246
>> #3  0x0000000000536c6f in fork_sync_timer (child_id=-1,
>> desc=0x2acddbc5b789 "Dialog Clean Timer", make_sock=1,
>> f=0x2acddbc28c2a <dlg_clean_timer_exec>, param=0x0, interval=90) at
>> timer_proc.c:232
>> #4  0x00002acddbc25778 in child_init (rank=0) at dialog.c:733
>> #5  0x00000000004f80e5 in init_mod_child (m=0x2acdd7731f60, rank=0) at
>> sr_module.c:924
>> #6  0x00000000004f7f8e in init_mod_child (m=0x2acdd7732c20, rank=0) at
>> sr_module.c:921
>> #7  0x00000000004f7f8e in init_mod_child (m=0x2acdd7733068, rank=0) at
>> sr_module.c:921
>> #8  0x00000000004f7f8e in init_mod_child (m=0x2acdd77334b0, rank=0) at
>> sr_module.c:921
>> #9  0x00000000004f7f8e in init_mod_child (m=0x2acdd7733e00, rank=0) at
>> sr_module.c:921
>> #10 0x00000000004f7f8e in init_mod_child (m=0x2acdd7739d40, rank=0) at
>> sr_module.c:921
>> #11 0x00000000004f7f8e in init_mod_child (m=0x2acdd773a150, rank=0) at
>> sr_module.c:921
>> #12 0x00000000004f7f8e in init_mod_child (m=0x2acdd773b9c0, rank=0) at
>> sr_module.c:921
>> #13 0x00000000004f7f8e in init_mod_child (m=0x2acdd773be10, rank=0) at
>> sr_module.c:921
>> #14 0x00000000004f7f8e in init_mod_child (m=0x2acdd773c588, rank=0) at
>> sr_module.c:921
>> #15 0x00000000004f7f8e in init_mod_child (m=0x2acdd773cdd0, rank=0) at
>> sr_module.c:921
>> #16 0x00000000004f7f8e in init_mod_child (m=0x2acdd773f610, rank=0) at
>> sr_module.c:921
>> #17 0x00000000004f7f8e in init_mod_child (m=0x2acdd773fb70, rank=0) at
>> sr_module.c:921
>> #18 0x00000000004f8269 in init_child (rank=0) at sr_module.c:948
>> #19 0x000000000046ddb7 in main_loop () at main.c:1696
>> #20 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
>>
>> On Fri, Oct 31, 2014 at 2:23 PM, Jason Penton <jason.penton at gmail.com> wrote:
>>> There should be another core file for the process that caused the crash.
>>> This bt is of kamailio crashing on shutdown..... After the real crash
>>>
>>> --
>>> Sent using my phone and may be brief, to the point or contain typos
>>> --
>>>
>>> On 31 Oct 2014 19:57, "Kristian Kielhofner" <kris at kriskinc.com> wrote:
>>>> Hello,
>>>>
>>>>   We recently upgraded several of our Kamailio instances to 4.1.6 and
>>>> have experienced this crash on several of them (full backtrace
>>>> attached).
>>>>
>>>> #0  0x00000031e9e30265 in raise () from /lib64/libc.so.6
>>>> #1  0x00000031e9e31d10 in abort () from /lib64/libc.so.6
>>>> #2  0x00000000004687de in sig_alarm_abort (signo=14) at main.c:687
>>>> #3  <signal handler called>
>>>> #4  0x00000031e9ed07c9 in syscall () from /lib64/libc.so.6
>>>> #5  0x00002acddbc4ff24 in futex_get (lock=0x2acdddcad6d8) at
>>>> ../../mem/../futexlock.h:110
>>>> #6  0x00002acddbc50555 in remove_dialog_timer (tl=0x2acde2bcb708) at
>>>> dlg_timer.c:168
>>>> #7  0x00002acddbc3edb8 in destroy_dlg (dlg=0x2acde2bcb6b0) at
>>>> dlg_hash.c:357
>>>> #8  0x00002acddbc3f70a in destroy_dlg_table () at dlg_hash.c:438
>>>> #9  0x00002acddbc25c21 in mod_destroy () at dialog.c:776
>>>> #10 0x00000000004f7ebb in destroy_modules () at sr_module.c:817
>>>> #11 0x00000000004672c4 in cleanup (show_status=1) at main.c:562
>>>> #12 0x0000000000468952 in shutdown_children (sig=15, show_status=1) at
>>>> main.c:704
>>>> #13 0x000000000046a012 in handle_sigs () at main.c:795
>>>> #14 0x000000000046e33c in main_loop () at main.c:1748
>>>> #15 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at
>>>> main.c:2547
>>>>
>>>>   Any thoughts? Thanks!
>>>>
>>>> --
>>>> Kristian Kielhofner
>>>>
>>>> _______________________________________________
>>>> sr-dev mailing list
>>>> sr-dev at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>
>>
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev



-- 
Kristian Kielhofner



More information about the sr-dev mailing list