[SR-Users] segmentation fault in init_mod_child function

Bruno Bresciani bruno.bresciani at gmail.com
Thu Nov 10 12:24:44 CET 2011


Thank's for reply Tino
follows the content of "print m" in gdb:
*
Program terminated with signal 11, Segmentation fault.
#0  init_mod_child (m=0xa238, rank=4) at sr_module.c:827
827     sr_module.c: Arquivo ou diretório não encontrado.
        in sr_module.c
(gdb)
(gdb)
(gdb)
(gdb) print m
$1 = (struct sr_module *) 0xa238
(gdb) p m
$2 = (struct sr_module *) 0xa238
(gdb) p *m
Cannot access memory at address 0xa238
(gdb)*

I'm trying to understand why "m" become messy only when I load my
loadbalance.so module... it was written to SER and now I'm porting it to the
kamailio.

Best Regards


2011/11/9 Timo Reimann <sr at foo-lounge.de>

> Hey Bruno,
>
>
> Am 09.11.2011 um 20:31 schrieb Bruno Bresciani:
> > 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.
> >
> > 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.
> >
> > Kamailio's trace:
> >
> > 9(27616) DEBUG: db_postgres [km_pg_con.c:80]: PQsetdbLogin(0x8db2878)
> >  9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5): sl
> >  9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5):
> auth_db
> >  9(27616) DEBUG: <core> [db.c:294]: connection 0x82f4108 found in pool
> >  9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5):
> usrloc
> >  9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5):
> mi_fifo
> >  9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5):
> registrar
> >  9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5):
> nathelper
> >  9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5):
> permissions
> >  9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5):
> loadbalance
> >  9(27616) DEBUG: loadbalance [loadbalance_mod.c:271]: loadbalance: child
> started! (5)
> >  9(27616) DEBUG: <core> [sr_module.c:828]: DEBUG: init_mod_child (5):
> route
> >  0(27582) ALERT: <core> [main.c:741]: child process 27585 exited by a
> signal 11
> >  0(27582) ALERT: <core> [main.c:744]: core was generated
> >  0(27582) INFO: <core> [main.c:756]: INFO: terminating due to SIGCHLD
> >  8(27615) INFO: <core> [main.c:807]: INFO: signal 15 received
> >  8(27615) DEBUG: <core> [main.c:818]: Memory status (pkg):
> >  8(27615) DEBUG: fm_status: fm_status (0x82aefc0):
> >  8(27615) DEBUG: fm_status:  heap size= 4194304
> >  8(27615) DEBUG: fm_status:  used= 236720, used+overhead=264064,
> free=3930240
> >  8(27615) DEBUG: fm_status:  max used (+overhead)= 299824
> >  8(27615) DEBUG: fm_status: dumping free list:
> >  8(27615) DEBUG: fm_status: hash =   1 fragments no.:    27, unused:
> 0
> >                  bucket size:         8 -         8 (first         8)
> >  8(27615) DEBUG: fm_status: hash =  44 fragments no.:     1, unused:
> 0
> >                  bucket size:       352 -       352 (first       352)
> >  8(27615) DEBUG: fm_status: hash =  74 fragments no.:     1, unused:
> 0
> >                  bucket size:       592 -       592 (first       592)
> >  8(27615) DEBUG: fm_status: hash =  77 fragments no.:     1, unused:
> 0
> >                  bucket size:       616 -       616 (first       616)
> >  8(27615) DEBUG: fm_status: hash =  81 fragments no.:     1, unused:
> 0
> >                  bucket size:       648 -       648 (first       648)
> >  8(27615) DEBUG: fm_status: hash =  84 fragments no.:     1, unused:
> 0
> >                  bucket size:       672 -       672 (first       672)
> >  8(27615) DEBUG: fm_status: hash = 113 fragments no.:    51, unused:
> 0
> >                  bucket size:       904 -       904 (first       904)
> >  8(27615) DEBUG: fm_status: hash = 2056 fragments no.:     1, unused:
>   0
> >
> >
> > gdb bt full trace:
> >
> >
> > Reading symbols from
> /media/sda1/local/kamailio/lib/kamailio/modules/route.so...done.
> > Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/route.so
> > Reading symbols from
> /media/sda1/local/kamailio/lib/kamailio/modules/rtpproxy.so...done.
> > Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/rtpproxy.so
> > Reading symbols from
> /media/sda1/local/kamailio/lib/kamailio/modules/tls.so...done.
> > Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/tls.so
> > Reading symbols from
> /media/sda1/local/kamailio/lib/kamailio/modules/perms_db.so...done.
> > Loaded symbols for /home2/local/kamailio/lib/kamailio/modules/perms_db.so
> > Reading symbols from /lib/libnss_files.so.2...done.
> > Loaded symbols for /lib/libnss_files.so.2
> > Reading symbols from /lib/libnss_dns.so.2...done.
> > Loaded symbols for /lib/libnss_dns.so.2
> > Core was generated by `/home2/local/kamailio/sbin/kamailio -P
> /var/run/kamailio.pid'.
> > Program terminated with signal 11, Segmentation fault.
> > #0  init_mod_child (m=0xa238, rank=2) at sr_module.c:827
> > 827     sr_module.c: Arquivo ou diretório não encontrado.
> >         in sr_module.c
> > (gdb)
> > (gdb)
> > (gdb)
> > (gdb)
> > (gdb)
> > (gdb)
> > (gdb) bt full
> > #0  init_mod_child (m=0xa238, rank=2) at sr_module.c:827
> > No locals.
> > #1  0x00000000 in ?? ()
> > No symbol table info available.
> > (gdb)
>
> 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.
>
>
> HTH,
>
> --Timo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20111110/222b5251/attachment.htm>


More information about the sr-users mailing list