[kamailio/kamailio] core kamailio 5.4 (#2740)

List overview All Threads
Download

newer

older

git:master:260a825a: core:...

git:master:f3332c7d: pv: suport...

descartin

21 May 2021 21 May '21

9:56 a.m.

Dear all

we have seen a core in a running production kamailio instance today, i attach you the bt in dropbox

version: kamailio 5.4.4 (x86_64/linux) 0ddb01-dirty centos7 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

https://www.dropbox.com/s/3dg72cbuz7nvx5b/core_kamailio_21mayo?dl=0 https://www.dropbox.com/s/iyko32fwfxj8aam/core_kamailio_21mayo_2?dl=0

seems there might be a relation async module when delaying a request after communicating with the rtpengine ?¿ could you please take a look?

thanks a lot and regards david

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740

Attachments:

attachment.html (text/html — 2.2 KB)

Show replies by date

Henning Westerholt

21 May 21 May

10:41 a.m.

Program terminated with signal 11, Segmentation fault. #0 0x00007f4ee113ac1d in async_ms_sleep (msg=0x7f4ee5cf11b0, milliseconds=250, act=0x7f4ee5e37ca8, cbname=0x0) at async_sleep.c:381 381 if(_async_ms_list->len >= MAX_MS_SLEEP_QUEUE) {

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#issuecomment-846000246

Henning Westerholt

10:46 a.m.

This is from the second backtrace, the first one is looking more like a crash during the kamailio shutdown. Could it be possible that you have a loop in your cfg? Just wondered from the large number of run_action, do_action calls in the trace. Kamailio should not crash from it, sure.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#issuecomment-846003708

descartin

24 May 24 May

4:10 a.m.

hello Henning

mmm maybe could be but i wouldn't have expected that. Seems the call is a call in where we receive a BYE from callee before que first ACK in sent from the caller (dialog in state 3). So i was using async_ms_sleep to delay it 250ms and try to avoid 200ok (of the first invite) retransmissions. In some other configurations we also use that async delay. The difference here is we used async_route (in secs) before, and now used async_ms_sleep. Anycase the actions done after are the same.

Could it be any issue with the usage of the delay of ms?

thanks a lot and best regards david

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#issuecomment-846862125

descartin

6:37 a.m.

Hello Henning

i noticed that i forgot to set ms_timer param. MAybe being with the 0 default value, causes a loop when using async_ms_sleep?

best regards david

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#issuecomment-846951680

Daniel-Constantin Mierla

27 May 27 May

4:07 a.m.

@descartin: can you get from core file with gdb the output for:

``` frame 0 info locals p _async_ms_list p *_async_ms_list ```

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#issuecomment-849429479

descartin

31 May 31 May

6:43 a.m.

hello Daniel sorry for the delay answering

``` (gdb) frame 0 #0 0x00007f4ee113ac1d in async_ms_sleep (msg=0x7f4ee5cf11b0, milliseconds=250, act=0x7f4ee5e37ca8, cbname=0x0) at async_sleep.c:381 381 if(_async_ms_list->len >= MAX_MS_SLEEP_QUEUE) { (gdb) info locals ai = 0x7fff943fcc30 dsize = 0 t = 0x0 tindex = 0 tlabel = 15 atp = 0x0 at = 0x7e __FUNCTION__ = "async_ms_sleep" now = {tv_sec = 139976839739840, tv_usec = 112} upause = {tv_sec = 140735680595712, tv_usec = 5221289} (gdb) p _async_ms_list $1 = (struct async_ms_list *) 0x0 (gdb) p *_async_ms_list Cannot access memory at address 0x0 ```

best regards david escartin

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#issuecomment-851400149

Daniel-Constantin Mierla

11:17 a.m.

Have you set:

* https://www.kamailio.org/docs/modules/stable/modules/async.html#idm56

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#issuecomment-851554692

descartin

2 Jun 2 Jun

10:09 a.m.

hello Daniel

yes i set this parameter after we had the crash

regards david

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#issuecomment-853060510

Daniel-Constantin Mierla

11:04 a.m.

If it crashed after you set it, then reopen. Otherwise, there was a safety check pushed to repo to avoid crashes when it is not set.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#issuecomment-853105777

Daniel-Constantin Mierla

11:04 a.m.

Closed #2740.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2740#event-4832347662

1379

Age (days ago)

1391

Last active (days ago)

sr-dev@lists.kamailio.org

10 comments

3 participants

tags (0)

participants (3)

Daniel-Constantin Mierla
descartin
Henning Westerholt