[asterisk-dev] [Code Review] 4501: ast_register_atexit should only be used when absolutely needed (13+ version)

[Corey Farrell]

> On March 20, 2015, 8:21 p.m., rmudgett wrote:
> > I'm wondering about the "core restart now" leaving all that memory and threadpool threads active.  Won't those things still be around after the restart?  A "core stop now" is no problem because the system will reclaim everything anyway.  However, a restart may just accumulate the lost resources.

>From http://man7.org/linux/man-pages/man2/execve.2.html:
       execve() does not return on success, and the text, data, bss, and
       stack of the calling process are overwritten by that of the program
       loaded.

My understanding is that execvp() is a front-end procedure that uses execve (that's what my local man-pages says).  This tells me that the memory is not an issue for sure.  Since it's a new process and all memory is purged, I don't see how threads could be maintained.  If this is an issue then my change makes it only slightly worse.  Channels drivers all have a monitoring thread and they are already left for the OS to cleanup during "core restart now".


> On March 20, 2015, 8:21 p.m., rmudgett wrote:
> > /branches/13/main/bridge.c, lines 5356-5357
> > <https://reviewboard.asterisk.org/r/4501/diff/1/?file=72402#file72402line5356>
> >
> >     These can be merged.

Will do.


> On March 20, 2015, 8:21 p.m., rmudgett wrote:
> > /branches/13/main/http.c, line 2341
> > <https://reviewboard.asterisk.org/r/4501/diff/1/?file=72417#file72417line2341>
> >
> >     This may need to stay.  HTTP needs to shutdown socket connections.
> >     
> >     Manager as well.

I don't think this is an issue, asterisk.c sets FD_CLOEXEC to FD's 3..32768 in the final stage of restart.


- Corey


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4501/#review14759
-----------------------------------------------------------


On March 15, 2015, 6:33 a.m., Corey Farrell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4501/
> -----------------------------------------------------------
> 
> (Updated March 15, 2015, 6:33 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24142, ASTERISK-24683, ASTERISK-24805, and ASTERISK-24881
>     https://issues.asterisk.org/jira/browse/ASTERISK-24142
>     https://issues.asterisk.org/jira/browse/ASTERISK-24683
>     https://issues.asterisk.org/jira/browse/ASTERISK-24805
>     https://issues.asterisk.org/jira/browse/ASTERISK-24881
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> We've had many issues related to "core stop now" or "core restart now" causing segmentation faults.  The solution to this is to change almost everything to use ast_register_cleanup.
> 
> Exceptions:
> CDR: Flush records.
> res_musiconhold: Kill external applications.
> AstDB: Close the DB.
> canary_exit: Kill canary process.
> 
> Although some changes from ast_register_atexit to ast_register_cleanup are not strictly necessary, the point is for nothing to use ast_register_atexit except where required.  For this reason the change is across the board.
> 
> 
> Diffs
> -----
> 
>   /branches/13/main/xmldoc.c 432991 
>   /branches/13/main/utils.c 432991 
>   /branches/13/main/udptl.c 432991 
>   /branches/13/main/timing.c 432991 
>   /branches/13/main/threadstorage.c 432991 
>   /branches/13/main/taskprocessor.c 432991 
>   /branches/13/main/stun.c 432991 
>   /branches/13/main/stasis.c 432991 
>   /branches/13/main/sounds_index.c 432991 
>   /branches/13/main/sorcery.c 432991 
>   /branches/13/main/rtp_engine.c 432991 
>   /branches/13/main/pickup.c 432991 
>   /branches/13/main/pbx.c 432991 
>   /branches/13/main/message.c 432991 
>   /branches/13/main/manager_system.c 432991 
>   /branches/13/main/manager_mwi.c 432991 
>   /branches/13/main/manager_endpoints.c 432991 
>   /branches/13/main/manager_channels.c 432991 
>   /branches/13/main/manager_bridges.c 432991 
>   /branches/13/main/manager.c 432991 
>   /branches/13/main/indications.c 432991 
>   /branches/13/main/image.c 432991 
>   /branches/13/main/http.c 432991 
>   /branches/13/main/format_cache.c 432991 
>   /branches/13/main/format.c 432991 
>   /branches/13/main/file.c 432991 
>   /branches/13/main/features.c 432991 
>   /branches/13/main/dnsmgr.c 432991 
>   /branches/13/main/data.c 432991 
>   /branches/13/main/core_local.c 432991 
>   /branches/13/main/config_options.c 432991 
>   /branches/13/main/config.c 432991 
>   /branches/13/main/codec.c 432991 
>   /branches/13/main/cli.c 432991 
>   /branches/13/main/channel.c 432991 
>   /branches/13/main/cel.c 432991 
>   /branches/13/main/ccss.c 432991 
>   /branches/13/main/bridge.c 432991 
>   /branches/13/main/astobj2_container.c 432991 
>   /branches/13/main/astobj2.c 432991 
>   /branches/13/main/astmm.c 432991 
>   /branches/13/main/astfd.c 432991 
>   /branches/13/main/asterisk.c 432991 
>   /branches/13/main/aoc.c 432991 
>   /branches/13/include/asterisk.h 432991 
> 
> Diff: https://reviewboard.asterisk.org/r/4501/diff/
> 
> 
> Testing
> -------
> 
> Compiled, started and ran 'core stop now'.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150321/b8dd6b63/attachment.html>