| 00:07.30 | *** join/#asterisk-dev Tim_Toady (~fuzzy@77.49.0.213.dsl.dyn.forthnet.gr) |
| 00:16.48 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-wnamikpxhcjidxso) |
| 00:17.43 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 00:18.22 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 02:13.05 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:13.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:51.42 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 04:44.11 | *** join/#asterisk-dev irroot (~gregory@41.48.158.166) |
| 05:32.23 | *** join/#asterisk-dev irroot (~gregory@41.48.158.166) |
| 05:47.24 | *** part/#asterisk-dev irroot (~gregory@41.48.158.166) |
| 07:49.42 | wdoekes2 | morning |
| 07:50.04 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 07:50.59 | *** join/#asterisk-dev Tim_Toady (~fuzzy@178.128.128.109.dsl.dyn.forthnet.gr) |
| 07:57.19 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 11:24.34 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 11:24.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:26.56 | oej | Afternoon |
| 11:31.35 | *** join/#asterisk-dev frawd (~francois@19.Red-81-39-176.dynamicIP.rima-tde.net) |
| 12:02.37 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:02.37 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:13.37 | *** join/#asterisk-dev frawd (~francois@19.Red-81-39-176.dynamicIP.rima-tde.net) |
| 12:20.27 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.125.71) |
| 12:27.20 | leifmadsen | morning! |
| 12:27.43 | kpfleming | only for a little while |
| 12:33.12 | wdoekes2 | kpfleming: pong |
| 14:05.20 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-qjhskubpnylrmnac) |
| 14:13.52 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-opkdcjgzrknwivlt) |
| 14:13.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:32.54 | *** join/#asterisk-dev tzafrir (~tzafrir@46-116-183-236.bb.netvision.net.il) |
| 14:32.54 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:00.46 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:00.46 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:01.00 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:01.00 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:21.47 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 15:40.10 | *** join/#asterisk-dev chazzam (~chazz@50-81-150-34.client.mchsi.com) |
| 15:56.59 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 15:57.31 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:57.31 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:16.15 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:16.16 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:20.59 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 19:22.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 19:32.52 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:32.52 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 19:37.16 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:37.16 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 19:39.23 | mjordan | Corydon76-work: ping |
| 19:43.57 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:43.57 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 19:49.06 | Corydon76-work | mjordan: pong |
| 19:49.37 | mjordan | so, post https://reviewboard.asterisk.org/r/1599/ the unit tests on trunk have been failing under bamboo |
| 19:50.01 | Corydon76-work | Which unit tests? |
| 19:50.37 | mjordan | sorry, should have clarified. The /main/stdtime/ test goes to wake up the localtime monitor, and blocks |
| 19:50.53 | mjordan | during the deletion test |
| 19:51.20 | mjordan | anyway, it only occurs when you execute the tests on a remote asterisk instance (ASTERISK-18794) |
| 19:51.26 | mjordan | whoops |
| 19:51.29 | mjordan | ASTERISK-18974 |
| 19:51.45 | Corydon76-work | Ah, then I suspect I know where the problem lies |
| 19:51.52 | mjordan | I'm not very familiar with the remote connection code, but saw that some of your verbose patch worked in that area |
| 19:52.11 | Corydon76-work | Where is the main/stdtime test code? |
| 19:52.34 | mjordan | test_time.c |
| 19:52.54 | mjordan | it should look familiar ;-) |
| 19:54.20 | Corydon76-work | Wait, how is this working with the remote connection code? |
| 19:54.40 | mjordan | that was my question, actually |
| 19:55.08 | Corydon76-work | I don't see anything that would do that |
| 19:55.51 | mjordan | me neither. The test runs fine however when run under the console |
| 19:56.27 | Corydon76-work | How is the test being executed? |
| 19:56.49 | mjordan | asterisk -rx "test execute all" |
| 19:58.19 | mjordan | although executing just the single test (asterisk -rx "test execute category /main/stdtime") will result in the same behavior |
| 20:00.32 | mjordan | you'll get the same behavior as well when not executing directly from the command line switch |
| 20:00.55 | Corydon76-work | Hang on, just re-enabled the test and recompiling |
| 20:03.58 | Corydon76-work | I am not getting a failure on that. Now, I am a few revisions behind current on trunk |
| 20:04.22 | Corydon76-work | I am at revision 346654. |
| 20:05.26 | mjordan | let me go to that revision and see what happens |
| 20:05.44 | Corydon76-work | I will try with current, and if I get the problem, then we have a set of revisions where the problem was introduced. |
| 20:07.06 | Corydon76-work | Still no issue with that revision |
| 20:07.15 | mjordan | hm |
| 20:09.08 | Corydon76-work | I just reproduced by running asterisk without a console |
| 20:09.34 | Corydon76-work | But if I run Asterisk with no console but 1 verbose, no issue |
| 20:10.35 | mjordan | interesting |
| 20:10.56 | mjordan | I hadn't tried running without a console but with any verbose |
| 20:12.41 | Corydon76-work | So it's something related to the core option_verbose == 0 |
| 20:16.02 | Corydon76-work | Oh, here's something interesting... if, at the hang, you execute 'core show locks', Asterisk segfaults |
| 20:45.32 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 20:45.32 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 20:51.25 | Corydon76-work | mjordan: I have a theory. Now to test it out. |
| 20:52.24 | mjordan | excellent |
| 20:52.50 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 21:06.13 | *** join/#asterisk-dev longshitian (~longst@c83-250-126-197.bredband.comhem.se) |
| 21:12.23 | longshitian | I would like to start working with Asterisk Development. I have been reading the site of http://www.asterisk.org/developer/resources. After that I still feel confuse where I could start. If someone would have ideas how I could start Thanks |
| 21:13.27 | pabelanger | longshitian: http://issues.asterisk.org/JIRA/ |
| 21:13.52 | pabelanger | you could find an open issue on the tracker and start working on it |
| 21:18.23 | longshitian | Good. Thanks for your help, I know we have https://wiki.asterisk.org/wiki/dashboard.action this wiki which I could read something I have to know if I am working with Asterisk. I went through this wiki, I think most of the topics are related to how to use Asterisk, but not regarding development issue. Could you please let me know if there is a "development wiki" or not. Thanks. |
| 21:20.36 | pabelanger | longshitian: https://wiki.asterisk.org/wiki/display/AST/Development is a good place to start |
| 21:20.39 | Corydon76-work | mjordan: The inotify_thread is dying in some way that I cannot see, while not resetting the inotify_thread value back to _NULL. |
| 21:26.12 | Corydon76-work | I can tell you the thread is dying, because when I attach to the process with gdb and retrieve the inotify_thread value, it does not match any of the currently executing threads. |
| 21:26.54 | mjordan | or it never got spawned for some reason |
| 21:27.19 | Corydon76-work | No, if it was never spawned, then the value would be _NULL. |
| 21:27.37 | mjordan | ah, yeah, we do initialize it to AST_PTHREADT_NULL |
| 21:27.40 | mjordan | hm. |
| 21:28.38 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 21:29.26 | longshitian | Thanks I will take a look |
| 21:30.29 | Corydon76-work | btw, the whole purpose of this inotify code is to deal with somebody overwriting /etc/localtime while Asterisk is running and expecting it to re-read the file at that point. If you can figure out a better way to do that, the code could be tossed. |
| 21:31.50 | kpfleming | that seems like at a minimum it could be optional behavior, as that use case is going to be exceedingly rare |
| 21:35.58 | Corydon76-work | I made that argument at the time, but was told it had to work |
| 21:36.30 | Corydon76-work | That if you're going to do that, you could just as easily restart Asterisk |
| 21:37.16 | Corydon76-work | Oh, weird. On another gdb, the thread exists, but it's something completely unrelated. |
| 21:38.14 | Corydon76-work | tps_processing_function |
| 21:38.52 | mjordan | the fact that the presence of a verbose flag is affecting any of this is disconcerting |
| 21:38.53 | kpfleming | i don't remember that discussion, but it probably happened a very long time ago and one or two things have occurred since then :-) |
| 21:39.21 | Corydon76-work | mjordan: Yeah, there are some weird timing issues in Asterisk sometimes |
| 21:39.52 | Corydon76-work | Had a case sometime back where if you put a printf in the middle of some code, a race condition would disappear |
| 21:40.20 | mjordan | I hate those. |
| 21:40.23 | mjordan | Heisenbugs. |
| 21:40.33 | Corydon76-work | mjordan: some of this is getting into the complexities of how threads are implemented in Linux. |
| 21:42.08 | Corydon76-work | There was one in the http code where if a thread lasted shorter than the time of a full context switch, then it was possible for pthread starting code to segfault, because it wrote into a structure that was deallocated at the end of the short-lived thread |
| 21:43.22 | Corydon76-work | When you spawn a thread, the write-back of the pthread ID to the starting process is delayed until the starting thread regains control of the processor. The started thread gets immediate control of the processor. |
| 21:44.39 | Corydon76-work | So we had to do a usleep() at the end of the started thread, so it would last long enough for the parent thread to get back that value, and write it into the structure |
| 22:06.04 | *** join/#asterisk-dev Crowb4r (u1012@gateway/web/irccloud.com/x-wayiamfvslwsvvyk) |
| 22:24.43 | mjordan | Corydon76-work: I'm going to continue to work on this and think through it over the weekend. I have a sneaky suspicion that this has something to do with forking asterisk and having the threads - which still exist in asterisk with the proper IDs - being referenced as something else in the remote process |
| 22:24.58 | mjordan | that being said, I'm not sure why a verbose flag would be affecting that still. |
| 22:26.26 | mjordan | However, if we can't figure out what's going on within a few days next week, we may have to consider backing out the patch until we figure out what's going on - having the -r option break is no bueno - and although right now its just the inotify thread, there's no promises that there aren't thread related issues that the patch may introduce |
| 22:32.41 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-opkdcjgzrknwivlt) |
| 23:10.15 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 23:20.03 | *** join/#asterisk-dev eZz (~ez@178.137.178.86) |
| 23:20.31 | eZz | hello |
| 23:20.35 | eZz | is it possible to setup a variables through pbx_builtin_setvar_helper in handle_response_invite and catch them in 's' in DumpChan ? As I see a variable is being set but can't see any in DumpChan |
| 23:53.34 | eZz | somebody can help me ? I'm knocking my head against the wall the last 4 hours... |
| 23:53.50 | eZz | I'm trying to catch a headers sent by outbound proxy on INVITE, then assign them to a variables through pbx_builtin_setvar_helper in handle_response_invite (channels/chan_sip.c) |
| 23:53.55 | eZz | But when I'm trying to fetch them with DumpChan, I can't see them... |
| 23:54.03 | eZz | What do I'm doing wrong ? |