| 00:32.42 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 00:51.34 | *** join/#asterisk-dev mjordan (~mjordan@user-24-236-95-234.knology.net) |
| 00:51.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:46.19 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 02:33.24 | *** join/#asterisk-dev mjordan (~mjordan@user-24-236-95-234.knology.net) |
| 02:33.24 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:39.06 | *** part/#asterisk-dev mjordan (~mjordan@user-24-236-95-234.knology.net) |
| 02:58.55 | opticron | lobs something fun onto reviewboard |
| 06:38.16 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 07:01.47 | *** join/#asterisk-dev oej (~olle@edifici-pub-67.adam.es) |
| 07:01.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:01.22 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:78c1:e2fd:67d3:76e3) |
| 08:11.15 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:11.15 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:43.35 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:43.45 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:09.18 | *** join/#asterisk-dev mjordan (~mjordan@user-24-236-95-234.knology.net) |
| 11:09.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:43.53 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:43.53 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:05.34 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:05.35 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:57.39 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:57.41 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:09.31 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fkioysdwfykgwbfo) |
| 13:09.31 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:20.00 | *** join/#asterisk-dev Deeewayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 13:20.01 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 13:22.18 | *** join/#asterisk-dev micols (~t@rlogin.dk) |
| 13:25.16 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 13:30.18 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-azdtulpbdnleywjt) |
| 14:16.48 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:16.48 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:29.04 | kpfleming | file: ping |
| 14:29.11 | file | kpfleming, pong |
| 14:29.50 | kpfleming | trying to answer steve davies' question on -dev... Timer B only applies in an INVITE transaction until the first response is received, correct? after that, there is no RFC-defined timer that would cause the transaction to be aborted. |
| 14:30.27 | file | right |
| 14:30.47 | kpfleming | so he's found a real problem them. lack of final response to a re-INVITE will cause a chan_sip dialog to be stuck forever. |
| 14:37.16 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:37.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:39.54 | *** join/#asterisk-dev GameGamer43 (~users.553@gateway/web/irccloud.com/x-oxidbgtdqrzxuwjp) |
| 15:27.06 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:34.15 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:34.15 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:41.18 | pabelanger | I noticed something lastnight, didn't look into it to much, but when I did a sip notify from the CLI, the sip message header had a contact address of "asterisk@127.0.1.1", I did expect to see that |
| 15:41.33 | pabelanger | not sure why it didn't use my actual IP |
| 15:42.29 | putnopvut | There may be a missing call to ast_sip_ouraddrfor() somewhere in that chain. |
| 15:44.16 | pabelanger | putnopvut: okay, I'll look more into later. Was trying to fix something else, and noticed that message fly by in the debug messages. |
| 15:46.12 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 15:58.59 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:19.45 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:b1f5:cae7:4cc9:3bda) |
| 16:51.30 | putnopvut | With regards to ASTERISK-19920, I'm a bit lost on how to proceed. I've determined that using gcc version 4.5+ results in a constructor call of ast_register_module() prior to main() that does not happen in previous versions. I don't really know of a good way of determining why that happens though. Searching release notes for gcc 4.5 as well as the gcc-help mailing list hasn't helped any. Can anyone give me a nudge as to how |
| 16:51.30 | putnopvut | <PROTECTED> |
| 16:55.53 | elguero | cd /usr/src |
| 16:55.53 | elguero | ls |
| 16:56.12 | elguero | woops... ignore me |
| 16:58.08 | otherwiseguy | putnopvut: that sounds hard. |
| 16:58.51 | rgagnon | elguero: don't you mean "cd /pub; more beer" ? |
| 16:59.41 | putnopvut | otherwiseguy: It may or may not be. I just don't know how to diagnose what's going on at this point. |
| 17:00.09 | otherwiseguy | hates any issue that starts out with "Well, on this compiler things work…" |
| 17:05.29 | elguero | rgagnon: hehe... a little too early for that |
| 17:06.04 | rgagnon | putnopvut... could this be another issue that has to do simply with the alphabetical order of the res_*.so files? res_adsi is first in the list. Maybe asterisk is attempting to load the first one? |
| 17:06.47 | rgagnon | if you rename res_adsi.so out of the way, does it load res_ael_share? |
| 17:07.01 | putnopvut | rgagnon: no, a module called "core" gets loaded isntead. |
| 17:08.07 | putnopvut | Basically, it appears that when changing gcc versions from 4.4 to 4.5, a call to the constructor __reg_module() gets called prior to Asterisk's main() function. |
| 17:08.46 | rgagnon | could it be the level of "-O" when compiling is making a bad binary? |
| 17:09.03 | putnopvut | I don't understand the question. |
| 17:10.05 | putnopvut | The one thing I've been somewhat ignoring in the issue is that Leif says that the issue occurred in Asterisk trunk. I should see if it occurs in Asterisk 1.8. If it doesn't, then I can look at Makefile changes to see if anything seems odd. |
| 17:11.35 | rgagnon | Just curious if gcc 4.5 might be buggy in its optimization on your ubuntu 12 test box... just throwing noodles at the wall here really. |
| 17:12.14 | putnopvut | Ah, gotcha. I haven't changed optimization levels from the default. I can see if DONT_OPTIMIZE changes matters any. |
| 17:13.17 | Qwell | putnopvut: stupid question - do you have anything in MENUSELECT_EMBED in menuselect.makeopts? |
| 17:13.31 | putnopvut | let's see... |
| 17:13.53 | putnopvut | Qwell: no, nothing there. |
| 17:17.28 | putnopvut | New finding. Problem occurs in 1.8 as well as trunk. |
| 17:17.51 | rgagnon | thinks that is just peachy |
| 17:18.00 | putnopvut | Trying with DONT_OPTIMIZE now |
| 17:18.20 | Qwell | might also try building with NOISY_BUILD, to see if there's anything funky between the gcc versions |
| 17:19.40 | putnopvut | While I'm certainly willing to try that, I'm not optimistic that I'll see a difference. |
| 17:20.00 | putnopvut | DONT_OPTIMIZE did not change anything. |
| 17:54.40 | kpfleming | putnopvut: here's what i suspect: the AST_MODULE_FOO() stuff has always attempted to cause what you are seeing, but due to bugs in gcc it never actually happened. now those bugs in gcc have been fixed, and the bugs in our code have been exposed. |
| 17:55.01 | kpfleming | are there any calls to AST_MODULE_<XXX> macros in main/ |
| 17:56.11 | Qwell | kpfleming: grep says no |
| 17:57.03 | kpfleming | hmm |
| 17:58.15 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 17:58.16 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 18:02.28 | jsmith | kpfleming: Fixed bugs in gcc exposing bugs in your code -- how nice! |
| 18:02.42 | kpfleming | yep |
| 18:02.52 | kpfleming | at least i suspect that is the case |
| 18:03.21 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:03.21 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:16.41 | elguero | putnopvut: main/Makefile line 34 ... just throwing that out there |
| 18:18.45 | Qwell | blinks |
| 18:19.04 | kpfleming | oh wow |
| 18:19.10 | kpfleming | that's so.... wrong |
| 18:19.35 | kpfleming | svn blame, anyone? |
| 18:20.02 | kpfleming | in that situation, res_adsi *is* actually loaded, because it got embedded into the main asterisk binary |
| 18:20.18 | Qwell | https://reviewboard.asterisk.org/r/790/ |
| 18:22.38 | mjordan | on the other hand, at least putnopvut wasn't going crazy |
| 18:22.53 | Qwell | mjordan: This doesn't prove that. |
| 18:23.45 | kpfleming | wow... that's still so broken. |
| 18:23.56 | kpfleming | why does res_adsi get this special treatment but other modules don't? |
| 18:24.01 | kpfleming | i bet this all works fine with that removed |
| 18:24.17 | kpfleming | Corydon76-home: do you have any recollection of why that change in review 790 to main/Makefile was necessary? |
| 18:26.55 | Corydon76-home | Yes, the original code was designed to run only for OS X, but the compiler test was passing on CentOS, so we changed the test so it would fail on CentOS |
| 18:27.16 | kpfleming | no, we're talking about the forced linking of res_adsi.o into the main asterisk binary |
| 18:27.49 | Corydon76-home | Ah, yes, that was the compiler bug in gcc 4.1 |
| 18:28.48 | Corydon76-home | I think we changed the way the compile worked later to negate that necessity, but I'd have to do a lot more looking to be sure |
| 18:28.49 | kpfleming | then i wonder why this is getting triggered on Ubuntu 12.04 using gcc 4.4/4.5/4.6 |
| 18:29.03 | Qwell | kpfleming: not 4.4 |
| 18:29.09 | kpfleming | yeah, we really can't forcibly link in res_adsi.o like that |
| 18:29.11 | kpfleming | that's just wrong |
| 18:29.31 | kpfleming | so for now that needs to be removed, and we can deal with any resulting effects when they crop up |
| 18:31.08 | mvanbaak | svn rm res_adsi.c |
| 18:31.11 | mvanbaak | \o/ |
| 18:31.35 | Qwell | CentOS also no longer ships 4.1.1 |
| 18:31.47 | Corydon76-home | What about 4.1.2? |
| 18:31.58 | Qwell | 4.1.2, yes. I thought that's where the fix was? |
| 18:32.07 | Corydon76-home | Nope, the fix was in 4.2.1 |
| 18:32.17 | Qwell | oh. r276731 says 4.1.2 |
| 18:33.07 | Corydon76-home | All of gcc 4.1 was completely broken for weak symbols |
| 18:33.54 | kpfleming | putnopvut: go ahead and remove the forced linking of res_adsi.o as the fix for your issue in JIRA. |
| 18:34.03 | jsmith | kpfleming: Would it be helpful for me to try anything on GCC 4.7? |
| 18:34.15 | kpfleming | no, i don't think so |
| 18:34.50 | kpfleming | i still don't understand why putnopvut is seeing this happen on gcc 4.5 and 4.6, but removing it will make that stop in any case |
| 18:39.35 | Qwell | I think I can answer that |
| 18:40.09 | Qwell | $(WEAKREF) may contain 1:1 (or something) in 4.5+ for some reason. On my 4.4 box, it contains just 1. |
| 18:40.14 | Qwell | ifneq ($(firstword $(subst :, ,$(WEAKREF))),1) |
| 18:40.23 | Qwell | that may be wonky |
| 18:40.39 | kpfleming | but that logic attempts to take that into account |
| 18:43.45 | Qwell | but 1:1 would become 11, and it's an ifneq. GNU Make is kinda magic though, so I could be reading it entirely wrong. |
| 18:43.59 | kpfleming | no, it would become '1 1' |
| 18:44.05 | kpfleming | the : is replaced with a space |
| 18:44.19 | Qwell | ahh |
| 18:49.06 | putnopvut | Just got back from lunch. Thanks for the help! |
| 18:50.01 | kpfleming | putnopvut: clearly, you should go to lunch more often |
| 18:51.24 | putnopvut | yeah, maybe I'll go for a second one right now and see if any of my other issues get resolved :) |
| 18:57.34 | putnopvut | And removing that offending line from the Makefile causes the issue to go away. Thanks! |
| 18:57.48 | kpfleming | might as well remove the conditional logic around it too |
| 18:57.51 | kpfleming | since it will be empty now |
| 18:57.58 | putnopvut | Sure t'ing |
| 20:28.59 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:28.59 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 20:56.13 | kpfleming | mjordan: weak symbols, not weak attributes :-) |
| 20:56.37 | kpfleming | putnopvut: also, that wasn't a phantom res_adsi, it was in fact really loaded, just not loaded from disk as a loadable module (it was embedded into the asterisk binary instead) |
| 20:59.49 | putnopvut | kpfleming: the weird thing was that even if res_adsi.c was not compiled, then a module called "core" would be listed as loaded. |
| 21:00.03 | putnopvut | I'm not sure what leads to that bit of oddness. |
| 21:00.06 | kpfleming | i think that's normal, actually |
| 21:00.11 | kpfleming | but i don't remember why |
| 21:00.29 | mjordan | kpfleming: will update |
| 21:00.31 | kpfleming | note the -DAST_MODULE=\"core\" in main/Makefile... |
| 21:07.49 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-xvlrooxscotymhbf) |
| 21:19.38 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 21:19.39 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 21:20.05 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:20.05 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 22:33.01 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fkioysdwfykgwbfo) |