| 00:18.04 | *** join/#asterisk-dev kazaa_lite (~eddie@cpc6-slam5-2-0-cust171.2-4.cable.virginmedia.com) |
| 00:18.50 | *** join/#asterisk-dev jmls (~jmls@212.183.140.35) |
| 00:22.06 | *** join/#asterisk-dev xpot-mobile (~xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 00:23.03 | kazaa_lite | how to download asterisk trunk? |
| 00:23.26 | kazaa_lite | svn? |
| 00:23.52 | kazaa_lite | can i specify specific trunk version? |
| 00:24.46 | jsmith | svn co http://svn.digium.com/svn/asterisk/trunk |
| 00:25.35 | kazaa_lite | thnx |
| 00:28.35 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 01:25.48 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 02:17.38 | *** join/#asterisk-dev nix8n82 (~AndChat@63.162.27.14) |
| 02:34.35 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 02:34.35 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 02:35.19 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-1177754737.dsl.bell.ca) |
| 02:42.32 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 03:07.28 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 03:46.44 | *** join/#asterisk-dev nix8n82 (~AndChat@63.162.27.14) |
| 03:52.41 | *** join/#asterisk-dev marv (~Tim@c-68-62-174-138.hsd1.al.comcast.net) |
| 04:33.56 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 04:43.39 | *** join/#asterisk-dev datachomper (~Adium@207.98.189.248) |
| 04:48.57 | *** part/#asterisk-dev datachomper (~Adium@207.98.189.248) |
| 05:19.56 | *** join/#asterisk-dev nix8n82 (~AndChat@63.162.27.14) |
| 06:01.25 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 06:01.26 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 06:35.39 | russellb | kpfleming: ohai |
| 06:35.58 | kpfleming | hi! |
| 06:36.00 | kpfleming | wifi works goodly |
| 06:36.18 | russellb | it works, at least |
| 06:36.27 | russellb | my package update downloads are going pretty slow :-) |
| 06:36.27 | kpfleming | post-plane ride commits FTW |
| 06:36.32 | russellb | kpfleming: indeed |
| 06:36.37 | kpfleming | i haven't tried anything like that |
| 06:36.53 | russellb | I basically owned main/cdr.c on my last 2 flights |
| 06:37.30 | russellb | because dropping CDR records is bad, mmmkay? |
| 06:40.10 | kpfleming | yep |
| 06:41.02 | russellb | this hotel smells funny to me |
| 06:41.15 | russellb | or at least it did to me at first |
| 06:42.26 | kpfleming | i haven't noticed anything |
| 06:42.29 | kpfleming | what room are you in? |
| 06:43.57 | russellb | 282 |
| 06:45.28 | russellb | looks suspiciously around at the other people in this room |
| 06:45.34 | russellb | at least nobody knows what hotel ^_^ |
| 06:47.15 | kpfleming | i'm right next door in 280 |
| 06:48.59 | snuff-work | finds it hard to stalk from 16k km away |
| 06:49.26 | russellb | kpfleming: nice. |
| 06:51.21 | kpfleming | we are somewhat closer to aussie land than we were twelve hours ago |
| 06:51.27 | russellb | this is true |
| 06:51.33 | russellb | I really want to visit AU ... |
| 06:51.51 | russellb | There needs to be an Asterisk Down Under conference |
| 06:53.20 | russellb | snuff-home: you should work on that :-p |
| 06:54.13 | snuff-work | mmm.. me and wedhorn are separated by about 700km.. |
| 06:54.27 | russellb | so basically right next to each other |
| 06:54.41 | snuff-work | heh.. if a 2hr flight counts :) |
| 06:57.53 | russellb | so, there is a guy in #asterisk right now talking about a problem he is having ... his nick is "themolester" |
| 06:57.59 | russellb | it is really hard to take him seriously with that name, heh |
| 06:59.24 | snuff-work | heh. |
| 07:08.14 | kpfleming | russellb: sleepy time... |
| 07:12.44 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:12.44 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:53.19 | *** join/#asterisk-dev fiddur (~fiddur@192.121.104.121) |
| 07:55.04 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 08:44.28 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 09:07.26 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-58-169-81-65.lns1.bat.bigpond.net.au) |
| 10:58.32 | *** join/#asterisk-dev sgimeno (~chatzilla@226.Red-80-33-64.staticIP.rima-tde.net) |
| 11:25.41 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 12:13.49 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:44.21 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 12:44.21 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 13:31.55 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 14:07.48 | *** join/#asterisk-dev mbranca (~matteo@host139-217-static.224-95-b.business.telecomitalia.it) |
| 14:12.31 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:12.32 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:15.02 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:15.02 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:57.05 | *** join/#asterisk-dev moy (~chatzilla@74.12.129.100) |
| 15:00.18 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:00.18 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:21.07 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 15:21.07 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:30.48 | *** join/#asterisk-dev sgimeno (~chatzilla@226.Red-80-33-64.staticIP.rima-tde.net) |
| 15:50.09 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 15:51.05 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 15:56.06 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:56.06 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:58.15 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:59.28 | *** join/#asterisk-dev mog (~mog@c-71-228-185-24.hsd1.al.comcast.net) |
| 15:59.28 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 16:01.17 | *** join/#asterisk-dev CunningPike (~CunningPi@S01060014bf81366b.vc.shawcable.net) |
| 16:04.23 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:04.23 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:05.35 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:05.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:09.20 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 16:09.20 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 16:12.54 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 16:29.05 | *** join/#asterisk-dev paulc (~paulc@unaffiliated/paulc) |
| 17:03.01 | *** join/#asterisk-dev Omorika (~omorika@193.198.31.85) |
| 17:03.03 | Omorika | chan_iax2.c: Received trunked frame before first full voice frame |
| 17:03.08 | Omorika | what does that mean? |
| 17:03.18 | Omorika | my log is full of this message? |
| 17:13.42 | *** join/#asterisk-dev Victor_Yure_ (~victor@unaffiliated/victoryure/x-837844) |
| 17:13.55 | *** part/#asterisk-dev Omorika (~omorika@193.198.31.85) |
| 17:17.42 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-1177754737.dsl.bell.ca) |
| 17:18.25 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:23.07 | putnopvut | I'm writing a set of ACL unit tests. The first one I am writing is a simple one where we feed a garbage IP address/netmask as an access rule, such as "DINOSAUR/24" . One of my "bogus" rules was for the string "33.4/10". My thinking was that the IP address 33.4 should be recognized as invalid. However, it is not. Further investigation shows that this IP address is validated using inet_aton, not a built-in Asterisk function, |
| 17:23.07 | putnopvut | <PROTECTED> |
| 17:25.02 | atis_work | putnopvut: that could make perfectly valid local hostname |
| 17:25.23 | putnopvut | atis_work: hostnames are not allowed in this situation, just dotted-decimal IPv4 addresses. |
| 17:25.34 | atis_work | ah.. |
| 17:26.13 | atis_work | for me it's 33.0.0.4 |
| 17:26.32 | atis_work | actually a cool way how to write 127.0.0.1 |
| 17:26.35 | atis_work | just 127.1 |
| 17:26.48 | seanbright | there is nothing cool about that |
| 17:26.50 | seanbright | :P |
| 17:26.51 | atis_work | works in ping |
| 17:34.12 | putnopvut | atis_work: interesting. at least in your case, the resulting IP address makes some amount of sense... |
| 17:34.47 | Corydon76-dig | Apparently, it works on BSD, too |
| 17:36.07 | atis_work | putnopvut: your case makes sense too, 33.0.0.4/10 is 33.0.0.0 |
| 17:36.19 | atis_work | with some of the complex mask stuff.. |
| 17:36.23 | atis_work | beginning of range |
| 17:36.51 | putnopvut | atis_work: ah, you're right! |
| 17:36.56 | putnopvut | Now I see. |
| 17:37.07 | putnopvut | ha->netaddr.s_addr &= ha->netmask.s_addr; |
| 17:37.15 | putnopvut | That's what causes that issue to happen... |
| 17:37.49 | putnopvut | The simple answer is that I need to remove that case from my test. |
| 17:38.25 | putnopvut | atis_work: thanks! |
| 17:38.31 | atis_work | hah, collegue says it works on windows too |
| 17:38.47 | Corydon76-dig | Aha... manpage for inet_aton on BSD is enlightening |
| 17:38.52 | atis_work | you're welcome :) |
| 17:39.23 | Corydon76-dig | The reason for it is to make Class A, B, and C network addresses easily writable |
| 17:39.31 | Corydon76-dig | in shorthand |
| 17:40.43 | Corydon76-dig | 2-part for Class A, 3-part for Class B, 4-part for Class C. And 1-part can be used as the integer form of the entire address |
| 17:42.01 | Corydon76-dig | My gateway can be written as 192.168.17665 |
| 17:54.51 | *** join/#asterisk-dev jmls (~jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 17:56.38 | atis_work | ah, so you can use 2130706433 instead of localhost :D |
| 17:58.39 | atis_work | hah, apache doesn't understand http://3232235615/ |
| 18:01.04 | atis_work | i should open bugreport against apache httpd :D |
| 18:01.19 | atis_work | everything else undestands that perfectly |
| 18:21.11 | Corydon76-dig | atis_work: probably because you have virtual hosts on, and that string doesn't match |
| 18:25.44 | atis_work | well, no i access it by ip |
| 18:31.15 | *** join/#asterisk-dev niekvlessert (~niek@5ED25657.cable.ziggo.nl) |
| 18:32.49 | *** join/#asterisk-dev m_c_le (~marcello@2001:470:1f0b:d4b:2e0:4dff:fe6c:9372) |
| 18:33.03 | *** join/#asterisk-dev |Rain| (~rain@ev.il.net) |
| 18:34.01 | |Rain| | is the timestamp in an IAX packet in any particular unit, or is it just an arbitrary monotonic number? |
| 18:34.57 | seanbright | acl documentation? HA HA HA |
| 18:36.40 | |Rain| | looks like it's in milliseconds |
| 18:38.03 | Corydon76-dig | Are you talking about mini frames or full frames? |
| 18:38.13 | |Rain| | full frames |
| 18:38.48 | Corydon76-dig | Mini frames might as well be arbitrary, because the most significant digits are missing |
| 18:39.18 | |Rain| | I'm trying to figure out why/how this host (asterisk 1.4) sometimes sends duplicate TXREQs (with different TRANSFERID IEs), although I already know that there's badness on the receiving end when the duplicates are received |
| 18:41.31 | |Rain| | on the receiving end, when there are two TXRQs for the same call, that call gets added to iax_transfercallno_pvts twice, but it's only removed once -- which ultimately causes a future call with the same callid to be rejected and dropped with IAX_COMMAND_INVAL |
| 18:41.51 | Corydon76-dig | Have you read the IAX2 RFC? |
| 18:42.45 | |Rain| | I have not, but I have been digging through the source and looking at packet captures |
| 18:43.02 | Corydon76-dig | RFC 5456 |
| 18:44.19 | |Rain| | after looking at the code, I don't see how the duplicate TXREQs are actually being sent (there's minimal safeguarding in chan_iax to prevent it) unless both the iaxs structs point to the same host (which wouldn't make sense, based on the IPs in the TXREQ packet) |
| 18:44.59 | Corydon76-dig | RFC section 8.6.28 specifies that the header timestamp starts at 0 for each call |
| 18:45.58 | Corydon76-dig | Well, if the TXREQ isn't ACKed before the retransmit timeout, then TXREQ would be re-transmitted |
| 18:46.35 | |Rain| | Based on your search of [5456] in the All Fields field zero matches were made. |
| 18:46.50 | |Rain| | Corydon76-dig: it's not flagged as a retransmit, and it occurs just a few milliseconds after the first |
| 18:47.14 | Corydon76-dig | Well, there's 2 TXREQs sent, one to each host |
| 18:47.25 | Corydon76-dig | See section 9.5 |
| 18:49.03 | |Rain| | right, I see that from the source (I can't find the RFC in the standard places), but these are both being sent to the same host, which doesn't make sense since one leg of the call is definitely on a different host |
| 18:49.06 | Corydon76-dig | Oh, the other possibility for a new TXREQ is if the original TXREQ did not contain the correct calltoken |
| 18:49.27 | |Rain| | there are no calltokens (sending version of asterisk is too old) |
| 18:49.29 | Corydon76-dig | That would explain a nearly immediate duplicate |
| 18:50.05 | Corydon76-dig | Oh, you're using an ancient version. Well, then, could have been a bug that has already been fixed |
| 18:50.09 | putnopvut | Someone needs to clear something up for me real quick. Are deny=0.0.0.0/0.0.0.0 and deny=0.0.0.0/0 the same thing? |
| 18:50.20 | Corydon76-dig | putnopvut: yes |
| 18:50.32 | putnopvut | Sounds like I've found a bug in the ol' ACL code then. |
| 18:50.46 | putnopvut | The ACL code is interpretting /0 as 255.255.255.255 |
| 18:50.56 | Corydon76-dig | Hah |
| 18:50.59 | |Rain| | Corydon76-dig: could be. it just doesn't make sense from the code... but the fix on the receiving end is the same regardless of the cause, so I'm not gonna worry about it too much |
| 18:51.05 | putnopvut | Corydon76-dig: thanks |
| 18:51.06 | Corydon76-dig | is it using atoi instead of sscanf? |
| 18:51.20 | putnopvut | It's using sscanf, it's the calculation afterwards that is incorrect. |
| 18:51.35 | putnopvut | It subtracts the number from 32 and then bitwise ands that with all ones. |
| 18:51.49 | putnopvut | I need to see if /32 gets interpreted as 0.0.0.0 now... |
| 18:52.12 | Corydon76-dig | Wow, you're right; that's broken |
| 18:52.42 | putnopvut | Other CIDR values appear to be interpreted correctly that way, but 0 is definitely broken. |
| 18:53.27 | Corydon76-dig | I wonder if people would ever really do that, or if they would just write "all" |
| 18:53.38 | Corydon76-dig | Corner case |
| 18:54.28 | putnopvut | I don't think you can use "all" with permit and deny, only with allow and disallow. I'm not 100% sure of that though. Let me double-check. |
| 18:55.24 | putnopvut | Yeah, I don't think "all" can be used on a permit or deny line. |
| 18:55.53 | Corydon76-dig | Yeah, appears not |
| 18:56.25 | putnopvut | So the problem appears to be that setting /0 will result in a shift of 32-bits, which apparently on my system anyway results in all ones instead of all zeroes. |
| 18:56.32 | putnopvut | a left shift, to be exact. |
| 18:56.55 | putnopvut | I think I will special case 0 here since that's the only one that would have the problem. |
| 18:57.26 | Corydon76-dig | putnopvut: see swdev |
| 18:59.48 | seanbright | bah |
| 18:59.54 | seanbright | you guys and your secrets |
| 19:01.14 | file | I have no secrets, except that I have secrets. |
| 19:02.24 | seanbright | i won't tell anyone |
| 19:02.30 | seanbright | except for everyone |
| 19:02.43 | file | okay! my secret is... I had yogurt this morning |
| 19:03.09 | Corydon76-dig | "Oh, it ain't going in that end, Mr. Lightbody" |
| 19:05.22 | Corydon76-dig | http://www.imdb.com/character/ch0022169/quotes |
| 19:13.40 | *** join/#asterisk-dev ecrane (~ecrane@o1-69-19-166-10.static.o1.com) |
| 19:17.12 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 19:23.05 | atis_work | file: you just contradicted yourself.. if you just told us that "you have secrets" which was your secret, then it isn't secret anymore |
| 19:23.17 | file | or do I? |
| 19:23.39 | file | runs off for a bit |
| 19:23.50 | atis_work | goes to sleep |
| 19:23.59 | atis_work | ah, i first have to get home |
| 19:24.36 | *** join/#asterisk-dev niekvlessert (~niek@5ED25657.cable.ziggo.nl) |
| 19:44.56 | |Rain| | is there a guideline for severity selection on the bug tracker? |
| 19:45.02 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 20:04.33 | Corydon76-dig | Don't use block, and unless you feel that it affects a large number of people and is a critical problem, don't use major. |
| 20:05.19 | Corydon76-dig | Text for documentation, Feature for features, Trivial if you have a fix that's 3 lines or less |
| 20:05.25 | Corydon76-dig | Otherwise, Minor |
| 20:17.11 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 20:17.47 | |Rain| | I was considering major for a bug that causes innocent IAX2 calls to be rejected with INVAL, but leaning strongly towards minor. I do wonder how often this happens for sites with lots of IAX calls, though. |
| 20:18.01 | |Rain| | "critical" problems aren't very well defined, either :) |
| 20:23.53 | Corydon76-dig | Use your best judgement |
| 20:34.02 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 20:34.05 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 20:52.38 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 20:52.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:11.59 | *** join/#asterisk-dev ctooley (~ctooley@c-98-193-232-154.hsd1.tn.comcast.net) |
| 21:11.59 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 21:59.00 | jsmith | Corydon76-dig: While you're busy correcting ANSI color codes, mind making another fix for me? |
| 22:01.45 | putnopvut | I'm facing an annoying issue in the CCSS branch. chan_sip will not load because of the following error: |
| 22:01.51 | putnopvut | .[Feb 24 16:03:01] WARNING[9917]: loader.c:428 load_dynamic_module: Error loading module 'chan_sip.so': /usr/lib/asterisk/modules/chan_sip.so: undefined symbol: _ast_strdup |
| 22:02.09 | putnopvut | I looked in the chan_sip.i file and could not find any reference to _ast_strdup |
| 22:02.18 | putnopvut | I'm at a loss as to how to go about debugging this. |
| 22:02.32 | putnopvut | Note that this problem does not happen in Asterisk trunk, just CCSS> |
| 22:02.38 | *** join/#asterisk-dev ArtemMakhutov (~ArtemMakh@ip-95-223-6-41.unitymediagroup.de) |
| 22:02.55 | putnopvut | I suppose what I'll do next is back off chan_sip commits until it loads properly and find which revision caused the module not to load anymore. |
| 22:03.12 | putnopvut | If anyone has any better suggestions, please let me know. |
| 22:03.44 | Corydon76-dig | jsmith: Mmm, what? |
| 22:05.08 | Corydon76-dig | putnopvut: try toggling MALLOC_DEBUG in Compiler Options |
| 22:06.35 | putnopvut | Corydon76-dig: I'll give that a shot. |
| 22:06.47 | Corydon76-dig | putnopvut: the problem is in channels/sip/reqresp_parser.c |
| 22:07.52 | Corydon76-dig | Or maybe not |
| 22:08.08 | jsmith | Corydon76-dig: In trunk, if I do something like "core show application foo", after the application help is displayed, the prompt becomes light gray on a white background, making it almost impossible to read. |
| 22:08.11 | Corydon76-dig | Yep, almost certainly |
| 22:08.18 | *** join/#asterisk-dev codefreeze-lap (~murf@mail.parsetree.com) |
| 22:08.18 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 22:08.27 | putnopvut | I had MALLOC_DEBUG enabled in CCSS but not in trunk. I'm enabling it in trunk now and compiling. Going to see how that affects things. |
| 22:08.35 | Corydon76-dig | jsmith: use the -W option at boot |
| 22:09.40 | jsmith | Corydon76-dig: I realize what the -W option is for... but shouldn't it return the prompt to the previous color? |
| 22:10.27 | Corydon76-dig | jsmith: it cannot detect what color the previous prompt was |
| 22:11.01 | Corydon76-dig | It can set a color... but it cannot detect what the present color is |
| 22:13.32 | Corydon76-dig | If you want me to look more closely at that, file an AST issue in Jira |
| 22:14.27 | jsmith | Will do |
| 22:14.28 | jsmith | Thanks |
| 22:15.30 | putnopvut | Preliminary report: enabling MALLOC_DEBUG in trunk did not cause the problem to appear there. disabling MALLOC_DEBUG in CCSS did make chan_sip load properly there. weird |
| 22:17.02 | putnopvut | The other option I had enabled in CCSS but not in trunk was DONT_OPTIMIZE. I'm going to see if enabling that in trunk has any negative effect. |
| 22:18.41 | snuff-work | i didn't think malloc_debug without dont optimise would work so well? |
| 22:20.43 | Corydon76-dig | putnopvut: I wouldn't be surprised if you reenabled it in CCSS and you couldn't get the problem to reoccur. Chalk it up to build weirdness and/or time skew |
| 22:21.01 | putnopvut | Corydon76-dig: Nope, I've already tried that and it's pretty consistent. |
| 22:21.09 | Corydon76-dig | Odd |
| 22:21.31 | putnopvut | Yeah, and enabling both MALLOC_DEBUG and DONT_OPTIMIZE in trunk did not make the problem occur there. |
| 22:21.46 | putnopvut | So now to find other differences... |
| 22:23.26 | putnopvut | I do think it is probably build weirdness. I'm going to try the good old make distclean approach and see if that fixes things up. |
| 22:25.02 | Corydon76-dig | Only other thing I can think of is that you might be inadvertently redefining an already-used constant in your branch |
| 22:28.07 | putnopvut | make distclean didn't fix the problem. |
| 22:28.18 | putnopvut | Corydon76-dig: I suppose that's possible. This is a pretty recent problem though. |
| 22:41.39 | Corydon76-dig | putnopvut: Found it |
| 22:42.14 | Corydon76-dig | DONT_OPTIMIZE is the key. distclean kills the .o files in channels/sip/, but doesn't kill the .i files |
| 22:43.53 | putnopvut | Interesting. So with the proper amount of experimentation I would eventually also have the problem in trunk. |
| 22:44.20 | putnopvut | So the fix is to have clean and distclean kill the .i files in channels/sip? |
| 22:45.05 | Corydon76-dig | Correct |
| 22:45.25 | Corydon76-dig | merge 248667 from trunk, and I'll bet a 'make clean' fixes the problem |
| 22:50.25 | putnopvut | Well, unfortunately I already made that fix manually. But thanks for finding the source of the problem. |
| 22:53.23 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 22:53.23 | *** join/#asterisk-dev jmls (~jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 22:53.23 | *** join/#asterisk-dev mnt_real (~sinan@bas1-montreal43-1177754737.dsl.bell.ca) |
| 22:53.23 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 22:53.23 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 22:53.23 | *** join/#asterisk-dev moy (~chatzilla@74.12.129.100) |
| 22:53.23 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 22:53.23 | *** mode/#asterisk-dev [+oo tzafrir seanbright] by anthony.freenode.net |
| 22:53.26 | *** join/#asterisk-dev 14WAAAGUB (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 22:53.26 | *** mode/#asterisk-dev [+o 14WAAAGUB] by ChanServ |
| 23:28.49 | *** part/#asterisk-dev ArtemMakhutov (~ArtemMakh@ip-95-223-6-41.unitymediagroup.de) |
| 23:46.09 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 23:46.09 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |