| 01:54.58 | *** join/#asterisk-dev rrb3942 (~rbullock@cpe-67-242-215-62.rochester.res.rr.com) |
| 04:20.30 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-116-81.ptld.qwest.net) |
| 04:50.16 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:50.16 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:26.50 | *** join/#asterisk-dev luckman212 (~quassel@pool-173-77-253-145.nycmny.fios.verizon.net) |
| 06:47.24 | *** part/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 07:44.49 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 07:44.49 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 07:45.01 | *** part/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 07:58.10 | *** join/#asterisk-dev lftsy (~lftsy@install.deckpoint.ch) |
| 08:02.46 | *** join/#asterisk-dev schmidts (~schmidts@86.59.126.42) |
| 08:02.48 | schmidts | good morning |
| 08:15.11 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:21b:63ff:feb5:e13b) |
| 08:16.01 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:19.29 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:19.29 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:34.30 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 08:34.30 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 08:35.52 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 08:35.52 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 09:43.20 | *** join/#asterisk-dev ccesario (~ccesario@189-29-54-68-ac.cpe.vivax.com.br) |
| 10:42.21 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 12:41.50 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 12:59.22 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 13:02.14 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:02.14 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:07.24 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 14:29.02 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:29.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:35.31 | *** join/#asterisk-dev russellb_ (~russell@asterisk/digium-open-source-team-lead/russellb) |
| 14:35.31 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 14:43.36 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 14:43.37 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 14:48.11 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 15:07.47 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:07.47 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:30.14 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:30.14 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:51.04 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:51.45 | *** join/#asterisk-dev elguero (~miguel323@dsl092-072-112.bos1.dsl.speakeasy.net) |
| 15:54.19 | sruffell | tzafrir_laptop: are you waiting for me to check the next part of merge_byname or should I move on and export the dahdi_device to sysfs? |
| 15:54.52 | tzafrir_laptop | yes |
| 15:55.11 | sruffell | export the devices...and all the span registration magic as it is currently? |
| 15:55.26 | sruffell | (or in other words, I wasn't sure what yes was referring to) |
| 16:11.42 | tzafrir_laptop | the device information in sysfs is a start, I guess |
| 16:11.53 | tzafrir_laptop | How are spans to be represented? |
| 16:12.23 | tzafrir_laptop | Another point: Where should all the udev scriptary reside? tools? linux? |
| 16:16.04 | sruffell | I'm thinking that next I won't even worry about how spans are represented, only that the devices can be used to control their numbering / order. I believe the representation is more a function of the merge_byname. |
| 16:16.24 | sruffell | and....yes...I think the scripts are going to have to be in tools...since that is where the configs are installed. |
| 16:16.40 | sruffell | even though, as you pointed out, that is linux specific. |
| 16:22.07 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 16:29.04 | tzafrir_laptop | yeah, but when it will depend on changes in tools (dahdi_cfg, init script, whatever) you'll have fun |
| 16:29.07 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:29.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:29.46 | sruffell | where do you think the udev scripts should go? |
| 16:45.52 | seanbright | Corydon76-home: ping |
| 16:47.27 | tzafrir_laptop | I believe all the udev stuff belongs in tools. |
| 16:47.38 | tzafrir_laptop | But I'll wait for a good example to show up |
| 16:47.57 | tzafrir_laptop | (the dahdi-perl modules is one such example, though) |
| 16:52.50 | sruffell | ok..cool. I think we're on the same sheet there. |
| 17:06.01 | seanbright | so... mmap |
| 17:06.08 | seanbright | who's an expert? |
| 17:26.51 | sruffell | seanbright: what is your question? I don't claim to be an expert....but I'll tell you if I know anything off the top of my head. |
| 17:27.18 | seanbright | http://svnview.digium.com/svn/asterisk/trunk/main/manager.c?r1=277814&r2=278024 |
| 17:28.01 | seanbright | basically... if the underlying file has X bytes, and you pass X + 1 to mmap it will success, but accessing the memory at X + 1 will result in undefined behavior |
| 17:28.56 | sruffell | I think ftell is reporting the last position...it's 0 based. |
| 17:29.05 | sruffell | so x + 1 is the number of bytes. |
| 17:29.15 | sruffell | wait.. |
| 17:29.19 | seanbright | ftell will be at EOF |
| 17:29.49 | seanbright | so it should be the number of bytes |
| 17:32.03 | sruffell | Why then are X + 1 bytes being mapped? |
| 17:32.21 | seanbright | i think the intent is so that it can be null terminated |
| 17:32.43 | seanbright | but just mapping an extra byte won't increase the size of the underlying file |
| 17:33.20 | seanbright | i think the original approach (the fprintf) would work |
| 17:33.42 | Qwell | huh |
| 17:33.44 | seanbright | but i am 84.7% sure that you would need an fflush(f) after the fprintf to ensure it works |
| 17:33.47 | Qwell | I was just looking at that commit yesterday |
| 17:34.24 | seanbright | it's related to 17747 |
| 17:34.25 | Qwell | seanbright: wanna see something even weirder, that we couldn't explain? |
| 17:34.33 | seanbright | Qwell: the value of x? |
| 17:34.48 | Qwell | http://svnview.digium.com/svn/asterisk/branches/1.4/main/manager.c?r1=277814&r2=278023 |
| 17:35.05 | Qwell | specifically, the difference between 1.4/trunk on line 2924 |
| 17:35.17 | Qwell | the MAP_SHARED bit |
| 17:35.20 | seanbright | yeah |
| 17:35.22 | seanbright | weird |
| 17:35.44 | seanbright | Qwell: more weirdness (i think...) |
| 17:35.48 | Qwell | we were looking at it for that reason |
| 17:35.55 | seanbright | M17747 |
| 17:35.57 | Qwell | it b0rks the AA50 |
| 17:35.58 | MuffinMan | [ready for review] [Asterisk] Core/ManagerInterface 0017747: [patch] Asterisk crashes every less than 1 hours (arrount 20 mn) when using manager and http manager using asterisk-1.4.35-rc1 reported by hoby https://issues.asterisk.org/view.php?id=17747 |
| 17:36.03 | seanbright | take a look at backtrace_1.6.2.14-rc1.txt |
| 17:36.18 | seanbright | and then look at tags/1.6.2.14/main/manager.c |
| 17:36.28 | seanbright | and tell me how x becomes 16385 in that backtrace |
| 17:36.31 | Qwell | what am I looking at? |
| 17:36.33 | sruffell | Probably borks the AA50 because there is no MMU...and mmap wants to map entire pages. |
| 17:36.52 | Qwell | sruffell: exactly |
| 17:38.32 | seanbright | i don't grok that, but i'm sure you're right |
| 17:38.33 | seanbright | :-) |
| 17:39.04 | Qwell | so, what's the suggestion? |
| 17:39.38 | sruffell | looks like to use fprintf instead of trying to write to bytes at the end of the mapping? |
| 17:39.45 | seanbright | i think an fflush after the fprintf |
| 17:39.48 | seanbright | fflush(f); |
| 17:40.02 | seanbright | i have a test case... hold |
| 17:40.14 | Qwell | I think the mmap() in auth_http_callback() is also questionable, fwiw |
| 17:42.45 | seanbright | agreed |
| 17:43.00 | Qwell | That one wasn't addressed by that issue. |
| 17:43.49 | seanbright | hmmm, i'm wrong |
| 17:44.02 | seanbright | so if you fprintf(s.f, ...) |
| 17:44.13 | seanbright | and then use lseek(s.fd |
| 17:44.28 | Qwell | Unfortunately, philly cheese steak > mmap(), so bbl. |
| 17:44.36 | seanbright | without the fflush, the fd is "behind" and doesn't have the trailing null |
| 17:45.04 | seanbright | but with ftell it appears to be ok... so i don't know what the fix is |
| 17:45.11 | seanbright | the original code should be fine |
| 17:45.32 | seanbright | so the fix for M16506 must be different |
| 17:45.36 | MuffinMan | [closed] [Asterisk] Core/ManagerInterface 0016506: [patch] Segmentation fault using manager http MXML reported by nik600 https://issues.asterisk.org/view.php?id=16506 |
| 17:48.43 | seanbright | moral: if l ends up being a multiple of the page size, the current code will always SIGBUS at buf[l] = 0; |
| 17:49.05 | seanbright | because the underlying file is only l bytes, not l + 1 bytes |
| 17:49.18 | russellb | fancy |
| 17:49.54 | file | are you calling me fat? |
| 17:49.56 | russellb | yup |
| 17:50.07 | file | oh, okay |
| 17:51.09 | jsmith | file: Sometimes the truth hurts! |
| 17:51.43 | file | in this case it did not |
| 18:26.53 | *** join/#asterisk-dev frawd (~francois@127.Red-83-41-39.dynamicIP.rima-tde.net) |
| 18:34.35 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:34.35 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:26.35 | Qwell | seanbright: Would you agree that the MAP_SHARED thing is unrelated to the intent of that patch? |
| 19:26.56 | Qwell | if so, I am going to revert just that, and we can figure the rest out elsewhere |
| 19:27.28 | seanbright | Qwell: yes |
| 19:27.36 | seanbright | nothing else should be mapping that file |
| 19:29.06 | Qwell | and what exactly is the problem you're having? some crash or something? |
| 19:32.02 | seanbright | i am not having any problem |
| 19:32.08 | Qwell | M17747 ? |
| 19:32.10 | seanbright | i am trying to fix M0017747 |
| 19:32.12 | MuffinMan | [ready for review] [Asterisk] Core/ManagerInterface 0017747: [patch] Asterisk crashes every less than 1 hours (arrount 20 mn) when using manager and http manager using asterisk-1.4.35-rc1 reported by hoby https://issues.asterisk.org/view.php?id=17747 |
| 19:32.12 | MuffinMan | [ready for review] [Asterisk] Core/ManagerInterface 0017747: [patch] Asterisk crashes every less than 1 hours (arrount 20 mn) when using manager and http manager using asterisk-1.4.35-rc1 reported by hoby https://issues.asterisk.org/view.php?id=0017747 |
| 19:32.26 | seanbright | they are complaining of a segfault |
| 19:32.37 | Qwell | I see |
| 19:32.41 | seanbright | but this problem would manifest as a SIGBUS |
| 19:33.32 | seanbright | and there are some things about the backtrace in 17747 that are confusing to me |
| 19:33.52 | seanbright | specifically the value of x in the 1.6.2.14-rc1 backtrace attached to that bug |
| 19:34.01 | seanbright | if you want to take a look i wouldn't complain |
| 19:34.05 | seanbright | i'm working on other things at the moment |
| 19:34.41 | Qwell | I'm just a little worried, having 2 people reference the same commit from months ago, in as many days. |
| 19:43.16 | Qwell | <PROTECTED> |
| 19:43.16 | Qwell | <PROTECTED> |
| 19:43.33 | Qwell | so, the +1 is completely ignoring that restriction |
| 19:48.48 | Qwell | I don't understand why we're even mmap()ing here. Or creating a file for that matter.. |
| 19:49.58 | Qwell | hell, we unlink() the file that we just mkstemp()d |
| 19:53.42 | Qwell | am I totally missing something here? |
| 19:55.07 | seanbright | Qwell: just because the file is unlinked, doesn't mean it doesn't exists |
| 19:55.09 | seanbright | exist* |
| 19:55.16 | Qwell | okay, but where is the file ever actually...used? |
| 19:55.24 | seanbright | in process_something |
| 19:55.34 | seanbright | search for "s->f" |
| 19:55.38 | seanbright | i think send_string uses it |
| 19:55.40 | Qwell | but the descriptor is cleared |
| 19:55.47 | seanbright | where? |
| 19:55.50 | Qwell | s.f and s.fd |
| 19:55.54 | Qwell | right after the fclose() |
| 19:55.57 | seanbright | what branch are you looking at right now? |
| 19:56.01 | Qwell | 1.6.2 |
| 19:56.52 | seanbright | ok, on 3918-3920 we open the fd and the FILE * |
| 19:57.06 | seanbright | 3920 we call process_message |
| 19:57.16 | Qwell | oh |
| 19:57.31 | seanbright | err |
| 19:57.33 | seanbright | 3930 |
| 19:58.05 | seanbright | which in turn calls process_events, which calls send_string, which appends stuff to the file |
| 19:58.20 | seanbright | the point of the memory mapping is to make the xml translation easier |
| 19:58.26 | seanbright | afaict |
| 19:58.27 | Qwell | I see |
| 19:59.20 | *** join/#asterisk-dev IsUp (~nocturne@unaffiliated/isup) |
| 20:02.36 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 20:02.36 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 20:08.26 | *** join/#asterisk-dev Bloudermilk (~Bloudermi@dsl081-234-075.lax1.dsl.speakeasy.net) |
| 20:29.05 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@192.55.64.175) |
| 20:31.41 | devmod | rtp.conf: the first port of the range should be even, so 10001 won't be used (use 10000 or 10002 instead); the last port must be uneven, and if you specify e.g. 10017 as last in range asterisk will actually use 10018, so be aware! << Is this still true? |
| 20:33.54 | seanbright | doesn't appear to be that way in trunk |
| 20:34.37 | seanbright | where are you reading that? |
| 20:41.45 | devmod | voip-info.org |
| 20:43.00 | devmod | I was also wondering why in the comments on rtp.conf.sample says ; Defaults are rtpstart=5000 and rtpend=31000 but then below rtpstart=10000 rtpend=20000 |
| 20:45.51 | seanbright | the "example" values in the config are typically different than the defaults |
| 20:46.15 | seanbright | voip-info.org is usually wrong about everything |
| 20:46.24 | seanbright | too many cooks |
| 20:46.28 | devmod | seanbright, haha ok gotta remember that |
| 21:10.10 | devmod | How would adding an outboundproxy in sip.conf affect media? I test calling without and it works (audio) , test after adding it media still sent but I hear nothing. |
| 21:23.11 | *** join/#asterisk-dev Corydon76-lap (~Adium@uslec-63-243-109-114.cust.uslec.net) |
| 21:23.11 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 21:35.41 | *** join/#asterisk-dev Corydon76-lap (~Adium@uslec-63-243-109-114.cust.uslec.net) |
| 21:35.41 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 21:37.15 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 21:39.49 | *** part/#asterisk-dev Corydon76-lap (~Adium@uslec-63-243-109-114.cust.uslec.net) |