<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
It was discovered that the function t_newtran() is causing a conflict with the transaction flags. When calling it before setting transaction flags, the flags are apparently lost, so for instance when using the ACC module, if the ACC flags are set after the t_newtran, these flags seems to get lost and no ACC entries are saved....
Some discussion around the t_newtran usage was already held in the past and it seems the function is not needed anymore to help detecting retransmissions, given the t_precheck_trans() can do this job without having to have an early creation of the transaction.
Not sure if the t_newtran is necessary in any other scenario, but if it is not I think it should be deprecated.
### Reproduction
Create simple script which uses ACC and the setflag to save ACC entries in DB. Verify ACC records are being saved properly.
Before calling the setflag(), add a call to t_newtran(). Make calls and check ACC records are not saved anymore.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
# kamailio -v
version: kamailio 5.2.2 (x86_64/linux) 67f967
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_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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 67f967
compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
# cat /etc/centos-release
CentOS Linux release 7.7.1908 (Core)
# uname -a
Linux dev1-sbc-01 3.10.0-1062.1.1.el7.x86_64 #1 SMP Fri Sep 13 22:55:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
```
--
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/2155
Hello,
Kamailio is crashing when I'm trying to set the parameter;
`modparam("tm|usrloc", "xavp_contact", "ulattrs")
`
The crash is happening when I'm register 2 devices with the same extension.
This is the core dump:
#### Reproduction
Set the following parameter:
`modparam("tm|usrloc", "xavp_contact", "ulattrs")
`
and register the same extension from 2 different devices. Then send an message to them (NOTIFY/OPTION/INVITE etc)
#### Debugging Data
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/kamailio/kamailio.pid -f /usr/local/etc/ka'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000000057cca2 in xavp_get_internal (name=0x8, list=0x0, idx=0,
prv=0x0) at core/xavp.c:288
288 core/xavp.c: No such file or directory.
(gdb) bt
#0 0x000000000057cca2 in xavp_get_internal (name=0x8, list=0x0, idx=0,
prv=0x0) at core/xavp.c:288
#1 0x0000000000581869 in xavp_insert (xavp=0x0, idx=0, list=0x0) at
core/xavp.c:752
#2 0x00007f05be0ee3a1 in ki_t_next_contacts (msg=0x7f05cb76c218) at
t_serial.c:552
#3 0x00007f05be0f09e8 in t_next_contacts (msg=0x7f05cb76c218, key=0x0,
value=0x0) at t_serial.c:756
#4 0x0000000000434d41 in do_action (h=0x7ffe93c9cad0, a=0x7f05cb642250,
msg=0x7f05cb76c218) at core/action.c:1067
#5 0x00000000004418e8 in run_actions (h=0x7ffe93c9cad0, a=0x7f05cb642250,
msg=0x7f05cb76c218) at core/action.c:1572
#6 0x0000000000441fa9 in run_actions_safe (h=0x7ffe93c9de90,
a=0x7f05cb642250, msg=0x7f05cb76c218) at core/action.c:1636
#7 0x000000000065734e in rval_get_int (h=0x7ffe93c9de90,
msg=0x7f05cb76c218, i=0x7ffe93c9cf78, rv=0x7f05cb642570, cache=0x0) at
core/rvalue.c:912
#8 0x000000000065b8fe in rval_expr_eval_int (h=0x7ffe93c9de90,
msg=0x7f05cb76c218, res=0x7ffe93c9cf78, rve=0x7f05cb642568) at
core/rvalue.c:1910
#9 0x000000000065bd51 in rval_expr_eval_int (h=0x7ffe93c9de90,
msg=0x7f05cb76c218, res=0x7ffe93c9d42c, rve=0x7f05cb642c98) at
core/rvalue.c:1918
#10 0x0000000000434807 in do_action (h=0x7ffe93c9de90, a=0x7f05cb645028,
msg=0x7f05cb76c218) at core/action.c:1043
#11 0x00000000004418e8 in run_actions (h=0x7ffe93c9de90, a=0x7f05cb637e48,
msg=0x7f05cb76c218) at core/action.c:1572
#12 0x0000000000431767 in do_action (h=0x7ffe93c9de90, a=0x7f05cb583858,
msg=0x7f05cb76c218) at core/action.c:691
#13 0x00000000004418e8 in run_actions (h=0x7ffe93c9de90, a=0x7f05cb574750,
msg=0x7f05cb76c218) at core/action.c:1572
#14 0x0000000000442071 in run_top_route (a=0x7f05cb574750,
msg=0x7f05cb76c218, c=0x0) at core/action.c:1657
#15 0x00000000005874a9 in receive_msg (buf=0xa6ec00 <buf.6868> "OPTIONS
sip:10 at 192.168.0.231:5060 SIP/2.0\r\nVia: SIP/2.0/UDP
192.168.0.231;branch=z9hG4bKd8a9.1b3abe656532065414a2f35a8916008d.1\r\nVia:
SIP/2.0/UDP 192.168.0.131:5060;received=192.168.0.131;branch=z9hG"...,
len=694, rcv_info=0x7ffe93c9e4d0) at core/receive.c:341
#16 0x000000000047bf81 in udp_rcv_loop () at core/udp_server.c:541
#17 0x0000000000424f9d in main_loop () at main.c:1669
#18 0x000000000042c688 in main (argc=13, argv=0x7ffe93c9ea18) at main.c:2710
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.2.5 (x86_64/linux) 18444d
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
Linux 3.10.0-1062.4.3.el7.x86_64 #1 SMP Wed Nov 13 23:58:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux CentOS 7```
--
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/2153
Module: kamailio
Branch: master
Commit: 063e6a025b8ca0163af2147f057d29447c6f9760
URL: https://github.com/kamailio/kamailio/commit/063e6a025b8ca0163af2147f057d294…
Author: Henning Westerholt <hw(a)skalatan.de>
Committer: Henning Westerholt <hw(a)skalatan.de>
Date: 2019-11-23T22:49:28+01:00
core: increase SHM memory pool to 128 MB
- increase SHM memory pool to 128 MB
- even an embedded system like Raspberry Pi has 1 GB RAM nowadays
- make it less likely that new users run into issues because of lack of memory
---
Modified: src/core/config.h
---
Diff: https://github.com/kamailio/kamailio/commit/063e6a025b8ca0163af2147f057d294…
Patch: https://github.com/kamailio/kamailio/commit/063e6a025b8ca0163af2147f057d294…
---
diff --git a/src/core/config.h b/src/core/config.h
index 0eda20302b..96196a0224 100644
--- a/src/core/config.h
+++ b/src/core/config.h
@@ -142,7 +142,7 @@
#endif
#define PKG_MEM_POOL_SIZE PKG_MEM_SIZE*1024*1024 /*!< used only if PKG_MALLOC is defined*/
-#define SHM_MEM_SIZE 64 /*!< used if SH_MEM is defined*/
+#define SHM_MEM_SIZE 128 /*!< used if SH_MEM is defined*/
#define SHM_MEM_POOL_SIZE SHM_MEM_SIZE*1024*1024
/* dimensioning buckets in q_malloc */