21 May
2021
21 May
'21
3:56 p.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
21 May
21 May
4:41 p.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
4:46 p.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
24 May
24 May
10: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
12:37 p.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
27 May
27 May
10: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
31 May
31 May
12:43 p.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
5:17 p.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
2 Jun
2 Jun
4:09 p.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
5:04 p.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
5:04 p.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
1085
days inactive
1097
days old
10 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
descartin
-
Henning Westerholt