Hi, all
This is related to the previous tls.reload not safe email chain. Now we have a detailed gdb output that shows the stack trace of the core dump. Please take a look. This looks like a bug. Please let me know if you have any insights on how to fix this. Thanks,
Ding
You should build Kamailio without optimizations. "<value optimized out>" does not bring much information.
regards Klaus
On 23.10.2013 21:48, Ding Ma wrote:
Hi, all
This is related to the previous tls.reload not safe email chain. Now we have a detailed gdb output that shows the stack trace of the core dump. Please take a look. This looks like a bug. Please let me know if you have any insights on how to fix this. Thanks,
Ding
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Is this the right way to build without optimization? make cfg-defs mode=debug We'll try this later.
By the way, after looking at the core dump and the TLS code, found a memory leak and an error in tls_free_cfg() and collect_gabarge(). We have patched the code, also implemented the locks and changed the ref_count to volatile based on the recommendations from Jan Janak's email chain. These fixes seem to work. The core dump hasn't happened even if we reload tls every 5 mins when there are some active TLS connections. Can we make these fixes into kamailio code base? What's the process to submit changes for review?
Thanks,
Ding
On 10/24/2013 03:18 AM, Klaus Darilion wrote:
You should build Kamailio without optimizations. "<value optimized out>" does not bring much information.
regards Klaus
On 23.10.2013 21:48, Ding Ma wrote:
Hi, all
This is related to the previous tls.reload not safe email chain. Now we have a detailed gdb output that shows the stack trace of the core dump. Please take a look. This looks like a bug. Please let me know if you have any insights on how to fix this. Thanks,
Ding
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Great! Please submit the patch on the bug tracker: https://sip-router.org/tracker/
It will then be reviewed before applying.
thanks Klaus
On 25.10.2013 01:54, Ding Ma wrote:
Is this the right way to build without optimization? make cfg-defs mode=debug We'll try this later.
By the way, after looking at the core dump and the TLS code, found a memory leak and an error in tls_free_cfg() and collect_gabarge(). We have patched the code, also implemented the locks and changed the ref_count to volatile based on the recommendations from Jan Janak's email chain. These fixes seem to work. The core dump hasn't happened even if we reload tls every 5 mins when there are some active TLS connections. Can we make these fixes into kamailio code base? What's the process to submit changes for review?
Thanks,
Ding
On 10/24/2013 03:18 AM, Klaus Darilion wrote:
You should build Kamailio without optimizations. "<value optimized out>" does not bring much information.
regards Klaus
On 23.10.2013 21:48, Ding Ma wrote:
Hi, all
This is related to the previous tls.reload not safe email chain. Now we have a detailed gdb output that shows the stack trace of the core dump. Please take a look. This looks like a bug. Please let me know if you have any insights on how to fix this. Thanks,
Ding
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Ding Ma!
It would be great if you can provide the patch at the tracker. https://sip-router.org/tracker/
regards Klaus
On 25.10.2013 01:54, Ding Ma wrote:
Is this the right way to build without optimization? make cfg-defs mode=debug We'll try this later.
By the way, after looking at the core dump and the TLS code, found a memory leak and an error in tls_free_cfg() and collect_gabarge(). We have patched the code, also implemented the locks and changed the ref_count to volatile based on the recommendations from Jan Janak's email chain. These fixes seem to work. The core dump hasn't happened even if we reload tls every 5 mins when there are some active TLS connections. Can we make these fixes into kamailio code base? What's the process to submit changes for review?
Thanks,
Ding
On 10/24/2013 03:18 AM, Klaus Darilion wrote:
You should build Kamailio without optimizations. "<value optimized out>" does not bring much information.
regards Klaus
On 23.10.2013 21:48, Ding Ma wrote:
Hi, all
This is related to the previous tls.reload not safe email chain. Now we have a detailed gdb output that shows the stack trace of the core dump. Please take a look. This looks like a bug. Please let me know if you have any insights on how to fix this. Thanks,
Ding
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Yes, give me a couple of days to get a clean patch based on 4.0.4. The original patch was done on 4.0.3.
Thanks,
On 11/15/2013 3:59 AM, Klaus Darilion wrote:
Hi Ding Ma!
It would be great if you can provide the patch at the tracker. https://sip-router.org/tracker/
regards Klaus
On 25.10.2013 01:54, Ding Ma wrote:
Is this the right way to build without optimization? make cfg-defs mode=debug We'll try this later.
By the way, after looking at the core dump and the TLS code, found a memory leak and an error in tls_free_cfg() and collect_gabarge(). We have patched the code, also implemented the locks and changed the ref_count to volatile based on the recommendations from Jan Janak's email chain. These fixes seem to work. The core dump hasn't happened even if we reload tls every 5 mins when there are some active TLS connections. Can we make these fixes into kamailio code base? What's the process to submit changes for review?
Thanks,
Ding
On 10/24/2013 03:18 AM, Klaus Darilion wrote:
You should build Kamailio without optimizations. "<value optimized out>" does not bring much information.
regards Klaus
On 23.10.2013 21:48, Ding Ma wrote:
Hi, all
This is related to the previous tls.reload not safe email chain. Now we have a detailed gdb output that shows the stack trace of the core dump. Please take a look. This looks like a bug. Please let me know if you have any insights on how to fix this. Thanks,
Ding
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Ding!
The TLS module is mostly BSD licensed. Thus, it would be great if you can BSD license your patch too. This eases integration of Kamailio-TLS in Debian.
Thanks Klaus
On 16.11.2013 06:26, Ding Ma wrote:
Yes, give me a couple of days to get a clean patch based on 4.0.4. The original patch was done on 4.0.3.
Thanks,
On 11/15/2013 3:59 AM, Klaus Darilion wrote:
Hi Ding Ma!
It would be great if you can provide the patch at the tracker. https://sip-router.org/tracker/
regards Klaus
On 25.10.2013 01:54, Ding Ma wrote:
Is this the right way to build without optimization? make cfg-defs mode=debug We'll try this later.
By the way, after looking at the core dump and the TLS code, found a memory leak and an error in tls_free_cfg() and collect_gabarge(). We have patched the code, also implemented the locks and changed the ref_count to volatile based on the recommendations from Jan Janak's email chain. These fixes seem to work. The core dump hasn't happened even if we reload tls every 5 mins when there are some active TLS connections. Can we make these fixes into kamailio code base? What's the process to submit changes for review?
Thanks,
Ding
On 10/24/2013 03:18 AM, Klaus Darilion wrote:
You should build Kamailio without optimizations. "<value optimized out>" does not bring much information.
regards Klaus
On 23.10.2013 21:48, Ding Ma wrote:
Hi, all
This is related to the previous tls.reload not safe email chain. Now we have a detailed gdb output that shows the stack trace of the core dump. Please take a look. This looks like a bug. Please let me know if you have any insights on how to fix this. Thanks,
Ding
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Ding Ma -
Klaus Darilion