| 01:02.46 | coreyfarrell | file: still around? |
| 01:02.51 | file | yes |
| 01:03.20 | coreyfarrell | I was just looking at select.h to try figuring out why we get "FD 32766 exceeds the maximum size of ast_fdset!" |
| 01:03.54 | coreyfarrell | it seems like the maximum FD should be 32768 (or maybe 32767)? |
| 01:04.48 | coreyfarrell | the conditional compile that has "#define ast_FDMAX32768" is active. |
| 01:06.45 | file | this sounds like a Richard question |
| 01:06.52 | coreyfarrell | I'm having trouble understanding 'if (fd / _bitsize(*bytes) + ((fd + 1) % _bitsize(*bytes) ? 1 : 0) < sizeof(*(fds)) / SIZEOF_FD_SET_FDS_BITS)', not sure why we don't just compare to ast_FDMAX. |
| 01:08.05 | coreyfarrell | ok I'll ask him next time he's on.. |
| 01:10.56 | file | my loop of this unit test has continued to run fine |
| 01:11.17 | file | sad |
| 01:11.26 | coreyfarrell | weird. have you gotten to look at the asterisk logs? |
| 01:12.25 | coreyfarrell | oh wait if the test isn't failing then the logs don't matter |
| 01:13.34 | file | quite |
| 01:13.57 | file | I may see what happens overnight, audit the code some, and also ponder what I can do to the testsuite to make stuff like this easier to figure out |
| 01:14.10 | file | well - Jenkins executions of unit tests that is |
| 01:15.02 | coreyfarrell | you said you are just running one unit test or all of them in your loop? |
| 01:15.10 | file | currently one of them |
| 01:15.32 | file | multiple may happen tomorrow |
| 01:15.39 | coreyfarrell | sounds like it might be some weird interaction between two tests |
| 01:20.26 | file | yeah, could be |
| 01:21.36 | file | there, I altered it to run all the cache thrash tests |
| 01:21.59 | file | will that do anything? WHO KNOWS |
| 01:29.04 | file | coreyfarrell, yup that did it |
| 01:29.25 | coreyfarrell | cool |
| 01:38.55 | file | yeah, seems to be a bit of starvation under that scenario causing the thread to wait for the write lock for awhile |
| 01:39.18 | file | so when it goes to stop the threads the first one just blocks on the pthread_join as it can't stop |
| 01:39.22 | file | fixable! |
| 01:41.57 | file | I shall toy with it tomorrow |
| 04:07.52 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 04:07.52 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 04:49.01 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 04:49.01 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 04:59.04 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 04:59.04 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 07:16.59 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 07:44.50 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.135.186) |
| 07:52.16 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 07:52.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:10.00 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:25.59 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 09:57.52 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 11:23.18 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 11:23.18 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:38.21 | file | coreyfarrell, I think... I have a fix! |
| 13:27.27 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 14:06.31 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 14:20.46 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 14:49.58 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:49.59 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:51.00 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:51.00 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:04.15 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:04.15 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:05.03 | cresl1n | file: !!!!!! |
| 15:05.06 | file | moo |
| 15:05.44 | cresl1n | moo who? |
| 15:06.23 | file | cresl1n, SQUIRREL |
| 15:16.59 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gbibmeixpimwtkiv) |
| 15:18.04 | jsmith | cresl1n: Wait, you're chatting in IRC again? WHAT HAS THE WORLD COME TO?!? |
| 15:18.10 | jsmith | ducks and hides |
| 15:18.12 | *** join/#asterisk-dev goddva (~goddva@2a02:fe0:c510:e300:ae9e:17ff:fe91:a8c9) |
| 15:18.20 | cresl1n | jsmith!!!!! |
| 15:19.40 | file | it's like old times! |
| 15:31.56 | cresl1n | All things old become new again. |
| 15:33.26 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 16:16.18 | *** join/#asterisk-dev dar123 (~bad53@107-203-254-31.lightspeed.sntcca.sbcglobal.net) |
| 16:28.59 | file | Gerrit is being restarted. Java has decided that it would like to consume all memory in the known universe. |
| 16:30.53 | file | Restart completed. |
| 16:35.09 | file | It is now consuming slightly less than all memory in the known universe. |
| 16:42.43 | cresl1n | file: sounds just like java to think that. |
| 16:42.58 | cresl1n | How dare it. |
| 16:43.50 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-rinhoaejokvbsikn) |
| 16:44.09 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-kxiyxgderhriwhkn) |
| 16:44.46 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-szfqawhllyphaiqa) |
| 16:57.39 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 16:57.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:00.30 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-214-127.w81-53.abo.wanadoo.fr) |
| 17:10.52 | coreyfarrell | file: so does that review fix the problem or just improve the shutdown speed? seems like it just stops threads in parallel instead of serially. |
| 17:11.03 | file | it fixes it |
| 17:11.24 | file | the read threads back off and let the writer threads in faster |
| 17:11.42 | file | which causes it all to shutdown properly on time |
| 17:16.52 | coreyfarrell | ahh the readers are at the end of the list so they keep hold on RW locks.. can the commit message mention the contention between read and write? |
| 17:18.54 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 17:18.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:21.01 | file | coreyfarrell, sure! |
| 17:23.36 | file | updated |
| 17:25.01 | coreyfarrell | and +1'ed |
| 17:33.54 | file | merci |
| 17:38.57 | coreyfarrell | file: so how did that bug cause asterisk to terminate? that's the part I don't understand, why the unit test didn't just freeze forever. |
| 17:39.16 | file | for some reason the remote console terminated after about 2 minutes |
| 17:41.21 | coreyfarrell | oh so the unit test was still running when the remote console disconnected then the normal process for stopping asterisk occurred? |
| 17:41.41 | file | yes |
| 17:41.55 | file | and terminating Asterisk in that case works fine |
| 17:46.31 | file | merci pour le review |
| 17:51.38 | coreyfarrell | rmudgett: last night I was looking FD_SET (in asterisk/select.h) to try troubleshooting the testsuite message: "FD 32766 exceeds the maximum size of ast_fdset!". in that macro I don't understand the 'if' conditional, but wouldn't if (fd < ast_FDMAX) protect us from buffer overrun? |
| 17:52.35 | rmudgett | Which asterisk version in case it matters. |
| 17:52.40 | coreyfarrell | in which case fd 32766 is less than ast_FDMAX (32768) so it should be within the buffer? |
| 17:52.54 | coreyfarrell | right now I'm looking at 11 |
| 18:20.14 | coreyfarrell | file: little piece of good news, asterisk 11 ref_debug had only 4 tests with leaks. all instances of asterisk from all tests shutdown gracefully. |
| 18:20.48 | file | I need to see what happens this weekend in regards to those... the normal periodics sorta stopped working after the ref_debug runs |
| 18:21.18 | file | I kicked zuul, but I'll leave it alone next time and see if they continue to not... work... and then look at logs |
| 18:21.29 | coreyfarrell | weird |
| 18:21.36 | file | very |
| 18:22.05 | coreyfarrell | oh wait it's run by java.. so I guess screwing up is not so weird. |
| 18:22.46 | file | I still maintain I can handle managing this stuff over Atlassian products |
| 18:27.17 | file | I think we still have 2 unit tests which fail maybe once or twice a month, but that's okay for now |
| 18:27.26 | rmudgett | coreyfarrell: That if test seems just wrong. |
| 18:29.03 | rmudgett | I think the ((fd + 1) % _bitsize(*bytes) ? 1 : 0) part should just be removed. |
| 18:31.38 | rmudgett | The if test could be changed to: if (fd / _bitsize(*bytes) < ast_FDMAX / 8 / SIZEOF_FD_SET_FDS_BITS) {} |
| 18:32.15 | rmudgett | As it is now, the last array element in ast_fdset could never be used. |
| 18:32.24 | coreyfarrell | rmudgett: any reason we can't say: if (fd < ast_FDMAX) ? |
| 18:32.55 | rmudgett | That'd work too. |
| 18:33.04 | rmudgett | It's also simpler. :) |
| 18:36.31 | coreyfarrell | I have to go out for a bit but I'll get that posted for review later.. thanks for checking this out. |
| 18:36.33 | rmudgett | Also won't need the 32bit and 64bit comments above the if test. |
| 18:37.10 | rmudgett | That range check was just overly complicated. |
| 18:38.37 | coreyfarrell | got it |
| 18:54.56 | file | how old was it? |
| 19:00.14 | gtjoseph | anyone know if Mark's around? |
| 19:02.43 | file | I have nudged him |
| 19:02.53 | file | virtually |
| 19:02.56 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 19:02.56 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 19:03.00 | gtjoseph | :) |
| 19:03.14 | gtjoseph | you'd need a really long stick otherwise. |
| 19:03.26 | file | or I could send kharwell to do so |
| 19:07.37 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:07.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:28.24 | coreyfarrell | is it possible to request that jenkins run any testsuite test against an open review? I'm not sure how else to test the FD_SET change except to have jenkins do it, I've never seen anything else use FD 32766. |
| 20:30.03 | file | it's... sorta... yeah |
| 20:30.39 | file | if you put a review up and it gets a +2 it will run Jenkins gates against it |
| 20:30.53 | file | thus the "sorta" |
| 20:38.45 | file | once a check is done I'll +2 one and see what happens |
| 20:40.28 | file | gates in progress |
| 20:49.01 | file | coreyfarrell, seems to be good |
| 20:50.44 | coreyfarrell | cool now we just need a version of twisted that doesn't warn about using it's own deprecated interface :) |
| 20:52.13 | file | this 11 gating may actually fully pass |
| 20:52.40 | coreyfarrell | does it not normally pass? |
| 20:52.56 | file | it depends on how it is feeling |
| 20:54.06 | file | I may use your 13 and master reviews to see how gating on 13 and master is doing |
| 20:54.38 | file | ties up nodes for the next hour on the gates |
| 21:12.42 | file | zomgz the 11 passed and merged in |
| 21:15.12 | coreyfarrell | looks like that deprecated interface warning is removed from twisted 15.5.0 (the interface was removed). |
| 21:16.26 | coreyfarrell | weird that they marked an interface deprecated when it's automatically imported by twisted/internet/endpoints.py |
| 21:27.30 | file | JENKINS. IS. WORKING. |
| 22:12.14 | file | coreyfarrell, welp that was cool |
| 22:12.31 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:13.28 | coreyfarrell | all 3 branches passed the gates |
| 22:13.34 | file | yup |
| 22:20.20 | file | putnopvut, for the rest of the week if you go to submit anything can you just +2 it? |
| 22:31.01 | putnopvut | absolutely not! |
| 22:31.05 | putnopvut | (ok fine) |
| 23:13.53 | file | I apparently left my cache thrash test running all day |
| 23:15.20 | coreyfarrell | oops |