Re: [sr-dev] Initialize modules before handling SIP messages

Hello, kamailio is calling the module destroy function without the module being fully initialized, so it is good at least to initialize to a value at declaration and check in the destroy function. Then, ensuring that no traffic is processed could be hard if some modules do such things on their own. Kamailio is starting listening once starting forking children (main process doesn't listen on 'sip' sockets). If I understood right, the (last) crashes reported by Olle to me (via irc) happened after proper startup - a sip request was sent and a reply was received. At least a backtrace I received was: #0 0x00007fff565b2f24 in ?? () No symbol table info available. #1 0x000000010eaa2b76 in notification_resp_callback_f (msg=0x109d47080, code=200, node=0x10acdc5d8, param=0x0) at notification_peer.c:330 #2 0x000000010ea8a829 in dmq_tm_callback (t=0x10acdcad8, type=1024, ps=0x7fff565b5e88) at dmq_funcs.c:64 cb_param = (dmq_cback_param_t *) 0x10acdc588 #3 0x000000010a82a6d8 in run_trans_callbacks_internal (cb_lst=0x10acdcb48, type=1024, trans=0x10acdcad8, params=0x7fff565b5e88) at t_hooks.c:268 #4 0x000000010a82a82d in run_trans_callbacks (type=1024, trans=0x10acdcad8, req=0x0, rpl=0x109d47080, code=200) at t_hooks.c:295 #5 0x000000010a883b84 in local_reply (t=0x10acdcad8, p_msg=0x109d47080, branch=0, msg_status=200, cancel_data=0x7fff565b6748) at t_reply.c:2039 #6 0x000000010a886cbf in reply_received (p_msg=0x109d47080) at t_reply.c:2395 #7 0x0000000109712ca3 in do_forward_reply (msg=0x109d47080, mode=0) at forward.c:747 #8 0x000000010971254a in forward_reply (msg=0x109d47080) at forward.c:849 #9 0x00000001097ebfa1 in receive_msg (buf=0x109c615e0 "SIP/2.0 200 OK ...", ...) at receive.c:255 #10 0x00000001099a44d7 in udp_rcv_loop () at udp_server.c:496 On the other hand, some where from init time -- it might have used the event route for htable mod init, adding items in hash table there. So the htable module has to handle this case or dmq be prepared. #0 0x00007fff5a18ef04 in ?? () No symbol table info available. #1 0x000000010aec9800 in dmq_notification_callback (msg=0x1071023f0, resp=0x7fff5a193780, dmq_node=0x107100338) at notification_peer.c:236 #2 0x000000010aed0271 in worker_loop (id=0) at worker.c:101 #3 0x000000010aea9cba in child_init (rank=0) at dmq.c:293 #4 0x0000000105cfba35 in init_mod_child (m=0x10614f400, rank=0) at sr_module.c:898 More details on what I discovered while troubleshooting is that the init callback in dmq is executed also via the callbacks for message received, as part of the last peer in the list which seems to be kind of special structure content. Hopefully the above can help you get some leads of what goes wrong (note that some lines might have small offset, as I added some checks at some point and didn't correlate the time of commits with the backtraces). Cheers, Daniel On 09/01/15 11:01, Alex Hermann wrote: -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda