Thank's for reply Tino<br>follows the content of "print m" in gdb:<br><b><br>Program terminated with signal 11, Segmentation fault.<br>#0 init_mod_child (m=0xa238, rank=4) at sr_module.c:827<br>827 sr_module.c: Arquivo ou diretório não encontrado.<br>
in sr_module.c<br>(gdb)<br>(gdb)<br>(gdb)<br>(gdb) print m<br>$1 = (struct sr_module *) 0xa238<br>(gdb) p m<br>$2 = (struct sr_module *) 0xa238<br>(gdb) p *m<br>Cannot access memory at address 0xa238<br>(gdb)</b><br>
<br>I'm trying to understand why "m" become messy only when I load my loadbalance.so module... <span id="result_box" class="" lang="en"><span class="hps">it was written</span> <span class="hps">to</span> <span class="hps">SER and</span> <span class="hps">now I'm</span> <span class="hps">porting it to</span> <span class="hps">the</span> <span class="hps">kamailio.<br>
<br>Best Regards<br></span></span><br><br><div class="gmail_quote">2011/11/9 Timo Reimann <span dir="ltr"><<a href="mailto:sr@foo-lounge.de">sr@foo-lounge.de</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hey Bruno,<br>
<br>
<br>
Am 09.11.2011 um 20:31 schrieb Bruno Bresciani:<br>
<div><div></div><div class="h5">> Kamailio 3.1.2 terminated with signal 11, segmentation fault, in the init_mod_child function at sr_module.c file. This problem occurs only when I try loading the loadbalance.so module, it was written by me.<br>
><br>
> Someone Can help me to understand why this segmentation fault was generated? There are two other module written by me and this problem doesn't happen.<br>
><br>
> Kamailio's trace:<br>
><br>
> 9(27616) DEBUG: db_postgres [km_pg_con.c:80]: PQsetdbLogin(0x8db2878)<br>
> 9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): sl<br>
> 9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): auth_db<br>
> 9(27616) DEBUG: <core> [db.c:294]: connection 0x82f4108 found in pool<br>
> 9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): usrloc<br>
> 9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): mi_fifo<br>
> 9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): registrar<br>
> 9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): nathelper<br>
> 9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): permissions<br>
> 9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): loadbalance<br>
> 9(27616) DEBUG: loadbalance [loadbalance_mod.c:271]: loadbalance: child started! (5)<br>
> 9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): route<br>
> 0(27582) ALERT: <core> [main.c:741]: child process 27585 exited by a signal 11<br>
> 0(27582) ALERT: <core> [main.c:744]: core was generated<br>
> 0(27582) INFO: <core> [main.c:756]: INFO: terminating due to SIGCHLD<br>
> 8(27615) INFO: <core> [main.c:807]: INFO: signal 15 received<br>
> 8(27615) DEBUG: <core> [main.c:818]: Memory status (pkg):<br>
> 8(27615) DEBUG: fm_status: fm_status (0x82aefc0):<br>
> 8(27615) DEBUG: fm_status: heap size= 4194304<br>
> 8(27615) DEBUG: fm_status: used= 236720, used+overhead=264064, free=3930240<br>
> 8(27615) DEBUG: fm_status: max used (+overhead)= 299824<br>
> 8(27615) DEBUG: fm_status: dumping free list:<br>
> 8(27615) DEBUG: fm_status: hash = 1 fragments no.: 27, unused: 0<br>
> bucket size: 8 - 8 (first 8)<br>
> 8(27615) DEBUG: fm_status: hash = 44 fragments no.: 1, unused: 0<br>
> bucket size: 352 - 352 (first 352)<br>
> 8(27615) DEBUG: fm_status: hash = 74 fragments no.: 1, unused: 0<br>
> bucket size: 592 - 592 (first 592)<br>
> 8(27615) DEBUG: fm_status: hash = 77 fragments no.: 1, unused: 0<br>
> bucket size: 616 - 616 (first 616)<br>
> 8(27615) DEBUG: fm_status: hash = 81 fragments no.: 1, unused: 0<br>
> bucket size: 648 - 648 (first 648)<br>
> 8(27615) DEBUG: fm_status: hash = 84 fragments no.: 1, unused: 0<br>
> bucket size: 672 - 672 (first 672)<br>
> 8(27615) DEBUG: fm_status: hash = 113 fragments no.: 51, unused: 0<br>
> bucket size: 904 - 904 (first 904)<br>
> 8(27615) DEBUG: fm_status: hash = 2056 fragments no.: 1, unused: 0<br>
><br>
><br>
> gdb bt full trace:<br>
><br>
><br>
> Reading symbols from /media/sda1/local/kamailio/lib/kamailio/modules/route.so...done.<br>
> Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/route.so<br>
> Reading symbols from /media/sda1/local/kamailio/lib/kamailio/modules/rtpproxy.so...done.<br>
> Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/rtpproxy.so<br>
> Reading symbols from /media/sda1/local/kamailio/lib/kamailio/modules/tls.so...done.<br>
> Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/tls.so<br>
> Reading symbols from /media/sda1/local/kamailio/lib/kamailio/modules/perms_db.so...done.<br>
> Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/perms_db.so<br>
> Reading symbols from /lib/libnss_files.so.2...done.<br>
> Loaded symbols for /lib/libnss_files.so.2<br>
> Reading symbols from /lib/libnss_dns.so.2...done.<br>
> Loaded symbols for /lib/libnss_dns.so.2<br>
> Core was generated by `/home2/local/kamailio/sbin/kamailio -P /var/run/kamailio.pid'.<br>
> Program terminated with signal 11, Segmentation fault.<br>
> #0 init_mod_child (m=0xa238, rank=2) at sr_module.c:827<br>
> 827 sr_module.c: Arquivo ou diretório não encontrado.<br>
> in sr_module.c<br>
> (gdb)<br>
> (gdb)<br>
> (gdb)<br>
> (gdb)<br>
> (gdb)<br>
> (gdb)<br>
> (gdb) bt full<br>
> #0 init_mod_child (m=0xa238, rank=2) at sr_module.c:827<br>
> No locals.<br>
> #1 0x00000000 in ?? ()<br>
> No symbol table info available.<br>
> (gdb)<br>
<br>
</div></div>The address of the "m" struct in init_mod_child looks awkward. Although it's non-null, it's probably not within the validity range of the process's address space, thereby causing a segfault. You can verify this by investigating the coredump in gdb and printing m's content with "print m". If my assumption holds, try figuring out why m became messy in the first place.<br>
<br>
<br>
HTH,<br>
<font color="#888888"><br>
--Timo</font></blockquote></div><br>