No, but I do have an alias defined.

alias="mydomain.com:5080"

Thanks

Nathaniel

On 4/26/2012 3:41 AM, Daniel-Constantin Mierla wrote:

Hello,

do you set the realm_prefix parameter of registrar module?

http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082

If yes, can you paste it here?

Cheers, Daniel

On 4/25/12 9:42 PM, Akan wrote:

...

I have 2 servers running Solaris and Kamailio 3.2.3 where on one Kamailio is terminating when it tries to save the location for a register request and the other is producing a core dump when processing an Option request. I have one server handling Register request while the other sip server forwards the register requests and handles the other requests. I have included the backtraces from the core dumps and the output from the log for the registrar server as well as the command that is causing kamailio to terminate:

    if (!save("location"))
            sl_reply_error();

4(3364) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=714 a=17 n=if 4(3364) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=711 a=26 n=save 14(3374) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 15 14(3374) DEBUG: <core> [tcp_main.c:3555]: DBG: handle_ser_child: dead child 4, pid 3364 (shutting down?) 14(3374) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (1003743d8, 15, 0, 0x0) fd_no=18 called 0(3360) ALERT: <core> [main.c:751]: child process 3364 exited by a signal 10 0(3360) ALERT: <core> [main.c:754]: core was not generated 0(3360) INFO: <core> [main.c:766]: INFO: terminating due to SIGCHLD 6(3366) INFO: <core> [main.c:817]: INFO: signal 15 received 1(3361) INFO: <core> [main.c:817]: INFO: signal 15 received 2(3362) INFO: <core> [main.c:817]: INFO: signal 15 received 3(3363) INFO: <core> [main.c:817]: INFO: signal 15 received 5(3365) INFO: <core> [main.c:817]: INFO: signal 15 received 7(3367) INFO: <core> [main.c:817]: INFO: signal 15 received 8(3368) INFO: <core> [main.c:817]: INFO: signal 15 received 9(3369) INFO: <core> [main.c:817]: INFO: signal 15 received 10(3370) INFO: <core> [main.c:817]: INFO: signal 15 received 11(3371) INFO: <core> [main.c:817]: INFO: signal 15 received 12(3372) INFO: <core> [main.c:817]: INFO: signal 15 received 13(3373) INFO: <core> [main.c:817]: INFO: signal 15 received 14(3374) INFO: <core> [main.c:817]: INFO: signal 15 received 0(3360) DEBUG: presence_xml [presence_xml.c:347]: start 0(3360) ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete unix socket /tmp/kamailio_ctl: Permission denied (13) 0(3360) DEBUG: <core> [db_pool.c:102]: removing connection from the pool 0(3360) DEBUG: db_postgres [km_pg_con.c:122]: PQfinish(100842470) 0(3360) DEBUG: db_postgres [km_pg_con.c:126]: pkg_free(1004c1f30) 0(3360) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start 0(3360) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash table 0(3360) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing semaphores 0(3360) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb lists 0(3360) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done

Thanks

Nathaniel

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4959 - Release Date: 04/25/12

Hello,

the issue was a sig bus this time, which more enforced in sparc/solaris, not common in linux. I was looked at the structure and seems aligned ok, mis-alignment being the most often used to rise sigbus. What I could think as next reason was the empty string default value which may make solaris think is not accessible anymore at runtime via the cfg structure, so I changed the field for prefix to str and initialized to null to force allocation in any case.

Can you try with the attached patch and tell if works fine?

Cheers, Daniel

On 4/28/12 6:49 PM, Akan wrote:

I tried adding the realm_prefix and still got the same problem. I ran kamailio thru gdb to try and step thru and get more information and have included the output in the attached text file. Hope this helps.

Thanks

Nathaniel L Keeling

On 4/26/2012 2:42 PM, Akan wrote:

...

No, but I do have an alias defined.

alias="mydomain.com:5080"

Thanks

Nathaniel

On 4/26/2012 3:41 AM, Daniel-Constantin Mierla wrote:

...

Hello,

do you set the realm_prefix parameter of registrar module?

http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082

If yes, can you paste it here?

Cheers, Daniel

On 4/25/12 9:42 PM, Akan wrote:

...

I have 2 servers running Solaris and Kamailio 3.2.3 where on one Kamailio is terminating when it tries to save the location for a register request and the other is producing a core dump when processing an Option request. I have one server handling Register request while the other sip server forwards the register requests and handles the other requests. I have included the backtraces from the core dumps and the output from the log for the registrar server as well as the command that is causing kamailio to terminate:

    if (!save("location"))
            sl_reply_error();

4(3364) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=714 a=17 n=if 4(3364) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=711 a=26 n=save 14(3374) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 15 14(3374) DEBUG: <core> [tcp_main.c:3555]: DBG: handle_ser_child: dead child 4, pid 3364 (shutting down?) 14(3374) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (1003743d8, 15, 0, 0x0) fd_no=18 called 0(3360) ALERT: <core> [main.c:751]: child process 3364 exited by a signal 10 0(3360) ALERT: <core> [main.c:754]: core was not generated 0(3360) INFO: <core> [main.c:766]: INFO: terminating due to SIGCHLD 6(3366) INFO: <core> [main.c:817]: INFO: signal 15 received 1(3361) INFO: <core> [main.c:817]: INFO: signal 15 received 2(3362) INFO: <core> [main.c:817]: INFO: signal 15 received 3(3363) INFO: <core> [main.c:817]: INFO: signal 15 received 5(3365) INFO: <core> [main.c:817]: INFO: signal 15 received 7(3367) INFO: <core> [main.c:817]: INFO: signal 15 received 8(3368) INFO: <core> [main.c:817]: INFO: signal 15 received 9(3369) INFO: <core> [main.c:817]: INFO: signal 15 received 10(3370) INFO: <core> [main.c:817]: INFO: signal 15 received 11(3371) INFO: <core> [main.c:817]: INFO: signal 15 received 12(3372) INFO: <core> [main.c:817]: INFO: signal 15 received 13(3373) INFO: <core> [main.c:817]: INFO: signal 15 received 14(3374) INFO: <core> [main.c:817]: INFO: signal 15 received 0(3360) DEBUG: presence_xml [presence_xml.c:347]: start 0(3360) ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete unix socket /tmp/kamailio_ctl: Permission denied (13) 0(3360) DEBUG: <core> [db_pool.c:102]: removing connection from the pool 0(3360) DEBUG: db_postgres [km_pg_con.c:122]: PQfinish(100842470) 0(3360) DEBUG: db_postgres [km_pg_con.c:126]: pkg_free(1004c1f30) 0(3360) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start 0(3360) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash table 0(3360) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing semaphores 0(3360) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb lists 0(3360) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done

Thanks

Nathaniel

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4959 - Release Date: 04/25/12

---

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

---

No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4960 - Release Date: 04/26/12

---

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

I applied the changes, reran the test and this time I got a core dump. I have included the core dumps as attachments and listed the commands that I used to apply the patches.

# git apply --check registrar-real-prefix-str.patch # git apply registrar-real-prefix-str.patch

Thanks

Nathaniel

On 4/29/2012 4:37 AM, Daniel-Constantin Mierla wrote:

Hello,

the issue was a sig bus this time, which more enforced in sparc/solaris, not common in linux. I was looked at the structure and seems aligned ok, mis-alignment being the most often used to rise sigbus. What I could think as next reason was the empty string default value which may make solaris think is not accessible anymore at runtime via the cfg structure, so I changed the field for prefix to str and initialized to null to force allocation in any case.

Can you try with the attached patch and tell if works fine?

Cheers, Daniel

On 4/28/12 6:49 PM, Akan wrote:

...

I tried adding the realm_prefix and still got the same problem. I ran kamailio thru gdb to try and step thru and get more information and have included the output in the attached text file. Hope this helps.

Thanks

Nathaniel L Keeling

On 4/26/2012 2:42 PM, Akan wrote:

...

No, but I do have an alias defined.

alias="mydomain.com:5080"

Thanks

Nathaniel

On 4/26/2012 3:41 AM, Daniel-Constantin Mierla wrote:

...

Hello,

do you set the realm_prefix parameter of registrar module?

http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082

If yes, can you paste it here?

Cheers, Daniel

On 4/25/12 9:42 PM, Akan wrote:

...

I have 2 servers running Solaris and Kamailio 3.2.3 where on one Kamailio is terminating when it tries to save the location for a register request and the other is producing a core dump when processing an Option request. I have one server handling Register request while the other sip server forwards the register requests and handles the other requests. I have included the backtraces from the core dumps and the output from the log for the registrar server as well as the command that is causing kamailio to terminate:

    if (!save("location"))
            sl_reply_error();

4(3364) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=714 a=17 n=if 4(3364) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=711 a=26 n=save 14(3374) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 15 14(3374) DEBUG: <core> [tcp_main.c:3555]: DBG: handle_ser_child: dead child 4, pid 3364 (shutting down?) 14(3374) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (1003743d8, 15, 0, 0x0) fd_no=18 called 0(3360) ALERT: <core> [main.c:751]: child process 3364 exited by a signal 10 0(3360) ALERT: <core> [main.c:754]: core was not generated 0(3360) INFO: <core> [main.c:766]: INFO: terminating due to SIGCHLD 6(3366) INFO: <core> [main.c:817]: INFO: signal 15 received 1(3361) INFO: <core> [main.c:817]: INFO: signal 15 received 2(3362) INFO: <core> [main.c:817]: INFO: signal 15 received 3(3363) INFO: <core> [main.c:817]: INFO: signal 15 received 5(3365) INFO: <core> [main.c:817]: INFO: signal 15 received 7(3367) INFO: <core> [main.c:817]: INFO: signal 15 received 8(3368) INFO: <core> [main.c:817]: INFO: signal 15 received 9(3369) INFO: <core> [main.c:817]: INFO: signal 15 received 10(3370) INFO: <core> [main.c:817]: INFO: signal 15 received 11(3371) INFO: <core> [main.c:817]: INFO: signal 15 received 12(3372) INFO: <core> [main.c:817]: INFO: signal 15 received 13(3373) INFO: <core> [main.c:817]: INFO: signal 15 received 14(3374) INFO: <core> [main.c:817]: INFO: signal 15 received 0(3360) DEBUG: presence_xml [presence_xml.c:347]: start 0(3360) ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete unix socket /tmp/kamailio_ctl: Permission denied (13) 0(3360) DEBUG: <core> [db_pool.c:102]: removing connection from the pool 0(3360) DEBUG: db_postgres [km_pg_con.c:122]: PQfinish(100842470) 0(3360) DEBUG: db_postgres [km_pg_con.c:126]: pkg_free(1004c1f30) 0(3360) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start 0(3360) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash table 0(3360) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing semaphores 0(3360) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb lists 0(3360) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done

Thanks

Nathaniel

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4959 - Release Date: 04/25/12

---

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

---

No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4960 - Release Date: 04/26/12

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4965 - Release Date: 04/28/12

Hello,

interesting, it seems to crash at the evaluation of 'realm_prefix.len' - because it is 0, the IF condition should stop evaluation of the rest of the expression.

Can you try to change the first part of the condition at line 104 to:

if (realm_prefix.len>0 && ...

Cheers, Daniel

On 5/4/12 4:42 AM, Akan wrote:

I was able to step thru via gdb to the point where Kamailio took a segment fault. I have included a backtrace as well as the output from me stepping thru common.c to the point where it failed. Hope this will help.

Thanks

Nathaniel

On 4/29/2012 4:37 AM, Daniel-Constantin Mierla wrote:

...

Hello,

the issue was a sig bus this time, which more enforced in sparc/solaris, not common in linux. I was looked at the structure and seems aligned ok, mis-alignment being the most often used to rise sigbus. What I could think as next reason was the empty string default value which may make solaris think is not accessible anymore at runtime via the cfg structure, so I changed the field for prefix to str and initialized to null to force allocation in any case.

Can you try with the attached patch and tell if works fine?

Cheers, Daniel

On 4/28/12 6:49 PM, Akan wrote:

...

I tried adding the realm_prefix and still got the same problem. I ran kamailio thru gdb to try and step thru and get more information and have included the output in the attached text file. Hope this helps.

Thanks

Nathaniel L Keeling

On 4/26/2012 2:42 PM, Akan wrote:

...

No, but I do have an alias defined.

alias="mydomain.com:5080"

Thanks

Nathaniel

On 4/26/2012 3:41 AM, Daniel-Constantin Mierla wrote:

...

Hello,

do you set the realm_prefix parameter of registrar module?

http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082

If yes, can you paste it here?

Cheers, Daniel

On 4/25/12 9:42 PM, Akan wrote:

...

I have 2 servers running Solaris and Kamailio 3.2.3 where on one Kamailio is terminating when it tries to save the location for a register request and the other is producing a core dump when processing an Option request. I have one server handling Register request while the other sip server forwards the register requests and handles the other requests. I have included the backtraces from the core dumps and the output from the log for the registrar server as well as the command that is causing kamailio to terminate:

    if (!save("location"))
            sl_reply_error();

4(3364) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=714 a=17 n=if 4(3364) ERROR: *** cfgtrace: c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=711 a=26 n=save 14(3374) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 15 14(3374) DEBUG: <core> [tcp_main.c:3555]: DBG: handle_ser_child: dead child 4, pid 3364 (shutting down?) 14(3374) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (1003743d8, 15, 0, 0x0) fd_no=18 called 0(3360) ALERT: <core> [main.c:751]: child process 3364 exited by a signal 10 0(3360) ALERT: <core> [main.c:754]: core was not generated 0(3360) INFO: <core> [main.c:766]: INFO: terminating due to SIGCHLD 6(3366) INFO: <core> [main.c:817]: INFO: signal 15 received 1(3361) INFO: <core> [main.c:817]: INFO: signal 15 received 2(3362) INFO: <core> [main.c:817]: INFO: signal 15 received 3(3363) INFO: <core> [main.c:817]: INFO: signal 15 received 5(3365) INFO: <core> [main.c:817]: INFO: signal 15 received 7(3367) INFO: <core> [main.c:817]: INFO: signal 15 received 8(3368) INFO: <core> [main.c:817]: INFO: signal 15 received 9(3369) INFO: <core> [main.c:817]: INFO: signal 15 received 10(3370) INFO: <core> [main.c:817]: INFO: signal 15 received 11(3371) INFO: <core> [main.c:817]: INFO: signal 15 received 12(3372) INFO: <core> [main.c:817]: INFO: signal 15 received 13(3373) INFO: <core> [main.c:817]: INFO: signal 15 received 14(3374) INFO: <core> [main.c:817]: INFO: signal 15 received 0(3360) DEBUG: presence_xml [presence_xml.c:347]: start 0(3360) ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete unix socket /tmp/kamailio_ctl: Permission denied (13) 0(3360) DEBUG: <core> [db_pool.c:102]: removing connection from the pool 0(3360) DEBUG: db_postgres [km_pg_con.c:122]: PQfinish(100842470) 0(3360) DEBUG: db_postgres [km_pg_con.c:126]: pkg_free(1004c1f30) 0(3360) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start 0(3360) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash table 0(3360) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : removing semaphores 0(3360) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb lists 0(3360) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done

Thanks

Nathaniel

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4959 - Release Date: 04/25/12

---

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

---

No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4960 - Release Date: 04/26/12

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4965 - Release Date: 04/28/12

I made the change and still have the problem. I have included the output from stepping thru via gdb and the block of code where I made the change and that was executed.

98 if (reg_use_domain) { 99 if (user_len) 100 aor_buf[_a->len++] = '@'; 101 /* strip prefix (if defined) */ 102 realm_prefix.s = cfg_get(registrar, registrar_cfg, realm_pref).s; 103 realm_prefix.len = cfg_get(registrar, registrar_cfg, realm_pref).len; 104 if (realm_prefix.len>0 && realm_prefix.len<puri.host.len && 105 (memcmp(realm_prefix.s, puri.host.s, realm_prefix.len)==0) ) { 106 memcpy(aor_buf + _a->len, puri.host.s + realm_prefix.len, 107 puri.host.len - realm_prefix.len); 108 _a->len += puri.host.len - realm_prefix.len; 109 } else { 110 memcpy(aor_buf + _a->len, puri.host.s, puri.host.len); 111 _a->len += puri.host.len; 112 } 113 }

Thanks

Nathaniel

On 5/4/2012 2:55 AM, Daniel-Constantin Mierla wrote:

Hello,

interesting, it seems to crash at the evaluation of 'realm_prefix.len'

• because it is 0, the IF condition should stop evaluation of the rest

of the expression.

Can you try to change the first part of the condition at line 104 to:

if (realm_prefix.len>0 && ...

Cheers, Daniel

On 5/4/12 4:42 AM, Akan wrote:

...

I was able to step thru via gdb to the point where Kamailio took a segment fault. I have included a backtrace as well as the output from me stepping thru common.c to the point where it failed. Hope this will help.

Thanks

Nathaniel

On 4/29/2012 4:37 AM, Daniel-Constantin Mierla wrote:

...

Hello,

the issue was a sig bus this time, which more enforced in sparc/solaris, not common in linux. I was looked at the structure and seems aligned ok, mis-alignment being the most often used to rise sigbus. What I could think as next reason was the empty string default value which may make solaris think is not accessible anymore at runtime via the cfg structure, so I changed the field for prefix to str and initialized to null to force allocation in any case.

Can you try with the attached patch and tell if works fine?

Cheers, Daniel

On 4/28/12 6:49 PM, Akan wrote:

...

I tried adding the realm_prefix and still got the same problem. I ran kamailio thru gdb to try and step thru and get more information and have included the output in the attached text file. Hope this helps.

Thanks

Nathaniel L Keeling

On 4/26/2012 2:42 PM, Akan wrote:

...

No, but I do have an alias defined.

alias="mydomain.com:5080"

Thanks

Nathaniel

On 4/26/2012 3:41 AM, Daniel-Constantin Mierla wrote:

...

Hello,

do you set the realm_prefix parameter of registrar module?

http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082

If yes, can you paste it here?

Cheers, Daniel

On 4/25/12 9:42 PM, Akan wrote: > I have 2 servers running Solaris and Kamailio 3.2.3 where on one > Kamailio is terminating when it tries to save the location for a > register request and the other is producing a core dump when > processing an Option request. I have one server handling > Register request while the other sip server forwards the > register requests and handles the other requests. I have > included the backtraces from the core dumps and the output from > the log for the registrar server as well as the command that is > causing kamailio to terminate: > > if (!save("location")) > sl_reply_error(); > > 4(3364) ERROR: *** cfgtrace: > c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=714 a=17 n=if > 4(3364) ERROR: *** cfgtrace: > c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=711 a=26 n=save > 14(3374) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 15 > 14(3374) DEBUG: <core> [tcp_main.c:3555]: DBG: handle_ser_child: > dead child 4, pid 3364 (shutting down?) > 14(3374) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del > (1003743d8, 15, 0, 0x0) fd_no=18 called > 0(3360) ALERT: <core> [main.c:751]: child process 3364 exited > by a signal 10 > 0(3360) ALERT: <core> [main.c:754]: core was not generated > 0(3360) INFO: <core> [main.c:766]: INFO: terminating due to > SIGCHLD > 6(3366) INFO: <core> [main.c:817]: INFO: signal 15 received > 1(3361) INFO: <core> [main.c:817]: INFO: signal 15 received > 2(3362) INFO: <core> [main.c:817]: INFO: signal 15 received > 3(3363) INFO: <core> [main.c:817]: INFO: signal 15 received > 5(3365) INFO: <core> [main.c:817]: INFO: signal 15 received > 7(3367) INFO: <core> [main.c:817]: INFO: signal 15 received > 8(3368) INFO: <core> [main.c:817]: INFO: signal 15 received > 9(3369) INFO: <core> [main.c:817]: INFO: signal 15 received > 10(3370) INFO: <core> [main.c:817]: INFO: signal 15 received > 11(3371) INFO: <core> [main.c:817]: INFO: signal 15 received > 12(3372) INFO: <core> [main.c:817]: INFO: signal 15 received > 13(3373) INFO: <core> [main.c:817]: INFO: signal 15 received > 14(3374) INFO: <core> [main.c:817]: INFO: signal 15 received > 0(3360) DEBUG: presence_xml [presence_xml.c:347]: start > 0(3360) ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete > unix socket /tmp/kamailio_ctl: Permission denied (13) > 0(3360) DEBUG: <core> [db_pool.c:102]: removing connection from > the pool > 0(3360) DEBUG: db_postgres [km_pg_con.c:122]: PQfinish(100842470) > 0(3360) DEBUG: db_postgres [km_pg_con.c:126]: pkg_free(1004c1f30) > 0(3360) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start > 0(3360) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : > emptying hash table > 0(3360) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : > removing semaphores > 0(3360) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : > destroying tmcb lists > 0(3360) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done > > Thanks > > Nathaniel > > > _______________________________________________ > 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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4959 - Release Date: 04/25/12

---

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

---

No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4960 - Release Date: 04/26/12

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4965 - Release Date: 04/28/12

I changed the use_domain parameter for usrloc to 0 and retried. Kamailio did not crash and I was able to get registered. I have another server with the same configurations as the one having the problem. I will apply the patch there and see if the problem still occurs. Also, setting the use_domain to 0 for usrloc, does this limit me to not being able to use other domains within the SIP message?

Thanks

Nathaniel

On 5/9/2012 3:05 AM, Daniel-Constantin Mierla wrote:

Hello,

I see no reason why it crashes at line 104 when realm_prefix.len==0.

Might be a memory problem (hardware). Can you try with use_domain parameter set to 0 for usrloc module?

Cheers, Daniel

On 5/5/12 5:29 PM, Akan wrote:

...

I made the change and still have the problem. I have included the output from stepping thru via gdb and the block of code where I made the change and that was executed.

98 if (reg_use_domain) { 99 if (user_len) 100 aor_buf[_a->len++] = '@'; 101 /* strip prefix (if defined) */ 102 realm_prefix.s = cfg_get(registrar, registrar_cfg, realm_pref).s; 103 realm_prefix.len = cfg_get(registrar, registrar_cfg, realm_pref).len; 104 if (realm_prefix.len>0 && realm_prefix.len<puri.host.len && 105 (memcmp(realm_prefix.s, puri.host.s, realm_prefix.len)==0) ) { 106 memcpy(aor_buf + _a->len, puri.host.s

• realm_prefix.len, 107 puri.host.len -

realm_prefix.len); 108 _a->len += puri.host.len - realm_prefix.len; 109 } else { 110 memcpy(aor_buf + _a->len, puri.host.s, puri.host.len); 111 _a->len += puri.host.len; 112 } 113 }

Thanks

Nathaniel

On 5/4/2012 2:55 AM, Daniel-Constantin Mierla wrote:

...

Hello,

interesting, it seems to crash at the evaluation of 'realm_prefix.len' - because it is 0, the IF condition should stop evaluation of the rest of the expression.

Can you try to change the first part of the condition at line 104 to:

if (realm_prefix.len>0 && ...

Cheers, Daniel

On 5/4/12 4:42 AM, Akan wrote:

...

I was able to step thru via gdb to the point where Kamailio took a segment fault. I have included a backtrace as well as the output from me stepping thru common.c to the point where it failed. Hope this will help.

Thanks

Nathaniel

On 4/29/2012 4:37 AM, Daniel-Constantin Mierla wrote:

...

Hello,

the issue was a sig bus this time, which more enforced in sparc/solaris, not common in linux. I was looked at the structure and seems aligned ok, mis-alignment being the most often used to rise sigbus. What I could think as next reason was the empty string default value which may make solaris think is not accessible anymore at runtime via the cfg structure, so I changed the field for prefix to str and initialized to null to force allocation in any case.

Can you try with the attached patch and tell if works fine?

Cheers, Daniel

On 4/28/12 6:49 PM, Akan wrote:

...

I tried adding the realm_prefix and still got the same problem. I ran kamailio thru gdb to try and step thru and get more information and have included the output in the attached text file. Hope this helps.

Thanks

Nathaniel L Keeling

On 4/26/2012 2:42 PM, Akan wrote: > No, but I do have an alias defined. > > alias="mydomain.com:5080" > > Thanks > > Nathaniel > > On 4/26/2012 3:41 AM, Daniel-Constantin Mierla wrote: >> Hello, >> >> do you set the realm_prefix parameter of registrar module? >> >> http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082 >> >> >> If yes, can you paste it here? >> >> Cheers, >> Daniel >> >> On 4/25/12 9:42 PM, Akan wrote: >>> I have 2 servers running Solaris and Kamailio 3.2.3 where on >>> one Kamailio is terminating when it tries to save the location >>> for a register request and the other is producing a core dump >>> when processing an Option request. I have one server handling >>> Register request while the other sip server forwards the >>> register requests and handles the other requests. I have >>> included the backtraces from the core dumps and the output >>> from the log for the registrar server as well as the command >>> that is causing kamailio to terminate: >>> >>> if (!save("location")) >>> sl_reply_error(); >>> >>> 4(3364) ERROR: *** cfgtrace: >>> c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=714 a=17 n=if >>> 4(3364) ERROR: *** cfgtrace: >>> c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=711 a=26 n=save >>> 14(3374) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 15 >>> 14(3374) DEBUG: <core> [tcp_main.c:3555]: DBG: >>> handle_ser_child: dead child 4, pid 3364 (shutting down?) >>> 14(3374) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del >>> (1003743d8, 15, 0, 0x0) fd_no=18 called >>> 0(3360) ALERT: <core> [main.c:751]: child process 3364 exited >>> by a signal 10 >>> 0(3360) ALERT: <core> [main.c:754]: core was not generated >>> 0(3360) INFO: <core> [main.c:766]: INFO: terminating due to >>> SIGCHLD >>> 6(3366) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 1(3361) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 2(3362) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 3(3363) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 5(3365) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 7(3367) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 8(3368) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 9(3369) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 10(3370) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 11(3371) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 12(3372) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 13(3373) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 14(3374) INFO: <core> [main.c:817]: INFO: signal 15 received >>> 0(3360) DEBUG: presence_xml [presence_xml.c:347]: start >>> 0(3360) ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete >>> unix socket /tmp/kamailio_ctl: Permission denied (13) >>> 0(3360) DEBUG: <core> [db_pool.c:102]: removing connection >>> from the pool >>> 0(3360) DEBUG: db_postgres [km_pg_con.c:122]: >>> PQfinish(100842470) >>> 0(3360) DEBUG: db_postgres [km_pg_con.c:126]: >>> pkg_free(1004c1f30) >>> 0(3360) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start >>> 0(3360) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : >>> emptying hash table >>> 0(3360) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : >>> removing semaphores >>> 0(3360) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : >>> destroying tmcb lists >>> 0(3360) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done >>> >>> Thanks >>> >>> Nathaniel >>> >>> >>> _______________________________________________ >>> 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 >> >> -- >> Daniel-Constantin Mierla -http://www.asipto.com >> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda >> >> No virus found in this message. >> Checked by AVG - www.avg.com http://www.avg.com >> Version: 2012.0.1913 / Virus Database: 2411/4959 - Release >> Date: 04/25/12 >> > > _______________________________________________ > 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 > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2411/4960 - Release Date: > 04/26/12 > >

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virus Database: 2411/4965 - Release Date: 04/28/12

I am still getting a core dump with Kamailio v3.2. I loaded Kamailio on a new server, applied the patch and started testing. I was able to register successfully which previously I was not, but now when I try to make a call, kamailio will take a core dump. I also loaded Kamailio v3.1 just to make sure that it is not a memory issue and I was able to place a call successfully without Kamailio taking a core dump. I have included the full backtrace from the dump and it looks like it is in the same place as previously. I loaded Kamailio v3.2 on 3 different servers with the same results of producing a core dump. I have not tried the new development version yet.

Thanks

Nathaniel

On 5/23/2012 1:44 AM, Akan wrote:

I'd setup another solaris server with kamailio v3.2, applied the patch and tested the change. Kamailio did not crash nor took a core dump. So it looks like it might be a hardware problem now.

Thanks

Nathaniel

On 5/9/2012 1:52 PM, Akan wrote:

...

I changed the use_domain parameter for usrloc to 0 and retried. Kamailio did not crash and I was able to get registered. I have another server with the same configurations as the one having the problem. I will apply the patch there and see if the problem still occurs. Also, setting the use_domain to 0 for usrloc, does this limit me to not being able to use other domains within the SIP message?

Thanks

Nathaniel

On 5/9/2012 3:05 AM, Daniel-Constantin Mierla wrote:

...

Hello,

I see no reason why it crashes at line 104 when realm_prefix.len==0.

Might be a memory problem (hardware). Can you try with use_domain parameter set to 0 for usrloc module?

Cheers, Daniel

On 5/5/12 5:29 PM, Akan wrote:

...

I made the change and still have the problem. I have included the output from stepping thru via gdb and the block of code where I made the change and that was executed.

98 if (reg_use_domain) { 99 if (user_len) 100 aor_buf[_a->len++] = '@'; 101 /* strip prefix (if defined) */ 102 realm_prefix.s = cfg_get(registrar, registrar_cfg, realm_pref).s; 103 realm_prefix.len = cfg_get(registrar, registrar_cfg, realm_pref).len; 104 if (realm_prefix.len>0 && realm_prefix.len<puri.host.len && 105 (memcmp(realm_prefix.s, puri.host.s, realm_prefix.len)==0) ) { 106 memcpy(aor_buf + _a->len, puri.host.s + realm_prefix.len, 107 puri.host.len - realm_prefix.len); 108 _a->len += puri.host.len - realm_prefix.len; 109 } else { 110 memcpy(aor_buf + _a->len, puri.host.s, puri.host.len); 111 _a->len += puri.host.len; 112 } 113 }

Thanks

Nathaniel

On 5/4/2012 2:55 AM, Daniel-Constantin Mierla wrote:

...

Hello,

interesting, it seems to crash at the evaluation of 'realm_prefix.len' - because it is 0, the IF condition should stop evaluation of the rest of the expression.

Can you try to change the first part of the condition at line 104 to:

if (realm_prefix.len>0 && ...

Cheers, Daniel

On 5/4/12 4:42 AM, Akan wrote:

...

I was able to step thru via gdb to the point where Kamailio took a segment fault. I have included a backtrace as well as the output from me stepping thru common.c to the point where it failed. Hope this will help.

Thanks

Nathaniel

On 4/29/2012 4:37 AM, Daniel-Constantin Mierla wrote: > Hello, > > the issue was a sig bus this time, which more enforced in > sparc/solaris, not common in linux. I was looked at the > structure and seems aligned ok, mis-alignment being the most > often used to rise sigbus. What I could think as next reason was > the empty string default value which may make solaris think is > not accessible anymore at runtime via the cfg structure, so I > changed the field for prefix to str and initialized to null to > force allocation in any case. > > Can you try with the attached patch and tell if works fine? > > Cheers, > Daniel > > On 4/28/12 6:49 PM, Akan wrote: >> I tried adding the realm_prefix and still got the same problem. >> I ran kamailio thru gdb to try and step thru and get more >> information and have included the output in the attached text >> file. Hope this helps. >> >> Thanks >> >> Nathaniel L Keeling >> >> On 4/26/2012 2:42 PM, Akan wrote: >>> No, but I do have an alias defined. >>> >>> alias="mydomain.com:5080" >>> >>> Thanks >>> >>> Nathaniel >>> >>> On 4/26/2012 3:41 AM, Daniel-Constantin Mierla wrote: >>>> Hello, >>>> >>>> do you set the realm_prefix parameter of registrar module? >>>> >>>> http://kamailio.org/docs/modules/stable/modules_k/registrar.html#id2495082 >>>> >>>> >>>> If yes, can you paste it here? >>>> >>>> Cheers, >>>> Daniel >>>> >>>> On 4/25/12 9:42 PM, Akan wrote: >>>>> I have 2 servers running Solaris and Kamailio 3.2.3 where on >>>>> one Kamailio is terminating when it tries to save the >>>>> location for a register request and the other is producing a >>>>> core dump when processing an Option request. I have one >>>>> server handling Register request while the other sip server >>>>> forwards the register requests and handles the other >>>>> requests. I have included the backtraces from the core dumps >>>>> and the output from the log for the registrar server as well >>>>> as the command that is causing kamailio to terminate: >>>>> >>>>> if (!save("location")) >>>>> sl_reply_error(); >>>>> >>>>> 4(3364) ERROR: *** cfgtrace: >>>>> c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=714 a=17 n=if >>>>> 4(3364) ERROR: *** cfgtrace: >>>>> c=[/opt/kamailio-3.2/etc/kamailio/kamailio.cfg] l=711 a=26 >>>>> n=save >>>>> 14(3374) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 15 >>>>> 14(3374) DEBUG: <core> [tcp_main.c:3555]: DBG: >>>>> handle_ser_child: dead child 4, pid 3364 (shutting down?) >>>>> 14(3374) DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del >>>>> (1003743d8, 15, 0, 0x0) fd_no=18 called >>>>> 0(3360) ALERT: <core> [main.c:751]: child process 3364 >>>>> exited by a signal 10 >>>>> 0(3360) ALERT: <core> [main.c:754]: core was not generated >>>>> 0(3360) INFO: <core> [main.c:766]: INFO: terminating due to >>>>> SIGCHLD >>>>> 6(3366) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 1(3361) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 2(3362) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 3(3363) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 5(3365) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 7(3367) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 8(3368) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 9(3369) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 10(3370) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 11(3371) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 12(3372) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 13(3373) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 14(3374) INFO: <core> [main.c:817]: INFO: signal 15 received >>>>> 0(3360) DEBUG: presence_xml [presence_xml.c:347]: start >>>>> 0(3360) ERROR: ctl [ctl.c:379]: ERROR: ctl: could not >>>>> delete unix socket /tmp/kamailio_ctl: Permission denied (13) >>>>> 0(3360) DEBUG: <core> [db_pool.c:102]: removing connection >>>>> from the pool >>>>> 0(3360) DEBUG: db_postgres [km_pg_con.c:122]: >>>>> PQfinish(100842470) >>>>> 0(3360) DEBUG: db_postgres [km_pg_con.c:126]: >>>>> pkg_free(1004c1f30) >>>>> 0(3360) DEBUG: tm [t_funcs.c:122]: DEBUG: tm_shutdown : start >>>>> 0(3360) DEBUG: tm [t_funcs.c:125]: DEBUG: tm_shutdown : >>>>> emptying hash table >>>>> 0(3360) DEBUG: tm [t_funcs.c:127]: DEBUG: tm_shutdown : >>>>> removing semaphores >>>>> 0(3360) DEBUG: tm [t_funcs.c:129]: DEBUG: tm_shutdown : >>>>> destroying tmcb lists >>>>> 0(3360) DEBUG: tm [t_funcs.c:132]: DEBUG: tm_shutdown : done >>>>> >>>>> Thanks >>>>> >>>>> Nathaniel >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> -- >>>> Daniel-Constantin Mierla -http://www.asipto.com >>>> http://twitter.com/#!/miconda >>>> -http://www.linkedin.com/in/miconda >>>> >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com http://www.avg.com >>>> Version: 2012.0.1913 / Virus Database: 2411/4959 - Release >>>> Date: 04/25/12 >>>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2012.0.1913 / Virus Database: 2411/4960 - Release >>> Date: 04/26/12 >>> >>> >> >> >> _______________________________________________ >> 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 > > -- > Daniel-Constantin Mierla -http://www.asipto.com > http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda > > > No virus found in this message. > Checked by AVG - www.avg.com http://www.avg.com > Version: 2012.0.1913 / Virus Database: 2411/4965 - Release Date: > 04/28/12 >

---

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

---

No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2171 / Virus Database: 2425/4987 - Release Date: 05/09/12

---

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

---

No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2176 / Virus Database: 2425/5016 - Release Date: 05/22/12

Sorry. To make sure I got the right versions, I removed all of the previous files, reloaded and re-compiled Kamailio from git and ran the test again. I have included the full trace files from the core dump. Here is my setting for use_domain parameter:

#!define MULTIDOMAIN 1 modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 2) modparam("usrloc", "use_domain", MULTIDOMAIN)

Thanks

Nathaniel L Keeling

On 5/29/2012 4:15 AM, Daniel-Constantin Mierla wrote:

Hello,

is this with use_domain parameter set?

Also, from the backtrace, the condition is not

104 if (realm_prefix.len>0 && realm_prefix.len<puri.host.len &&

but

104 if (realm_prefix.len && realm_prefix.len<puri.host.len &&

It looks it is without the last recommendation I made - now I pushed the change also in master branch.

Cheers, Daniel

On 5/29/12 10:55 AM, Akan wrote:

...

I am still getting a core dump with Kamailio v3.2. I loaded Kamailio on a new server, applied the patch and started testing. I was able to register successfully which previously I was not, but now when I try to make a call, kamailio will take a core dump. I also loaded Kamailio v3.1 just to make sure that it is not a memory issue and I was able to place a call successfully without Kamailio taking a core dump. I have included the full backtrace from the dump and it looks like it is in the same place as previously. I loaded Kamailio v3.2 on 3 different servers with the same results of producing a core dump. I have not tried the new development version yet.

Thanks

Nathaniel

On 5/23/2012 1:44 AM, Akan wrote:

...

I'd setup another solaris server with kamailio v3.2, applied the patch and tested the change. Kamailio did not crash nor took a core dump. So it looks like it might be a hardware problem now.

Thanks

Nathaniel

On 5/9/2012 1:52 PM, Akan wrote:

...

I changed the use_domain parameter for usrloc to 0 and retried. Kamailio did not crash and I was able to get registered. I have another server with the same configurations as the one having the problem. I will apply the patch there and see if the problem still occurs. Also, setting the use_domain to 0 for usrloc, does this limit me to not being able to use other domains within the SIP message?

Thanks

Nathaniel

On 5/9/2012 3:05 AM, Daniel-Constantin Mierla wrote:

...

Hello,

I see no reason why it crashes at line 104 when realm_prefix.len==0.

Might be a memory problem (hardware). Can you try with use_domain parameter set to 0 for usrloc module?

Cheers, Daniel

This was a re-pull from the git master. I had deleted all of the old files and issued these commands:

git clone --depth 1 git://git.sip-router.org/sip-router kamailio cd kamailio git checkout -b 3.2 origin/3.2

This is the source that I got. Could this be a problem within git?

Thanks

Nathaniel

On 5/30/2012 9:55 AM, Daniel-Constantin Mierla wrote:

Hello,

On 5/30/12 4:26 AM, Akan wrote:

...

Sorry. To make sure I got the right versions, I removed all of the previous files, reloaded and re-compiled Kamailio from git and ran the test again.

is it git master branch? Because the branch 3.2 does not have all patches backported, as I wanted to test them first, 3.2 is a stable branch used in production.

It does not seem the latest as the line of crash is reporting to be:

102 realm_prefix.s = cfg_get(registrar, registrar_cfg, realm_pref);

And the last source code is:

realm_prefix.s = cfg_get(registrar, registrar_cfg, realm_pref).s;

Can you try with latest git master branch? At least will be sure it is the right source code.

Cheers, Daniel

...

I have included the full trace files from the core dump. Here is my setting for use_domain parameter:

#!define MULTIDOMAIN 1 modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 2) modparam("usrloc", "use_domain", MULTIDOMAIN)

Thanks

Nathaniel L Keeling

On 5/29/2012 4:15 AM, Daniel-Constantin Mierla wrote:

...

Hello,

is this with use_domain parameter set?

Also, from the backtrace, the condition is not

104 if (realm_prefix.len>0 && realm_prefix.len<puri.host.len &&

but

104 if (realm_prefix.len && realm_prefix.len<puri.host.len &&

It looks it is without the last recommendation I made - now I pushed the change also in master branch.

Cheers, Daniel

On 5/29/12 10:55 AM, Akan wrote:

...

I am still getting a core dump with Kamailio v3.2. I loaded Kamailio on a new server, applied the patch and started testing. I was able to register successfully which previously I was not, but now when I try to make a call, kamailio will take a core dump. I also loaded Kamailio v3.1 just to make sure that it is not a memory issue and I was able to place a call successfully without Kamailio taking a core dump. I have included the full backtrace from the dump and it looks like it is in the same place as previously. I loaded Kamailio v3.2 on 3 different servers with the same results of producing a core dump. I have not tried the new development version yet.

Thanks

Nathaniel

On 5/23/2012 1:44 AM, Akan wrote:

...

I'd setup another solaris server with kamailio v3.2, applied the patch and tested the change. Kamailio did not crash nor took a core dump. So it looks like it might be a hardware problem now.

Thanks

Nathaniel

On 5/9/2012 1:52 PM, Akan wrote:

...

I changed the use_domain parameter for usrloc to 0 and retried. Kamailio did not crash and I was able to get registered. I have another server with the same configurations as the one having the problem. I will apply the patch there and see if the problem still occurs. Also, setting the use_domain to 0 for usrloc, does this limit me to not being able to use other domains within the SIP message?

Thanks

Nathaniel

On 5/9/2012 3:05 AM, Daniel-Constantin Mierla wrote: > Hello, > > I see no reason why it crashes at line 104 when > realm_prefix.len==0. > > Might be a memory problem (hardware). Can you try with > use_domain parameter set to 0 for usrloc module? >

Ok, I reloaded the servers with v3.2 from git without performing the checkout and with just the master branch. Reran my tests on 2 servers and Kamailio terminated with a core dump. I have included the full trace of both servers.

Thanks

Nathaniel

On 5/30/2012 2:25 PM, Daniel-Constantin Mierla wrote:

Hello,

On 5/30/12 9:10 PM, Akan wrote:

...

This was a re-pull from the git master. I had deleted all of the old files and issued these commands:

git clone --depth 1 git://git.sip-router.org/sip-router kamailio cd kamailio git checkout -b 3.2 origin/3.2

This is the source that I got. Could this be a problem within git?

do not checkout branch 3.2, just try with the master branch, as said, not all patches are backported to stable 3.2.

For sake of completeness, here are some guidelines: http://www.kamailio.org/wiki/install/devel/git

Cheers, Daniel

Hello,

still strange with the crash on that if condition. One of your previous reports showed a different line, when assigning a pointer. Also, I kind of understood that save() was ok, but lookup() not. Is not the case anymore as the backtrace shows.

SIGBUS can occur because of alignment in memory which is thrown in solaris, does not happen in linux flavours. I am thinking of putting the prefix field first so the access to it is at beginning of the straucture, just to see if that is the problem, although is should not be.

I will add a patch soon, otherwise I am out of ideas for the moment with the SIGBUS, I would need access to the machine to do some testing by myself.

Cheers, Daniel

On 6/2/12 10:36 PM, Akan wrote:

Ok, I reloaded the servers with v3.2 from git without performing the checkout and with just the master branch. Reran my tests on 2 servers and Kamailio terminated with a core dump. I have included the full trace of one of the servers. The other trace has the same results.

Thanks

Nathaniel

On 5/30/2012 2:25 PM, Daniel-Constantin Mierla wrote:

...

Hello,

On 5/30/12 9:10 PM, Akan wrote:

...

This was a re-pull from the git master. I had deleted all of the old files and issued these commands:

git clone --depth 1 git://git.sip-router.org/sip-router kamailio cd kamailio git checkout -b 3.2 origin/3.2

This is the source that I got. Could this be a problem within git?

do not checkout branch 3.2, just try with the master branch, as said, not all patches are backported to stable 3.2.

For sake of completeness, here are some guidelines: http://www.kamailio.org/wiki/install/devel/git

Cheers, Daniel

---

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

Hello,

I got access and it is actually gcc, here are the compile options:

$ gmake Q=0 Makefile.defs defs skipped gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -DNAME='"kamailio"' -DVERSION='"3.3.0-pre3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3003000 -DCFG_DIR='"/usr/local/etc/kamailio/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DF_MALLOC -DMEM_JOIN_FREE -DUSE_TLS -DTLS_HOOKS -DUSE_CORE_STATS -DSTATISTICS -DMALLOC_STATS -DWITH_AS_SUPPORT -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -DMODS_DIR='"/usr/local/lib64/kamailio/modules:/usr/local/lib64/kamailio/modules_s:/usr/local/lib64/kamailio/modules_k"' -c main.c -o main.o -MMD -MP

I am doing some tests right now to see if I catch soemthing.

Cheers, Daniel

On 6/11/12 10:21 AM, Jason Penton wrote:

This seems like a really strange bug, what compiler are you using, gcc or sun studio? We use gcc and don't have any issues like this. I will use sun studio if you confirm that you are using it and will give that a go.

Cheers Jason

On Mon, Jun 4, 2012 at 8:57 AM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:

Hello,

still strange with the crash on that if condition. One of your
previous reports showed a different line, when assigning a
pointer. Also, I kind of understood that save() was ok, but
lookup() not. Is not the case anymore as the backtrace shows.

SIGBUS can occur because of alignment in memory which is thrown in
solaris, does not happen in linux flavours. I am thinking of
putting the prefix field first so the access to it is at beginning
of the straucture, just to see if that is the problem, although is
should not be.

I will add a patch soon, otherwise I am out of ideas for the
moment with the SIGBUS, I would need access to the machine to do
some testing by myself.

Cheers,
Daniel


On 6/2/12 10:36 PM, Akan wrote:

...

Ok, I reloaded the servers with v3.2 from git without performing
the checkout and with just the master branch.  Reran my tests on
2 servers and Kamailio terminated with a core dump. I have
included the full trace of one of the servers. The other trace
has the same results.

Thanks

Nathaniel

On 5/30/2012 2:25 PM, Daniel-Constantin Mierla wrote:

...

Hello,

On 5/30/12 9:10 PM, Akan wrote:

...

This was a re-pull from the git master. I had deleted all of
the old files and issued these commands:

git clone --depth 1 git://git.sip-router.org/sip-router kamailio
cd kamailio
git checkout -b 3.2 origin/3.2

This is the source that I got. Could this be a problem within git?

do not checkout branch 3.2, just try with the master branch, as
said, not all patches are backported to stable 3.2.

For sake of completeness, here are some guidelines:
http://www.kamailio.org/wiki/install/devel/git

Cheers,
Daniel

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org  <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw




_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer

Here is the information requested:

System = SunOS Node = -f Release = 5.10 KernelID = Generic_141444-09 Machine = sun4u BusType = <unknown> Serial = <unknown> Users = <unknown> OEM# = 0 Origin# = 1 NumCPU = 1

One machine is a Sun Fire V120, 2g memory, UltraSPARC-IIe 650MHz, UltraAX-i2 The other machine is a Sun Netra T1 200, 1g memory, UltraSparc-IIe 500MHz, UltraAX-i2

Thanks

Nathaniel L Keeling

On 6/11/2012 8:33 AM, Daniel-Constantin Mierla wrote:

Hello,

I committed a patch that should make it work when realm_prefix is not set for registrar module:

http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d42379da...

For the moment I have no idea why SIGBUS is triggered, i tried to access the structure directly, not via defines, and there is still a problem when realm_prefix is set. It's ok accessing the .len field but not .s of the same structure. The field .s is the first, making me think it's not alignment issue, or it is something very specific to this system.

Overall, I am not familiar with sparc/solaris systems, maybe if you send here full details about OS version, architecture and CPU type, others using similar systems can give hints.

Jason reported that on solaris with x86, this problem was not encountered.

Cheers, Daniel

On 6/4/12 8:57 AM, Daniel-Constantin Mierla wrote:

...

Hello,

still strange with the crash on that if condition. One of your previous reports showed a different line, when assigning a pointer. Also, I kind of understood that save() was ok, but lookup() not. Is not the case anymore as the backtrace shows.

SIGBUS can occur because of alignment in memory which is thrown in solaris, does not happen in linux flavours. I am thinking of putting the prefix field first so the access to it is at beginning of the straucture, just to see if that is the problem, although is should not be.

I will add a patch soon, otherwise I am out of ideas for the moment with the SIGBUS, I would need access to the machine to do some testing by myself.

Cheers, Daniel

On 6/2/12 10:36 PM, Akan wrote:

...

Ok, I reloaded the servers with v3.2 from git without performing the checkout and with just the master branch. Reran my tests on 2 servers and Kamailio terminated with a core dump. I have included the full trace of one of the servers. The other trace has the same results.

Thanks

Nathaniel

On 5/30/2012 2:25 PM, Daniel-Constantin Mierla wrote:

...

Hello,

On 5/30/12 9:10 PM, Akan wrote:

...

This was a re-pull from the git master. I had deleted all of the old files and issued these commands:

git clone --depth 1 git://git.sip-router.org/sip-router kamailio cd kamailio git checkout -b 3.2 origin/3.2

This is the source that I got. Could this be a problem within git?

do not checkout branch 3.2, just try with the master branch, as said, not all patches are backported to stable 3.2.

For sake of completeness, here are some guidelines: http://www.kamailio.org/wiki/install/devel/git

Cheers, Daniel

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.2178 / Virus Database: 2433/5061 - Release Date: 06/10/12

from the logs he has sent the mem addresses all look 64 bit. Sparc AFAIK is only 64 bit anyway

Cheers Jason

On Tue, Jun 12, 2012 at 8:50 AM, Daniel-Constantin Mierla <miconda@gmail.com

wrote:

Hello,

is it 64bit architecture?

Cheers, Daniel

On 6/11/12 9:12 PM, Akan wrote:

...

Here is the information requested:

System = SunOS Node = -f Release = 5.10 KernelID = Generic_141444-09 Machine = sun4u BusType = <unknown> Serial = <unknown> Users = <unknown> OEM# = 0 Origin# = 1 NumCPU = 1

One machine is a Sun Fire V120, 2g memory, UltraSPARC-IIe 650MHz, UltraAX-i2 The other machine is a Sun Netra T1 200, 1g memory, UltraSparc-IIe 500MHz, UltraAX-i2

Thanks

Nathaniel L Keeling

On 6/11/2012 8:33 AM, Daniel-Constantin Mierla wrote:

...

Hello,

I committed a patch that should make it work when realm_prefix is not set for registrar module:

http://git.sip-router.org/cgi-**bin/gitweb.cgi/sip-router/?a=**commit;h= **d42379da90f2ec87cb5dbb00ebb563**c7528ec910http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d42379da90f2ec87cb5dbb00ebb563c7528ec910

For the moment I have no idea why SIGBUS is triggered, i tried to access the structure directly, not via defines, and there is still a problem when realm_prefix is set. It's ok accessing the .len field but not .s of the same structure. The field .s is the first, making me think it's not alignment issue, or it is something very specific to this system.

Overall, I am not familiar with sparc/solaris systems, maybe if you send here full details about OS version, architecture and CPU type, others using similar systems can give hints.

Jason reported that on solaris with x86, this problem was not encountered.

Cheers, Daniel

On 6/4/12 8:57 AM, Daniel-Constantin Mierla wrote:

...

Hello,

still strange with the crash on that if condition. One of your previous reports showed a different line, when assigning a pointer. Also, I kind of understood that save() was ok, but lookup() not. Is not the case anymore as the backtrace shows.

SIGBUS can occur because of alignment in memory which is thrown in solaris, does not happen in linux flavours. I am thinking of putting the prefix field first so the access to it is at beginning of the straucture, just to see if that is the problem, although is should not be.

I will add a patch soon, otherwise I am out of ideas for the moment with the SIGBUS, I would need access to the machine to do some testing by myself.

Cheers, Daniel

On 6/2/12 10:36 PM, Akan wrote:

...

Ok, I reloaded the servers with v3.2 from git without performing the checkout and with just the master branch. Reran my tests on 2 servers and Kamailio terminated with a core dump. I have included the full trace of one of the servers. The other trace has the same results.

Thanks

Nathaniel

On 5/30/2012 2:25 PM, Daniel-Constantin Mierla wrote:

...

Hello,

On 5/30/12 9:10 PM, Akan wrote:

> This was a re-pull from the git master. I had deleted all of the old > files and issued these commands: > > git clone --depth 1 git://git.sip-router.org/sip-**routerhttp://git.sip-router.org/sip-routerkamailio > cd kamailio > git checkout -b 3.2 origin/3.2 > > This is the source that I got. Could this be a problem within git? > do not checkout branch 3.2, just try with the master branch, as said, not all patches are backported to stable 3.2.

For sake of completeness, here are some guidelines: http://www.kamailio.org/wiki/**install/devel/githttp://www.kamailio.org/wiki/install/devel/git

Cheers, Daniel

______________________________**_________________ 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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/**micondahttp://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/**micondahttp://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.2178 / Virus Database: 2433/5061 - Release Date: 06/10/12

______________________________**_________________ 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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/**micondahttp://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu

Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

______________________________**_________________ 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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer

I tested the patch and got different results. A core dump was still produced but in a different program. I have included the full backtrace.

Thanks

Nathaniel

On 6/12/2012 1:10 PM, Akan wrote:

Yes, this is a 64bit system

Thanks

Nathaniel

On 6/12/2012 1:50 AM, Daniel-Constantin Mierla wrote:

...

Hello,

is it 64bit architecture?

Cheers, Daniel

On 6/11/12 9:12 PM, Akan wrote:

...

Here is the information requested:

System = SunOS Node = -f Release = 5.10 KernelID = Generic_141444-09 Machine = sun4u BusType = <unknown> Serial = <unknown> Users = <unknown> OEM# = 0 Origin# = 1 NumCPU = 1

One machine is a Sun Fire V120, 2g memory, UltraSPARC-IIe 650MHz, UltraAX-i2 The other machine is a Sun Netra T1 200, 1g memory, UltraSparc-IIe 500MHz, UltraAX-i2

Thanks

Nathaniel L Keeling

On 6/11/2012 8:33 AM, Daniel-Constantin Mierla wrote:

...

Hello,

I committed a patch that should make it work when realm_prefix is not set for registrar module:

http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d42379da...

For the moment I have no idea why SIGBUS is triggered, i tried to access the structure directly, not via defines, and there is still a problem when realm_prefix is set. It's ok accessing the .len field but not .s of the same structure. The field .s is the first, making me think it's not alignment issue, or it is something very specific to this system.

Overall, I am not familiar with sparc/solaris systems, maybe if you send here full details about OS version, architecture and CPU type, others using similar systems can give hints.

Jason reported that on solaris with x86, this problem was not encountered.

Cheers, Daniel

On 6/4/12 8:57 AM, Daniel-Constantin Mierla wrote:

...

Hello,

still strange with the crash on that if condition. One of your previous reports showed a different line, when assigning a pointer. Also, I kind of understood that save() was ok, but lookup() not. Is not the case anymore as the backtrace shows.

SIGBUS can occur because of alignment in memory which is thrown in solaris, does not happen in linux flavours. I am thinking of putting the prefix field first so the access to it is at beginning of the straucture, just to see if that is the problem, although is should not be.

I will add a patch soon, otherwise I am out of ideas for the moment with the SIGBUS, I would need access to the machine to do some testing by myself.

Cheers, Daniel

On 6/2/12 10:36 PM, Akan wrote:

...

Ok, I reloaded the servers with v3.2 from git without performing the checkout and with just the master branch. Reran my tests on 2 servers and Kamailio terminated with a core dump. I have included the full trace of one of the servers. The other trace has the same results.

Thanks

Nathaniel

On 5/30/2012 2:25 PM, Daniel-Constantin Mierla wrote: > Hello, > > On 5/30/12 9:10 PM, Akan wrote: >> This was a re-pull from the git master. I had deleted all of >> the old files and issued these commands: >> >> git clone --depth 1 git://git.sip-router.org/sip-router kamailio >> cd kamailio >> git checkout -b 3.2 origin/3.2 >> >> This is the source that I got. Could this be a problem within git? > do not checkout branch 3.2, just try with the master branch, as > said, not all patches are backported to stable 3.2. > > For sake of completeness, here are some guidelines: > http://www.kamailio.org/wiki/install/devel/git > > Cheers, > Daniel >

---

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.2178 / Virus Database: 2433/5061 - Release Date: 06/10/12

---

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

---

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

---

No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2180 / Virus Database: 2433/5064 - Release Date: 06/12/12

Hello,

thanks for troubleshooting further -- as I expected, it is a memalign problem, but some confusing reports by not using always the patches I made to registrar module to align the structure, made thinking is something else. Now is no longer in registrar, but in another module.

There might be many of these, can you try to compile first without strict alignment to 8 bytes? Checking quickly to gcc, the option should be |-mno-faster-structs

So try:

make proper make FLAVOUR=kamailio cfg| make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all| ...

By providing Q=0, you will see all compile flags, verify that |-mno-faster-structs is there.

Cheers, Daniel | On 6/22/12 3:26 PM, Akan wrote:

Hello,

After doing some research, this is what I found out. On Solaris Sparc 64bit system, there is a mandatory alignment of memory accesses and also for data types. I went thru the core dump, disassembled the code and located the instruction that produced the error. The registers addresses in questioned are on a 4 byte alignment but not an 8 byte or 16 byte alignment. .The earlier patch must have forced the alignment which is why the error did not occur in the program common.c. It looks like there is a similar situation in t_funcs.c.

Here is a link that I found that can better explain: http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html

Core was generated by `/opt/kamailio-3.2/sbin/kamailio'. Program terminated with signal 10, Bus error. #0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0, proto=0, replicate=0) at t_funcs.c:352 352 if (!t_reply( t, p_msg , 100 ,

0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1 0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 t_reply@plt *=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3* 0xffffffff7bd2b7c0 <+992>: cmp %o0, 0 0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14 <t_relay_to+1844> 0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0 0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460 <t_relay_to+128>

End of assembler dump. (gdb) info registers g1 g1 0xffffffff7666c3e4 -2308520988 (gdb) info registers o3 o3 0x18f3d0 1635280

I hope this helps in trying to resolve this problem and to find a solution. Also, if you need a sparc system to test with, just let me know. We can help from a sparc perspective.

Thanks

Nathaniel

Just to let you know

I made a lot of tests using different modules including carrierroute, I do have the bus error also after the first call and core dump.

thank you O

On Jun 27, 2012, at 11:45 PM, Akan wrote:

Daniel,

i did a repull from git, compiled, installed and re-test of Kamailio and got the same error in the same program's location as previous (in tm_funcs.c). Here are the commands that I entered to make sure I did everything correctly:

mkdir -p /usr/local/src/kamailio/kamailio-3.2-noalignment cd /usr/local/src/kamailio/kamailio-3.2-noalignment git clone --depth 1 git://git.sip-router.org/sip-router kamailio cd kamailio |gmake proper gmake prefix=/opt/kamailio-3.2 FLAVOUR=kamailio cfg vi modules.lst | gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all |gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs install

Makefile:363: config.mak: No such file or directory normal Makefile.defs exec target architecture <sparc64>, host architecture <sparc64> generating autover.h ... making config... Makefile.defs defs skipped gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c endianness.c -o endianness.o -MMD -MP gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c select_buf.c -o select_buf.o -MMD -MP

|| Thanks

Nathaniel

| On 6/25/2012 3:05 AM, Daniel-Constantin Mierla wrote:

...

Hello,

thanks for troubleshooting further -- as I expected, it is a memalign problem, but some confusing reports by not using always the patches I made to registrar module to align the structure, made thinking is something else. Now is no longer in registrar, but in another module.

There might be many of these, can you try to compile first without strict alignment to 8 bytes? Checking quickly to gcc, the option should be |-mno-faster-structs

So try:

make proper make FLAVOUR=kamailio cfg| make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all| ...

By providing Q=0, you will see all compile flags, verify that |-mno-faster-structs is there.

Cheers, Daniel | On 6/22/12 3:26 PM, Akan wrote:

...

Hello,

After doing some research, this is what I found out. On Solaris Sparc 64bit system, there is a mandatory alignment of memory accesses and also for data types. I went thru the core dump, disassembled the code and located the instruction that produced the error. The registers addresses in questioned are on a 4 byte alignment but not an 8 byte or 16 byte alignment. .The earlier patch must have forced the alignment which is why the error did not occur in the program common.c. It looks like there is a similar situation in t_funcs.c.

Here is a link that I found that can better explain: http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html

Core was generated by `/opt/kamailio-3.2/sbin/kamailio'. Program terminated with signal 10, Bus error. #0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0, proto=0, replicate=0) at t_funcs.c:352 352 if (!t_reply( t, p_msg , 100 ,

0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1 0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 t_reply@plt *=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3* 0xffffffff7bd2b7c0 <+992>: cmp %o0, 0 0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14 <t_relay_to+1844> 0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0 0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460 <t_relay_to+128>

End of assembler dump. (gdb) info registers g1 g1 0xffffffff7666c3e4 -2308520988 (gdb) info registers o3 o3 0x18f3d0 1635280

I hope this helps in trying to resolve this problem and to find a solution. Also, if you need a sparc system to test with, just let me know. We can help from a sparc perspective.

Thanks

Nathaniel

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.2180 / Virus Database: 2437/5091 - Release Date: 06/24/12

---

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

Hello,

for solaris sparc64 you have to find the option for compiler not to build with strict alignment requirement for structures. I checked quickly on the web in some man pages, but I am not sure I got the right solution (what I previously sent on this thread).

If anyone can allocate resources to check all the structure, will be another variant, at some time/money expence, but I guess the fast will be the right flag to compiler.

Cheers, Daniel

On 7/2/12 12:47 AM, Omar Labs 188 Gmail wrote:

I tried in solaris the version kamailio 3.3.0 Bus error. For solaris I have had that same issue in any version above the 1.4.3.

If i test in Suse, kamailio crashes when the radius or Diameter module is enabled. this i tested with versions 3.1 3.2 i am checking if i can get the gdb for all this.

I was unable to build it yet for 3.3.0

thank you

O

On Jun 30, 2012, at 8:54 PM, Omar Labs 188 Gmail wrote:

...

Just to let you know

I made a lot of tests using different modules including carrierroute, I do have the bus error also after the first call and core dump.

thank you O

On Jun 27, 2012, at 11:45 PM, Akan wrote:

...

Daniel,

i did a repull from git, compiled, installed and re-test of Kamailio and got the same error in the same program's location as previous (in tm_funcs.c). Here are the commands that I entered to make sure I did everything correctly:

mkdir -p /usr/local/src/kamailio/kamailio-3.2-noalignment cd /usr/local/src/kamailio/kamailio-3.2-noalignment git clone --depth 1 git://git.sip-router.org/sip-router kamailio cd kamailio |gmake proper gmake prefix=/opt/kamailio-3.2 FLAVOUR=kamailio cfg vi modules.lst | gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all |gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs install

Makefile:363: config.mak: No such file or directory normal Makefile.defs exec target architecture <sparc64>, host architecture <sparc64> generating autover.h ... making config... Makefile.defs defs skipped gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c endianness.c -o endianness.o -MMD -MP gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c select_buf.c -o select_buf.o -MMD -MP

|| Thanks

Nathaniel

| On 6/25/2012 3:05 AM, Daniel-Constantin Mierla wrote:

...

Hello,

thanks for troubleshooting further -- as I expected, it is a memalign problem, but some confusing reports by not using always the patches I made to registrar module to align the structure, made thinking is something else. Now is no longer in registrar, but in another module.

There might be many of these, can you try to compile first without strict alignment to 8 bytes? Checking quickly to gcc, the option should be |-mno-faster-structs

So try:

make proper make FLAVOUR=kamailio cfg| make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all| ...

By providing Q=0, you will see all compile flags, verify that |-mno-faster-structs is there.

Cheers, Daniel | On 6/22/12 3:26 PM, Akan wrote:

...

Hello,

After doing some research, this is what I found out. On Solaris Sparc 64bit system, there is a mandatory alignment of memory accesses and also for data types. I went thru the core dump, disassembled the code and located the instruction that produced the error. The registers addresses in questioned are on a 4 byte alignment but not an 8 byte or 16 byte alignment. .The earlier patch must have forced the alignment which is why the error did not occur in the program common.c. It looks like there is a similar situation in t_funcs.c.

Here is a link that I found that can better explain: http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html

Core was generated by `/opt/kamailio-3.2/sbin/kamailio'. Program terminated with signal 10, Bus error. #0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0, proto=0, replicate=0) at t_funcs.c:352 352 if (!t_reply( t, p_msg , 100 ,

0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1 0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 t_reply@plt *=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3* 0xffffffff7bd2b7c0 <+992>: cmp %o0, 0 0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14 <t_relay_to+1844> 0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0 0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460 <t_relay_to+128>

End of assembler dump. (gdb) info registers g1 g1 0xffffffff7666c3e4 -2308520988 (gdb) info registers o3 o3 0x18f3d0 1635280

I hope this helps in trying to resolve this problem and to find a solution. Also, if you need a sparc system to test with, just let me know. We can help from a sparc perspective.

Thanks

Nathaniel

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.2180 / Virus Database: 2437/5091 - Release Date: 06/24/12

---

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

---

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

---

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

Hello,

you will have to read the manual of the compiler and the specifics of the operating system to build it without 64b alignment requirements. I attempted to find it on the web, bit it may have not been the right one.

Cheers, Daniel

On 6/28/12 5:45 AM, Akan wrote:

Daniel,

i did a repull from git, compiled, installed and re-test of Kamailio and got the same error in the same program's location as previous (in tm_funcs.c). Here are the commands that I entered to make sure I did everything correctly:

mkdir -p /usr/local/src/kamailio/kamailio-3.2-noalignment cd /usr/local/src/kamailio/kamailio-3.2-noalignment git clone --depth 1 git://git.sip-router.org/sip-router kamailio cd kamailio |gmake proper gmake prefix=/opt/kamailio-3.2 FLAVOUR=kamailio cfg vi modules.lst | gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all |gmake prefix=/opt/kamailio-3.2 Q=0 CC_EXTRA_OPTS=|-mno-faster-structs install

Makefile:363: config.mak: No such file or directory normal Makefile.defs exec target architecture <sparc64>, host architecture <sparc64> generating autover.h ... making config... Makefile.defs defs skipped gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c endianness.c -o endianness.o -MMD -MP gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -fno-strict-overflow -ftree-vectorize -Wall -mno-faster-structs -DNAME='"ser"' -DVERSION='"3.2.3"' -DARCH='"sparc64"' -DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 4.6.2"' -D__CPU_sparc64 -D__OS_solaris -DSER_VER=3002003 -DCFG_DIR='"/opt/kamailio-3.2/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DDBG_QM_MALLOC -DUSE_TLS -DTLS_HOOKS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H -c select_buf.c -o select_buf.o -MMD -MP

|| Thanks

Nathaniel

| On 6/25/2012 3:05 AM, Daniel-Constantin Mierla wrote:

...

Hello,

thanks for troubleshooting further -- as I expected, it is a memalign problem, but some confusing reports by not using always the patches I made to registrar module to align the structure, made thinking is something else. Now is no longer in registrar, but in another module.

There might be many of these, can you try to compile first without strict alignment to 8 bytes? Checking quickly to gcc, the option should be |-mno-faster-structs

So try:

make proper make FLAVOUR=kamailio cfg| make Q=0 CC_EXTRA_OPTS=|-mno-faster-structs all| ...

By providing Q=0, you will see all compile flags, verify that |-mno-faster-structs is there.

Cheers, Daniel | On 6/22/12 3:26 PM, Akan wrote:

...

Hello,

After doing some research, this is what I found out. On Solaris Sparc 64bit system, there is a mandatory alignment of memory accesses and also for data types. I went thru the core dump, disassembled the code and located the instruction that produced the error. The registers addresses in questioned are on a 4 byte alignment but not an 8 byte or 16 byte alignment. .The earlier patch must have forced the alignment which is why the error did not occur in the program common.c. It looks like there is a similar situation in t_funcs.c.

Here is a link that I found that can better explain: http://blog.jgc.org/2007/04/debugging-solaris-bus-error-caused-by.html

Core was generated by `/opt/kamailio-3.2/sbin/kamailio'. Program terminated with signal 10, Bus error. #0 0xffffffff7bd2b7bc in t_relay_to (p_msg=0x10047c698, proxy=0x0, proto=0, replicate=0) at t_funcs.c:352 352 if (!t_reply( t, p_msg , 100 ,

0xffffffff7bd2b7b0 <+976>: ldx [ %l7 + %g1 ], %g1 0xffffffff7bd2b7b4 <+980>: ldx [ %g1 ], %g1 0xffffffff7bd2b7b8 <+984>: call 0xffffffff7be9bc80 t_reply@plt *=> 0xffffffff7bd2b7bc <+988>: ldx [ %g1 + 0x38 ], %o3* 0xffffffff7bd2b7c0 <+992>: cmp %o0, 0 0xffffffff7bd2b7c4 <+996>: be,pn %icc, 0xffffffff7bd2bb14 <t_relay_to+1844> 0xffffffff7bd2b7c8 <+1000>: ldx [ %fp + 0x7f7 ], %o0 0xffffffff7bd2b7cc <+1004>: b %xcc, 0xffffffff7bd2b460 <t_relay_to+128>

End of assembler dump. (gdb) info registers g1 g1 0xffffffff7666c3e4 -2308520988 (gdb) info registers o3 o3 0x18f3d0 1635280

I hope this helps in trying to resolve this problem and to find a solution. Also, if you need a sparc system to test with, just let me know. We can help from a sparc perspective.

Thanks

Nathaniel

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2012.0.2180 / Virus Database: 2437/5091 - Release Date: 06/24/12

---

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