[sr-dev] [kamailio] kamailio crash on receive_fd (version: 4.2 , >4.2.6) (#466)

BroWater notifications at github.com
Mon Feb 15 10:57:39 CET 2016


I tested the stop issue using the script "sh kamctl restart" with several times and it can be reproduced.
In my version which has changes in codes, it printed like this:

```
mv7:/tmp/kamailio/sbin# sh kamctl restart

\E[37;33mINFO: Stopping Kamailio : 
\E[37;33mINFO: stopped

\E[37;33mINFO: Starting Kamailio : 
23370 XXX   0:00 ./kamailio -P /var/run/kamailio.pid -f /tmp/kamailio/etc/kamailio//kamailio.cfg
23371 XXX   0:00 ./kamailio -P /var/run/kamailio.pid -f /tmp/kamailio/etc/kamailio//kamailio.cfg
23478 XXX   0:00 /bin/egrep kamailio
-rw-r--r--    1 XXX XXX         6 Feb 15 16:14 /var/run/kamailio.pid
\E[37;33mINFO: PID file exists (/var/run/kamailio.pid)! Kamailio already running?
```
The children processes above then terminated after a few seconds later,
but the /var/run/kamailio.pid (may be or not)was still there,
I had to remove it by myself to make the restart work.

And I also tried to build kamailio with the stock version - with just a few changes to make compiling and execution work, following is what I've done with it:

1. **build the config.mak for ARM**

    make cfg include_modules="db_sqlite tls" mode=debug ARCH=armv41 CPU=cortex-a8 PREFIX=/tmp/kamailio
2. **modify the config.mak**

   CC= /usr/gcc/bin/arm-marvell-linux-gnueabi-gcc
   LD= /usr/gcc/bin/arm-marvell-linux-gnueabi-gcc
   MKDEP= /usr/gcc/bin/arm-marvell-linux-gnueabi-gcc -MM -MG
   and remove -Wcast-align
3. **make all**
     
    dbase.h:29:21: fatal error: sqlite3.h: No such file or directory
    => I add sqlite3.h in the modules/db_sqlite/ and change the db_sqlite.h
   //#include \<sqlite3.h\>
   #include "sqlite3.h"

    /usr/bin/ld: cannot find -lsqlite3
    => so I put the libsqlite3.so in the modules/db_sqlite and change the Makefile in the same directory
   #LIBS= -L$(LOCALBASE)/lib -lsqlite3
   LIBS= -L./ -lsqlite3

After testing with this version, the error still occurs.

I check the unfinished children process by attaching with gdb, both two versions show the same result:

```
#0  0x400650b8 in wait () from /lib/libpthread.so.0
#1  0x000be6f0 in shutdown_children (sig=15, show_status=1) at main.c:708
#2  0x000bf288 in handle_sigs () at main.c:741
#3  0x000ca9bc in main_loop () at main.c:1757
#4  0x000d0830 in main (argc=5, argv=0xbeb82c94) at main.c:2581
```

```
#0  0x40111a04 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x4010c0b8 in pthread_mutex_lock () from /lib/libpthread.so.0
#2  0x000bc7e0 in cfg_update_local (no_cbs=1) at cfg/cfg_struct.h:339
#3  0x000c21a4 in sig_usr (signo=15) at main.c:857
#4  <signal handler called>
#5  0x40112450 in recvfrom () from /lib/libpthread.so.0
#6  0x00265848 in udp_rcv_loop () at udp_server.c:446
#7  0x000c90a0 in main_loop () at main.c:1629
#8  0x000d0830 in main (argc=5, argv=0xbee68c94) at main.c:2581
```

or 

```
#0  0x4012aa04 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x401250b8 in pthread_mutex_lock () from /lib/libpthread.so.0
#2  0x000bc7e0 in cfg_update_local (no_cbs=1) at cfg/cfg_struct.h:339
#3  0x000c21a4 in sig_usr (signo=15) at main.c:857
#4  <signal handler called>
#5  0x4026fc5c in epoll_wait () from /lib/libc.so.6
#6  0x4109fc14 in io_wait_loop_epoll (h=0x410c9898, t=10, repeat=0) at ../../io_wait.h:1042
#7  0x410a4fc0 in io_listen_loop (fd_no=1, cs_lst=0x4ff960) at io_listener.c:292
#8  0x4107881c in mod_child (rank=0) at ctl.c:333
#9  0x001d83b0 in init_mod_child (m=0x403067c8, rank=0) at sr_module.c:921
#10 0x001d8090 in init_mod_child (m=0x40306ae0, rank=0) at sr_module.c:918
#11 0x001d8090 in init_mod_child (m=0x403078b8, rank=0) at sr_module.c:918
#12 0x001d8090 in init_mod_child (m=0x40307bd8, rank=0) at sr_module.c:918
#13 0x001d8770 in init_child (rank=0) at sr_module.c:947
#14 0x000c9b2c in main_loop () at main.c:1706
#15 0x000d0830 in main (argc=5, argv=0xbe8d3c94) at main.c:2581
```

Any ideas??

---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/466#issuecomment-184139851
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20160215/2ac51ae9/attachment.html>


More information about the sr-dev mailing list