| 00:00.24 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 00:12.35 | coreyfarrell | mjordan: you got a minute to discuss ASTERISK-24805? we've had many bugs for memory usage after free and crashes during 'core stop now', I'm thinking that most uses of ast_register_atexit are wrong. |
| 00:21.28 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 00:21.39 | mjordan | to some extent, I think testing memory issues for 'core stop now' is pointless. |
| 00:21.50 | mjordan | actually, not even 'to some extent'. It is pointless. |
| 00:22.06 | mjordan | Either we'll end up corrupting something because things are still in flight, or we don't clean up the memory and leak it. |
| 00:22.20 | mjordan | a 'core stop now' is a "Screw the woman and children, I'm grabbing a lifeboat" kind of exit. |
| 00:22.56 | mjordan | what do you think? |
| 00:23.33 | coreyfarrell | I think we should close_logger (flush it), do what we need to avoid astdb corruption, and exit(0) |
| 00:24.04 | mjordan | it'd be nice to shutdown Stasis as well |
| 00:24.12 | mjordan | I'm not sure if we do that on exit or not. |
| 00:25.24 | coreyfarrell | the threadpool in stasis.c is shutdown regardless.. everything else in stasis*.c uses ast_register_cleanup |
| 00:27.23 | coreyfarrell | I think ast_register_atexit should be used under conditions where we can prove that it's very important to run those cleanups. the only reasons I can think of is to avoid corruption or (excessive) data loss |
| 00:29.28 | mjordan | CDRs |
| 00:29.32 | mjordan | that's the only other one I can think of. |
| 00:29.38 | mjordan | We generally try to force billing information out |
| 00:29.51 | mjordan | and it has several callbacks that are chained to try and make sure that occurs. |
| 00:29.58 | coreyfarrell | yup... but what happens to CDR of a channel that is never hung up? |
| 00:30.02 | mjordan | I'm good with the rest getting moved out to cleanup |
| 00:30.04 | mjordan | you lose it |
| 00:30.24 | mjordan | but since CDRs are often batched and/or put onto a separate thread, the atexit call tries to make sure records in flight get pushed out |
| 00:31.48 | coreyfarrell | so maybe 'core stop now' should attempt to hangup all channels? |
| 00:32.02 | coreyfarrell | that way we get CDR for calls terminated by shutdown |
| 00:32.12 | coreyfarrell | or most anyways |
| 00:33.04 | file | that would be a very drastic change to the behavior of core stop now |
| 00:35.00 | coreyfarrell | just so I understand right are you talking about the hanging up channels idea? or everything I've said? |
| 00:35.31 | file | hanging up channels idea |
| 00:36.48 | coreyfarrell | point taken |
| 00:42.58 | mjordan | yeah... |
| 00:42.59 | gtjoseph | file: coreyfarrell: Actually, I'd be in favor of the hangup thing. The active calls were up for some time and did terminate. Seems better to capture that if possible. |
| 00:43.17 | mjordan | but at that point, why not just issue 'channel request hangup all' |
| 00:43.19 | mjordan | and then stop? |
| 00:44.07 | gtjoseph | yeah, it's just an extra step though. |
| 00:44.57 | gtjoseph | is there a case where you'd actually want the calls to not generate CDRs? |
| 00:47.09 | mjordan | not really sure |
| 00:47.17 | mjordan | part of the problem is that we don't wait for all the channels to exit |
| 00:47.22 | mjordan | on a core stop now |
| 00:47.23 | coreyfarrell | if calls are going through kamailio to asterisk and asterisk just disappears, is it possible for kamailio to redirect all active calls? |
| 00:47.26 | mjordan | so you aren't guaranteed to get the data |
| 00:47.41 | mjordan | coreyfarrell: only if it is running as a stateful proxy |
| 00:47.57 | mjordan | and if you block on the channels dying, you might as well do a 'core stop gracefully' |
| 00:48.23 | coreyfarrell | I wasn't suggesting we should block, just try :) |
| 00:48.35 | gtjoseph | maybe need 'terminate all calls and stop accepting new ones" |
| 00:49.12 | coreyfarrell | gtjoseph: I agree with you, but that's not core stop graceful or core stop now, it's in between. |
| 00:49.31 | coreyfarrell | core stop soon :) |
| 00:49.41 | gtjoseph | yep, exactly. the trouble with gracefull is that on a busy system, you could wait a long time. |
| 00:51.11 | gtjoseph | hmmm. when you do a graceful now, does asterisk stop taking calls while it's quiescing? |
| 00:51.23 | coreyfarrell | pretty sure |
| 00:51.47 | coreyfarrell | it's 'core stop when convenient' or something that allows more calls while we wait to reach 0 |
| 00:52.35 | gtjoseph | oh yeah, I remember now. |
| 00:53.56 | mjordan | coreyfarrell: yup, it does |
| 00:54.01 | mjordan | I'd be okay with (yet another) shutdown option |
| 00:54.05 | mjordan | it'd certainly be less intrusive |
| 00:54.14 | mjordan | at least from the user perspective |
| 00:54.54 | coreyfarrell | another crazy thought I just had to go with this, it would be nice if I could put 'sigkill=core stop soon' into asterisk.conf :) |
| 01:00.11 | mjordan | that actually would be nice |
| 01:02.58 | coreyfarrell | i'll think about that one.. I assume the 'core stop soon' command and signal assignment are trunk only ideas? |
| 01:03.45 | mjordan | how many tests do you want to write? |
| 01:03.50 | mjordan | :-) |
| 01:04.05 | coreyfarrell | none :P |
| 01:05.25 | mjordan | trunk! |
| 02:20.11 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 02:33.57 | *** join/#asterisk-dev dustinm (~dustinm@105.ip-167-114-152.net) |
| 03:58.00 | *** join/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 03:58.17 | *** part/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 06:52.06 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 06:52.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:15.33 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 08:15.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:46.31 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 08:46.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:27.40 | stefan27 | what svn checkout commands checks out the same source code as is tarred in wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-13.1.0.tar.gz |
| 11:37.21 | *** join/#asterisk-dev pchero_travel (~pchero@80-62-116-172-mobile.dk.customer.tdc.net) |
| 11:50.55 | coreyfarrell | stefan27: svn co http://svn.asterisk.org/svn/asterisk/tags/13.1.0/ |
| 11:56.16 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 11:56.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:23.33 | *** join/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 12:23.37 | *** part/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 13:02.36 | stefan27 | thanks |
| 13:05.56 | stefan27 | coreyfarrell: You commented and commited on an issue i created some months ago https://issues.asterisk.org/jira/browse/ASTERISK-24281 do you remember this issue? |
| 13:07.07 | stefan27 | Was that commit in fact shipped to 13.1.0? If so i'll try reproduce the test case and see if its fixed with music on hold not being removed |
| 13:07.20 | stefan27 | so that old issue hopefully can be closed? |
| 13:08.21 | stefan27 | let me see if i can reproduce it |
| 13:11.18 | stefan27 | I couldnt reproduce it on first attempt - It looks like something from 12.5.0 to 13.1.0 fixed it but let me verify |
| 13:13.28 | stefan27 | Not on second try either; ill comment on the jira |
| 13:19.51 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-qfmtwwkvvvhksnwe) |
| 13:19.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:20.50 | stefan27 | i don't have any 12 installations to test it on anymore |
| 13:22.42 | stefan27 | but you do? https://issues.asterisk.org/jira/browse/ASTERISK-24281 was in fact an easily reproducable bug so check if you can consider it fixed |
| 13:26.00 | stefan27 | ill be back on monday |
| 13:35.05 | *** join/#asterisk-dev pchero_travel (~pchero@80-62-116-172-mobile.dk.customer.tdc.net) |
| 15:27.11 | *** join/#asterisk-dev pchero_travel (~pchero@80-62-116-172-mobile.dk.customer.tdc.net) |
| 16:38.38 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-dgywyxlqjmvqedcm) |
| 16:42.43 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 16:47.25 | pchero_travel | Hi, guys. |
| 16:48.52 | pchero_travel | Does anybody here who can explain about bug-for-bug term? The mighty google says it's same means with bug-compatible. But I don't get it bug-compatible either. |
| 16:49.17 | pchero_travel | what is bug-for-bug? |
| 16:49.32 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 17:36.42 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 19:36.07 | *** join/#asterisk-dev oej (~oej@2001:16d8:cc57:42:3db4:594b:81c2:dd62) |
| 19:36.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:41.28 | skrusty | evening all |
| 20:57.13 | mjordan | evening skrusty |
| 21:17.09 | coreyfarrell | stefan27: wasn't sure at the time that my commit would fix your issue, glad it did. looks like someone else marked the ticket resolved. |
| 21:22.17 | mjordan | file and I are doing backlog digging, so I went ahead and closed it out when I saw the comment |
| 21:28.19 | coreyfarrell | yeah I saw.. almost down to 1000 unresolved tickets :) |
| 21:32.23 | coreyfarrell | how would you feel about marking https://issues.asterisk.org/jira/browse/ASTERISK-13402 - "[patch] JSON Manager Event Interface" as either won't fix or workaround available (ARI)? |
| 21:43.47 | coreyfarrell | hmm looks like the reporter is still active on the system, I'll just ping the ticket to see if they still want to pursue. |
| 21:51.43 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 21:51.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:52.07 | snuff-home | has anyone tried recently to deploy * on freeBSD?.. i know on openBSD it fails due to backtrace issues |
| 22:10.33 | mjordan | coreyfarrell: I'd be okay marking it as won't fix or the other. At this point, the patch isn't going to be the right way to do it |
| 22:10.45 | mjordan | snuff-home: what do you mean 'backtrace issues'? |
| 22:13.27 | coreyfarrell | mjordan: yeah I already queried the ticket to see if the reporter wanted to pursue further since the reporter is still active on JIRA |
| 22:32.58 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 22:32.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 22:53.59 | snuff-home | mjordan: as in can't compile due to the backtrace code |
| 22:58.26 | coreyfarrell | snuff-home: configure.ac not checking for a symbol needed by HAVE_BKTR that doesn't exist in bsd? |
| 22:58.56 | snuff-home | i think its that while it might have it.. it doesn't resemble what linux has |
| 22:59.11 | mjordan | yeah, if that were the case, then that would be a bug. I don't recall seeing that. Of course, portability things usually need patches, but that shouldn't be that hard to fix |
| 22:59.41 | snuff-home | i tried a crude method.. n failed for a really simple fix |
| 23:00.09 | snuff-home | am testing both bsd's again now |
| 23:16.13 | *** join/#asterisk-dev pchero (~pchero@0x555140b5.adsl.cybercity.dk) |
| 23:47.26 | snuff-home | example from obsd.. root/ast-trunk/include/asterisk/utils.h:28:22: error: execinfo.h: No such file or directory |
| 23:50.18 | snuff-home | basically i go comment that out etc.. gets lil further.. then has issues with the 'backtrace' function itself |
| 23:53.40 | coreyfarrell | hmm, looks like utils.h fails to consider !defined(HAVE_BKTR) |
| 23:54.10 | coreyfarrell | which would break the logger infinite loop detection. |
| 23:55.01 | coreyfarrell | maybe it's best for MALLOC_FAILURE_MSG to do nothing if !defined(HAVE_BKTR) |