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 <[email protected]>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 > <[email protected]>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 >> [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
