[OpenSIPS-Users] opensips shutdown leaves some processes

[Jeff Pyle]

Hi Bogdan,

You're right, localhost doesn't seem to have anything to do with it.  In
fact, I can't reproduce this problem anymore.  One difference is now I'm
using DBG_QM_MALLOC instead of F_MALLOC to troubleshoot the other memory
issue.

Now, instead of leaving processes running after shutdown, it crashes
outright:
  CRITICAL:core:qm_free: freeing already freed pointer, first free:
t_reply.c: free_faked_req(580) - aborting

This happens only if I use the uac_auth() function.  I ran it again to get
a memlog and it failed like this:
  CRITICAL:core:qm_free: freeing already freed pointer, first free: auth.c:
uac_auth(187) - aborting

This is probably the same problem as bug 126.  Memlog and bt available here:
  http://storageb.fidelityvoice.net/~jpyle/signal6.zip


- Jeff



On Mon, Nov 18, 2013 at 4:59 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:

>  Hi Jeff,
>
> the LO interface issue is really strange - I cannot imagine a relation
> between the LO interface and the shutdown interface....attaching with gdb
> to a running process is as simple as accessing a core file "gdb bin_file
> pid"
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 11/14/2013 04:36 PM, Jeff Pyle wrote:
>
> Hi Bogdan,
>
>  I had not, that's a new concept for me.  I'll see what I can do.
>  Changing from localhost to LAN IPs did solve the problem of processes not
> shutting down properly, however.  Just the already freed memory crash<https://github.com/OpenSIPS/opensips/issues/126>remains.
>
>
>  - Jeff
>
>
>
> On Thu, Nov 14, 2013 at 5:29 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:
>
>>  Hi Jeff,
>>
>> Have you tried to attach with gdb to the remaining process and to get a
>> backtrace ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>> On 11/12/2013 06:03 AM, Jeff Pyle wrote:
>>
>>    Hello,
>>
>>  In one particular configuration on 1.10 a standard Opensips shutdown
>> isn't ending all the processes...if calls have passed through the system.
>>  If no calls have passed, everything shuts down fine.
>>
>>  At one particular moment in time with everything running I have:
>>
>>  Process::  ID=0 PID=26283 Type=attendant
>> Process::  ID=1 PID=26284 Type=MI XMLRPC
>> Process::  ID=2 PID=26285 Type=MI FIFO
>> Process::  ID=3 PID=26286 Type=RTPP timeout receiver
>> Process::  ID=4 PID=26287 Type=SIP receiver udp:127.0.0.1:5002
>> Process::  ID=5 PID=26288 Type=SIP receiver udp:127.0.0.1:5002
>> Process::  ID=6 PID=26289 Type=time_keeper
>> Process::  ID=7 PID=26290 Type=timer
>>
>>  But after /etc/init.d/opensips stop, it's always the attendant (26283)
>> and the second SIP receiver (26288) hanging around.  It requires a kill -9
>> to get them to go away.
>>
>>  A full debug isn't showing anything obvious:
>>
>>  Nov 11 22:51:29 [26283] DBG:core:handle_sigs: SIGTERM received, program
>> terminates
>> Nov 11 22:51:29 [26289] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26288] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26290] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26287] INFO:core:sig_usr: signal 15 received
>>  Nov 11 22:51:29 [26286] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26285] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26284] INFO:core:sig_usr: signal 15 received
>>
>>  But not everything has terminated:
>>
>>  # ps ax | grep opensips
>> 26283 ?        S<     0:00 /usr/sbin/opensips -f
>> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
>> opensips -g opensips
>> 26288 ?        R<     0:21 /usr/sbin/opensips -f
>> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
>> opensips -g opensips
>>
>>  Any suggestions on where to continue investigating?
>>
>>
>>  - Jeff
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20131118/fb190ca7/attachment-0001.htm>