| 00:19.55 | *** join/#asterisk-bugs mjordan (~mjordan@75.76.55.191) |
| 00:19.55 | *** mode/#asterisk-bugs [+o mjordan] by ChanServ |
| 03:27.43 | *** join/#asterisk-bugs darkbasic (~quassel@niko.linuxsystems.it) |
| 12:24.35 | *** join/#asterisk-bugs tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 14:06.14 | *** join/#asterisk-bugs putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:06.14 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 14:25.08 | *** join/#asterisk-bugs sgriepentrog (~sgriepent@162-239-32-132.lightspeed.brhmal.sbcglobal.net) |
| 15:22.49 | *** join/#asterisk-bugs newtonr (RustyNewto@nat/digium/x-znoceefenvpynspc) |
| 15:22.49 | *** mode/#asterisk-bugs [+o newtonr] by ChanServ |
| 16:30.14 | *** join/#asterisk-bugs sgriepentrog (~sgriepent@2602:30a:2ef2:840:20c:29ff:fe4f:cac8) |
| 16:56.32 | *** join/#asterisk-bugs superscrat (asanders@nat/digium/x-prauudjnkymshjlk) |
| 19:47.05 | *** join/#asterisk-bugs mjordan (~mjordan@75.76.55.191) |
| 19:47.06 | *** mode/#asterisk-bugs [+o mjordan] by ChanServ |
| 23:06.56 | *** join/#asterisk-bugs mjordan (~mjordan@75.76.55.191) |
| 23:06.56 | *** mode/#asterisk-bugs [+o mjordan] by ChanServ |
| 23:26.13 | *** join/#asterisk-bugs mjordan (mjordan@nat/digium/x-nmjohfncnrmfnrta) |
| 23:26.13 | *** mode/#asterisk-bugs [+o mjordan] by ChanServ |
| 23:27.15 | file | SQUIRREL |
| 23:28.10 | mjordan | chipmunk? |
| 23:28.24 | file | very good |
| 23:29.23 | file | ASTERISK-18323 |
| 23:30.02 | file | MOAR MEMORY |
| 23:31.04 | mjordan | huh |
| 23:31.35 | mjordan | rmudgett always thought that is occurred, but I'm not sure I ever reproduced that one |
| 23:32.14 | mjordan | ah, but it looks like we fixed that one already anyway |
| 23:32.50 | file | chan_iax2 still eats gobs of memory |
| 23:34.19 | mjordan | oo |
| 23:34.26 | mjordan | chan_iax2: sure, but does it leak them? |
| 23:34.38 | file | I don't think so |
| 23:34.40 | mjordan | it's probably just allocating a lock for every sequence number |
| 23:34.44 | file | it is |
| 23:34.48 | mjordan | that's dumb, but not a bug :-P |
| 23:34.54 | file | agreed |
| 23:35.25 | mjordan | while we're on the issue of "but why would you do that", ASTERISK-17752 |
| 23:35.53 | mjordan | does a quick test |
| 23:36.52 | file | huh |
| 23:37.09 | file | that's interesting |
| 23:40.52 | mjordan | no white space occurred |
| 23:40.58 | mjordan | and we didn't blow up the database |
| 23:41.15 | file | how was le memory? |
| 23:41.38 | mjordan | lawl |
| 23:41.47 | mjordan | I read the issue wrong. I'll have to go back and comment on it again |
| 23:41.48 | mjordan | :-P |
| 23:41.55 | file | slacker |
| 23:44.15 | mjordan | nuts |
| 23:44.19 | mjordan | memory is growing.. |
| 23:44.23 | mjordan | I wonder why. |
| 23:44.24 | file | I wonder... why... |
| 23:44.28 | file | is it us or sqlite? |
| 23:44.34 | mjordan | dunno |
| 23:44.56 | file | if you build with MALLOC_DEBUG you should be able to know |
| 23:46.25 | mjordan | true |
| 23:46.30 | mjordan | interestingly, we no longer have a 4k limit |
| 23:47.14 | mjordan | killing the channel _does_ look like it leaked. |
| 23:47.16 | mjordan | A mystery! |
| 23:47.51 | file | most foul |
| 23:48.08 | mjordan | looks for something easier to close |
| 23:48.34 | file | how about a CDR issue? :P |
| 23:48.55 | file | ASTERISK-17316 |
| 23:49.01 | mjordan | https://issues.asterisk.org/jira/browse/ASTERISK-19254 |
| 23:49.08 | mjordan | that one looks like it has a valid work around |
| 23:49.26 | file | agreed |
| 23:50.00 | mjordan | heh |
| 23:50.07 | mjordan | ASTERISK-17316 has a work around as well |
| 23:52.02 | file | oh my - a users.conf patch |
| 23:52.05 | mjordan | although, that is odd. Using CALLERID generally should change the caller ID on the CDR. |
| 23:55.15 | file | mjordan, guess what I found! |
| 23:55.16 | mjordan | huh |
| 23:55.20 | mjordan | logger.c? |
| 23:55.31 | file | a hint: autoservice |
| 23:55.42 | mjordan | interesting |
| 23:55.48 | file | unrelated to that |
| 23:55.51 | file | ASTERISK-18764 |
| 23:56.17 | file | that looks like the autoservice+pbx realtime deadlock |
| 23:57.34 | mjordan | yeah |
| 23:57.43 | mjordan | crazy though, the memory leak is in logger.c |
| 23:57.49 | file | oic |
| 23:57.55 | mjordan | yeah... |
| 23:58.07 | mjordan | and then it flushes out. |
| 23:58.09 | mjordan | HM> |
| 23:58.22 | mjordan | something tells me that the logger thread gets overwhelmed |
| 23:58.30 | mjordan | until it flushes everything out to the CLI |
| 23:58.44 | mjordan | yupp. |
| 23:58.54 | mjordan | soon as the CLI caught up with the infinite dump of stuff, memory stopped. |
| 23:59.02 | mjordan | I'll bet if I didn't have verbose on, I wouldn't see squat |
| 23:59.09 | file | nods |
| 23:59.43 | mjordan | yup |
| 23:59.45 | mjordan | NOT A BUG |