Kamailio had an abort happend and does a coredump. Sorry I doesn't have debug symbols on this machine.
Kamailio:
```
root@voip-integration-cust1:~ # kamailio -V
version: kamailio 4.4.0 (amd64/freebsd) d4f23c
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_PTHREAD_MUTEX, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, select, kqueue.
id: d4f23c
compiled on 16:52:24 Apr 30 2016 with clang 3.4
```
Log:
```
May 4 17:55:27 <local0.crit> voip-integration-cust1 kamailio[1177]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 12
May 4 17:55:27 <kern.info> voip-integration-cust1 kernel: pid 1147 (kamailio), uid 986: exited on signal 6 (core dumped)
May 4 17:55:27 <kern.info> voip-integration-cust1 kernel: pid 1146 (kamailio), uid 986: exited on signal 6 (core dumped)
May 4 17:55:27 <local0.alert> voip-integration-cust1 kamailio[1145]: ALERT: <core> [main.c:739]: handle_sigs(): child process 1147 exited by a signal 6
May 4 17:55:27 <local0.alert> voip-integration-cust1 kamailio[1145]: ALERT: <core> [main.c:742]: handle_sigs(): core was generated
May 4 17:55:27 <kern.info> voip-integration-cust1 kernel: pid 1148 (kamailio), uid 986: exited on signal 6 (core dumped)
```
Backtrace:
```
#0 0x000000080110235a in thr_kill () from /lib/libc.so.7
#1 0x0000000801102346 in raise () from /lib/libc.so.7
#2 0x00000008011022c9 in abort () from /lib/libc.so.7
#3 0x0000000800e3195a in pthread_attr_getaffinity_np () from /lib/libthr.so.3
#4 0x0000000800e2d046 in pthread_mutex_destroy () from /lib/libthr.so.3
#5 0x0000000805b436b5 in rpc_reply () from /usr/local/lib/kamailio/modules/tm.so
#6 0x0000000805b23f18 in tm_reply_mutex_lock () from /usr/local/lib/kamailio/modules/tm.so
#7 0x0000000805b34ba2 in reply_received () from /usr/local/lib/kamailio/modules/tm.so
#8 0x000000000057146b in forward_reply ()
#9 0x0000000000570cca in forward_reply ()
#10 0x00000000004682a4 in receive_msg ()
#11 0x0000000000645023 in udp_rcv_loop ()
#12 0x0000000000543cad in main_loop ()
#13 0x00000000005519a5 in main ()
```
---
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/604
I would like the URI transformations to be more generic so one can pick up the URI scheme, like HTTP: or TEL:
Just an idea
---
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/592
ENV: Debian 8
So on most Linux systems the /var/run folder is a tmpfs and after which clears after each reboot
As I try to start up kamailio after a reboot through kamctl I get the following error.
"ERROR: PID file /var/run/kamailio.pid does not exist -- Kamailio start failed"
Because kamailio does not have the permission to write to the /var/run folder as the kamailio user.
Would it be possible to add in the "kamctl" code a section where the SPECIFIED PID LOCATION (/var/run/kamailio) is checked and if it does not exist create it as the root user and chown it to the SPECIFIED USER (kamailio)? The way I have patched it for now is to create a init script that creates a /var/run/kamailio folder and chmods it to kamailio:kamailio
Thanks everyone!
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/231
Hi,
Kamailio crashes when we handle a 302 redirect and the reply is a 404.
> # kamailio -v
> version: kamailio 4.4.4 (x86_64/linux)
> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown
> compiled with gcc 4.9.2
root@14cn5:/home/joel/files#
This works:
> softphone1 > kamailio1 > server1 > 302 > kamailio1 > server2 > 200 OK
This crashes:
> softphone1 > kamailio1 > server1 > 302 > kamailio1 > server2 > 404 Not Found
I'm attaching debug logs, sip traces and the bt full from backtrace.
IPs:
> A.B.C.D = Kamailio IP
> E.F.G.H = Softphone IP
> I.J.K.L1 = dispatcher node1
> I.J.K.L2 = dispatcher node2
In the config we send INVITE requests to a dispatcher group (very simple config).
Then, in failure_route we have:
```
if (t_check_status("302")) {
xlog("L_NOTICE", "Redirecting to TestName: $T_rpl($ct) - M=$rm R=$ru ID=$ci\n");
get_redirects("*");
route(RELAY);
}
```
And call get redirected to the address of the contact in the 302.
If the new INVITE to that address gets a 200, all works, if that request gets a 404, Kamailio crashes.
Please let me know if you need more info, this is 100% reproducible on our platform.
Thank you!
Joel.
[backtrace.txt](https://github.com/kamailio/kamailio/files/623307/backtrace.…
[debug.txt](https://github.com/kamailio/kamailio/files/623308/debug.txt)
[sip.txt](https://github.com/kamailio/kamailio/files/623309/sip.txt)
--
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/875
We have a crash in kamailio 4.4.4 after t_next_contacts() has been called from failure route, if at this very moment when kamailio is preparing new INVITE the caller sends a cancel.
#0 build_res_buf_from_sip_req (code=3186024432, code@entry=487, text=0x25, new_tag=0x7f8dcf5fb2b0 <tm_tag>, msg=0x7f8dbde6cf78,
returned_len=0xb7, bmark=0x4) at msg_translator.c:2395
#1 0x00007f8dcf35f7b2 in _reply (trans=0x7f8dbde70960, p_msg=0x7f8dbde6cf78, code=487, text=<optimized out>, lock=1) at t_reply.c:712
#2 0x00007f8dcf3b5e8b in e2e_cancel (cancel_msg=0x7f8dbde6dff0, cancel_msg@entry=0x7f8dd26bb750, t_cancel=0x25,
t_invite=0x7f8dbde70960) at t_fwd.c:1278
So the scheme is the following: proxy > INVITE < 486 > INVITE* < CANCEL
Victor has investigated this and found that the issue seems to be related to the reply lumps added by append_to_reply when processing initial invite. In order to reproduce this you need children>=2.
When first target replies 486 the proxy calls t_next_contacts() and starts preparing invite to the next target and at this time another process receives cancel and destroys the transaction, the process handling that invite message(*) gets crashed.
While we are investigating the possibility to move the append_to_reply calls to the branch route, would it be possible to avoid crash by some kind of lock mechanism? The thing is that it's not always possible to move append_to_reply to the branch route, e.g. our proxy is deployed behind stateless lb with multiple interfaces and proxy needs to tell lb which interface to use already in the 100 Trying reply it sends to lb as a first thing when receiving a message.
--
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/872
Hello,
I recall reading somewhere that all private variables (i.e. $var(foo)-style
pvs) are reset/destroyed between request_route executions, but I have a
suspicion this is not happening - either in some limited cases or perhaps
in all cases.
I suppose the most telling symptom is that I see no references to either
destroy_vars() or reset_vars() functions that are defined in
$kamailio/modules/pv/pv_svar.{c,h}.
Is this behavior intentional? If so, I'll see what I can do about
implementing a mechanism that manually resets (or destroys?) variables with
a "$var(all) = $null;"-type of statement (similar to "$uac_req(all) =
$null;"), or making a modparam setting that automatically does this.
Thoughts welcome. Thanks!
Armen