| 00:01.46 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 00:01.46 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 00:47.29 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 00:47.29 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 00:48.21 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 00:48.21 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 02:23.15 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 02:23.15 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 03:13.14 | *** join/#asterisk-dev bbryant1 (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 03:13.14 | *** mode/#asterisk-dev [+o bbryant1] by ChanServ |
| 03:33.54 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 06:01.54 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 06:12.44 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:12.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:26.05 | *** part/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:03.09 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:03.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:03.48 | oej | Morning |
| 07:04.56 | mvanbaak | hey oej |
| 07:17.24 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 07:24.00 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:21.12 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 08:43.54 | *** join/#asterisk-dev oej_ (n=olle@ns.webway.se) |
| 09:01.15 | *** join/#asterisk-dev oej (n=olle@87.96.134.125) |
| 09:01.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:24.30 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 10:35.05 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 11:01.51 | leifmadsen | morning all |
| 11:13.57 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:22.46 | tzafrir_laptop | good morning |
| 11:41.15 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 11:41.15 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:44.45 | *** join/#asterisk-dev ms110 (n=Shehzad@122.169.51.32) |
| 11:58.24 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:58.24 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:22.09 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:22.09 | *** join/#asterisk-dev ccesario_ (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 12:22.09 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) [NETSPLIT VICTIM] |
| 12:22.09 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 12:22.09 | *** mode/#asterisk-dev [+o leifmadsen] by irc.freenode.net |
| 12:23.35 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:23.35 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:30.04 | eliel | morning all! |
| 12:30.45 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 12:30.45 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 12:32.41 | fiddur | Hi folks. I have an issue with code ready and it's well tested but it hasen't been touched by the bug marchals; been hanging since late february... Would it help if I post it to review board instead, to get some feedback from the dev-list? https://issues.asterisk.org/view.php?id=14559 |
| 12:34.04 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:34.04 | *** join/#asterisk-dev ccesario_ (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 12:34.05 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) [NETSPLIT VICTIM] |
| 12:34.05 | *** mode/#asterisk-dev [+o leifmadsen] by irc.freenode.net |
| 12:37.55 | eliel | fiddur: you could email the -dev list about this feature, to know if this is usefull for other users to get some attention... |
| 12:39.32 | russellb | M14559 |
| 12:39.34 | MuffinMan | [new] [Asterisk] Applications/NewFeature 0014559: [patch] Queue setting to disregard penalty on few queue members reported by fiddur (Karma: neutral) https://issues.asterisk.org/view.php?id=14559 |
| 12:40.47 | fiddur | Oh, nice bot :) |
| 12:41.55 | fiddur | eliel: Yes... But with a patch ready, I thought the reviewboard was preferrable, so the dev's can comment on the code too? It goes to -dev anyway? |
| 12:42.25 | mvanbaak | yes, if you put it up on reviewboard there will be a mail to -dev |
| 12:42.26 | eliel | fiddur: review the coding guidelines |
| 12:45.05 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) [NETSPLIT VICTIM] |
| 12:47.29 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:47.29 | *** join/#asterisk-dev ccesario_ (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 12:47.30 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) [NETSPLIT VICTIM] |
| 12:47.30 | *** mode/#asterisk-dev [+o leifmadsen] by irc.freenode.net |
| 12:51.06 | fiddur | eliel: Thanks, I'll update. |
| 12:57.55 | eliel | fiddur: you are welcome |
| 12:59.24 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 13:09.14 | *** join/#asterisk-dev ccesario_ (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 13:14.18 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:14.40 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:38.44 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) |
| 13:44.15 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 13:50.36 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:50.36 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:51.11 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:51.11 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:53.48 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 13:53.48 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 13:58.29 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 14:02.43 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-32-189.maryville.mo.cebridge.net) |
| 14:02.43 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 14:14.44 | *** join/#asterisk-dev moy (n=moy@74.12.123.90) |
| 14:19.09 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:19.09 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:26.20 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 14:45.38 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 14:47.43 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 14:48.39 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 14:59.05 | mvanbaak | if I have two boxen configured with an IAX2 link between them, and boxa has boxb as reachable but boxb has boxa unreachable, what can it be ? |
| 14:59.15 | mvanbaak | they are on the same network, without firewalls involved |
| 14:59.36 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:59.36 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:59.39 | mvanbaak | stuff from boxa to boxb works without trouble, but from boxb to boxa results in INVAL all the time |
| 15:00.06 | mvanbaak | entries in iax.conf are the same, cept for the host= line |
| 15:05.10 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 15:05.10 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:25.01 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.175.58) |
| 15:26.31 | *** join/#asterisk-dev Dovid (n=annon@72-59-101-4.pools.spcsdns.net) |
| 15:33.18 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:48.10 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:48.10 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:51.59 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:52.24 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 16:22.13 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:54.45 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 16:54.45 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 16:57.05 | seanbright | i doubt it's a big deal, but seeing these warnings while building on 64bit ubuntu - 2.6.24-24-server |
| 16:57.08 | seanbright | /drivers/dahdi/wct4xxp/base.c: In function ât4_remove_oneâ: |
| 16:57.09 | seanbright | /drivers/dahdi/wct4xxp/base.c:3839: warning: passing argument 3 of âpci_free_consistentâ discards qualifiers from pointer target type |
| 17:20.44 | Qwell | seanbright: should probably ping sruffell or open a bug for it |
| 17:21.02 | seanbright | it's not a big deal. just a const vs. non-const thing. |
| 17:21.06 | seanbright | build still succeeds. |
| 17:21.15 | russellb | that warning has been there for a long time |
| 17:21.21 | Qwell | oh |
| 17:21.28 | russellb | i went to try to fix it once and didn't see how to fix it |
| 17:21.33 | russellb | and then I probably got distracted |
| 17:22.11 | Qwell | I'll fix it if you guys find this key for me. :D |
| 17:22.28 | Qwell | deal? k, go. |
| 17:22.55 | tzafrir_laptop | IIRC the respective "qualifier" is DMA zone. But that's my faint memory |
| 17:30.30 | seanbright | would it make sense for the 'make uninstall' target of dahdi linux also remove tonezone.h from /usr/include/dahdi? |
| 17:30.37 | seanbright | even though tools installs it? |
| 17:32.59 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:33.06 | seanbright | ugh. this blows. wanpipe drives don't support the latest dahdi RC> |
| 17:33.26 | seanbright | drivers* |
| 17:35.48 | Corydon76-lap | You know, you COULD use Digium cards... |
| 17:36.03 | Corydon76-lap | That would ensure continued compatibility |
| 17:38.50 | tzafrir_laptop | seanbright, yeah, the echo canceller interface change |
| 17:39.07 | seanbright | indeed. |
| 17:39.28 | tzafrir_laptop | (though with latest dahdi you can actually build their drivers without the source tree of dahdi-linux) |
| 17:40.17 | seanbright | and we do use digium cards, but we needed a PCI express interface for a couple of them and at the time digium didn't have any |
| 17:40.21 | seanbright | whatever. it's moot. |
| 17:41.30 | seanbright | the echo canceller changes were between 2.1.0 and 2.2.0 correct? |
| 17:42.43 | tzafrir_laptop | yes |
| 17:42.46 | seanbright | splendid. |
| 17:42.50 | seanbright | downgrades |
| 17:45.34 | dbrooks | so I'm doing one of the 'janitor projects' http://svn.asterisk.org/svn/asterisk/trunk/doc/janitor-projects.txt , the pbx_builtin_getvar_helper() should be more threadsafe one. Should I replace code only if the ast_channel_lock() and unlocks are missing? |
| 18:02.19 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 18:23.12 | tzafrir_laptop | seanbright, what was that warning there you silinced? |
| 18:32.34 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:37.59 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:37.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:43.03 | leifmadsen | seanbright: 1.4.26-rc2 is going out soon-ish |
| 18:43.18 | leifmadsen | seanbright: do you have everything done that needs to be in that release? |
| 18:43.26 | leifmadsen | -rc2 is expected to become 1.4.26 |
| 18:59.16 | seanbright | yes. that stack fix. |
| 18:59.27 | seanbright | but i haven't heard back from the reporter. |
| 18:59.38 | seanbright | it fixes the crash here, so i may just commit. |
| 19:00.29 | seanbright | in fact... yes |
| 19:00.33 | seanbright | i shall commit now |
| 19:03.42 | seanbright | tzafrir_laptop: warning where? |
| 19:04.08 | seanbright | tzafrir_laptop: oh... the one that says to add a (+) when you run 'make -j9' or whatever. |
| 19:05.09 | seanbright | if gmake calls sub-makes and $(MAKE) doesn't appear in the rule, it doesn't know that it can do the build in parallel |
| 19:05.20 | seanbright | so the + says "trust me on this one, you can do this in parallel" |
| 19:09.05 | seanbright | tzafrir_laptop: this one, specically: |
| 19:09.07 | seanbright | gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. |
| 19:09.48 | leifmadsen | seanbright: which bug number? |
| 19:12.00 | seanbright | 14932 |
| 19:12.03 | seanbright | M14932 |
| 19:12.06 | MuffinMan | [ready for testing] [Asterisk] Applications/app_voicemail 0014932: [patch] asterisk-1.6.0.9-x86_64 segfaults when leaving a voicemail internally to another extension reported by jpiszcz (Karma: neutral) https://issues.asterisk.org/view.php?id=14932 |
| 19:12.21 | seanbright | like i said though, i was able to duplicate the crash here, and tested the fix and it works just fine. |
| 19:12.27 | seanbright | so i am in the process of committing right now. |
| 19:20.37 | *** join/#asterisk-dev korihor (n=korihor@190.72.254.245) |
| 19:21.37 | leifmadsen | awesome |
| 19:21.41 | leifmadsen | I just wanted to add it to the roadmap |
| 19:22.31 | leifmadsen | seanbright: that looks to mostly affect 1.6.x? |
| 19:24.51 | seanbright | leifmadsen: yes and no. it is a crash bug on 1.4 as well. |
| 19:24.53 | seanbright | on 64 bit processors. |
| 19:25.07 | *** join/#asterisk-dev tamiel (n=tamiel@ip-120.net-81-220-18.versailles.rev.numericable.fr) |
| 19:26.02 | leifmadsen | ah gotcha |
| 19:28.03 | kpfleming | yo yo yo! any FreeBSD users here? |
| 19:28.59 | Juggie | watches a tumbleweed roll by. |
| 19:33.16 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:48.15 | eliel | kpfleming: plan9? obsd? amoeba? |
| 19:48.58 | kpfleming | nope, just freebsd, although openbsd would be alright as well |
| 19:49.08 | eliel | ok |
| 19:49.12 | eliel | i have one |
| 19:49.21 | kpfleming | are you an experienced obsd user? |
| 19:49.27 | eliel | nop |
| 19:49.30 | kpfleming | ok |
| 19:49.36 | kpfleming | me either :_) |
| 19:49.47 | seanbright | do a full backup right now |
| 19:49.50 | seanbright | :P |
| 19:53.18 | Qwell | kpfleming: mvanbaak would likely know |
| 19:53.27 | kpfleming | yep |
| 19:54.34 | eliel | what is the problem? |
| 19:54.59 | kpfleming | there is no problem |
| 19:55.07 | eliel | the question? |
| 19:55.21 | kpfleming | i need people to build me properly-made VMware VMs of FreeBSD 6 (32-bit and 64-bit) for use in making builds of codec_g729 |
| 19:56.34 | eliel | i am running freebsd 7.1 in a vm... |
| 19:57.09 | eliel | 32bit |
| 19:57.21 | kpfleming | well, and FreeBSD 7 as well then |
| 19:58.08 | eliel | do you want a copy of my vm? |
| 19:58.20 | kpfleming | no |
| 19:58.29 | kpfleming | i want a freshly built VM, with gcc 4.3 installed and subversion 1.5 |
| 19:58.33 | kpfleming | never used for anything |
| 20:01.21 | eliel | is installing freebsd (32bit) |
| 20:06.34 | *** join/#asterisk-dev Nine5102 (n=Aleksi@192.80-203-96.nextgentel.com) |
| 20:10.58 | leifmadsen | mvanbaak: your services are needed! :) |
| 20:11.38 | russellb | no, not those services |
| 20:18.38 | leifmadsen | oh, well nevermind then. |
| 20:32.44 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 20:32.44 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 20:50.23 | russellb | putnopvut: ping |
| 20:50.32 | putnopvut | russellb: pong sir |
| 20:50.38 | russellb | So, remember that RTP alt peer patch? |
| 20:50.43 | putnopvut | I sure do! |
| 20:50.50 | russellb | What's the story on the trunk version of that? |
| 20:50.55 | russellb | I went looking for it, and didn't see it |
| 20:51.02 | *** join/#asterisk-dev ziram19 (n=chatzill@41.226.177.171) |
| 20:51.03 | putnopvut | Not needed because of a modification to chan_sip that file made. |
| 20:51.26 | putnopvut | In trunk, you can have canreinvite set to nonat and it doesn't affect how the reinvites work. |
| 20:51.53 | russellb | Oh, alrighty then. I just wanted to make sure it didn't slip through the cracks |
| 20:51.56 | russellb | carry on ;-) |
| 20:52.09 | putnopvut | Let me verify |
| 20:52.49 | putnopvut | Actually I think I'm wrong. |
| 20:52.58 | putnopvut | I may need to code up a little something something for trunk. |
| 20:53.14 | putnopvut | Now I just need to be sure that the rtp engine needs the change. |
| 20:53.34 | putnopvut | I think res_rtp_asterisk will correctly learn the new RTP source, but once again I need to verify. |
| 20:56.15 | ziram19 | did someone has any solution for echo that happens even a call is established without that the other side answer? |
| 20:56.53 | ziram19 | is the hardware solution works for this kind of echo |
| 20:57.36 | russellb | #asterisk please |
| 20:58.36 | file | putnopvut: ohhhhhh... |
| 20:58.41 | file | putnopvut: we talked about that. |
| 20:58.55 | file | remembers |
| 20:59.34 | putnopvut | grumbles about rtp engines. |
| 21:02.12 | ziram19 | russellb there is no one on * |
| 21:02.34 | russellb | there are 296 people, be patient :-) |
| 21:04.40 | Nine5102 | Is there any user-space library for developing programs that use dahdi? libzap doesn't seem to exist anymore. |
| 21:04.40 | seanbright | so here is a dumb question |
| 21:04.54 | kpfleming | no, there is no library |
| 21:05.04 | seanbright | actually, i'll just test it. |
| 21:10.58 | seanbright | ok, so the child process from a fork() appears to inherit the parent processes signal handlers |
| 21:11.10 | seanbright | does that sound correct? |
| 21:13.34 | seanbright | here is my fundamental question. in res_musiconhold, we fork() which effectively gives us a child process which is a duplicate of the main asterisk process. then we execv() which overwrites the current process with that of the exec'd process (mpg123) in this case |
| 21:13.36 | putnopvut | seanbright: It sounds correct but I'm having trouble finding a doc to verify. |
| 21:13.59 | Corydon76-lap | seanbright: it is completely correct |
| 21:14.01 | seanbright | but the signal handlers would still be intact... i think |
| 21:14.15 | seanbright | or maybe that part is wrong. |
| 21:14.23 | kpfleming | the signal dispositions are certainly carried across the fork |
| 21:14.30 | seanbright | what about the exec? |
| 21:14.36 | Corydon76-lap | seanbright: it specifically creates a problem in that the pointers to the signal handlers may no longer be real functions |
| 21:14.38 | kpfleming | the handlers should be as well, but then exec would clear them, since the entire process image is being replaced |
| 21:14.40 | russellb | hm, don't think the exec ... |
| 21:14.48 | seanbright | ok, that makes me feel better. |
| 21:14.50 | Corydon76-lap | exec does not clear them |
| 21:14.54 | seanbright | oh really? |
| 21:14.58 | russellb | do what? |
| 21:15.21 | Corydon76-lap | By my reading of the POSIX spec, the exec should not alter the signal handlers |
| 21:15.24 | seanbright | so when SIGTERM is sent to the child process (mpg123) doesn't that try to call __quit_handler? |
| 21:15.41 | seanbright | which is not in the current process' image? |
| 21:15.42 | Corydon76-lap | seanbright: correct, and that function may no longer be there |
| 21:15.56 | seanbright | interesting. |
| 21:16.06 | kpfleming | there is no 'may' about it |
| 21:16.09 | kpfleming | it will not be there |
| 21:16.26 | Corydon76-lap | which is why we explicitly replace those signal handlers before we exec |
| 21:16.30 | seanbright | ohhhh |
| 21:16.31 | seanbright | heh |
| 21:16.34 | seanbright | that's the part i was missing |
| 21:16.40 | Corydon76-lap | or rather, we set them back to SIG_DFLT |
| 21:17.04 | kpfleming | technically, the is the disposition, not the handler :-) |
| 21:17.21 | seanbright | where is that happening in res_moh? |
| 21:18.03 | seanbright | i'm not seeing it, but i will admit to not completely grok'ing the source |
| 21:18.08 | seanbright | plus i'm looking at 1.4 |
| 21:18.11 | *** join/#asterisk-dev Greek-Boy (n=greek@41.222.89.77) |
| 21:18.14 | Corydon76-lap | seanbright: in ast_safe_fork() |
| 21:18.28 | Corydon76-lap | It's possible that 1.4 doesn't do it |
| 21:18.37 | seanbright | ahhh. |
| 21:18.42 | Corydon76-lap | since ast_safe_fork() is a 1.6ism |
| 21:18.47 | seanbright | yeah, res_musiconhold calls fork() directly |
| 21:19.06 | Corydon76-lap | Might be something worth backporting |
| 21:19.21 | seanbright | but i guess the worst that happens is that mpg123 would crash |
| 21:19.25 | seanbright | that shouldn't affect asterisk |
| 21:19.30 | Corydon76-lap | It makes doing all of the various things we need to do during a fork oh so easy |
| 21:20.14 | Corydon76-lap | For one thing, it blocks all the signals during a fork, so that the child cannot die on a signal prematurely |
| 21:20.33 | kpfleming | and it also handles dropping elevated privileges |
| 21:21.04 | Corydon76-lap | Right, that's the other major thing |
| 21:21.25 | seanbright | that's done in moh in 1.4, just not via ast_safe_fork |
| 21:21.35 | seanbright | the signal handlers are not reset to defaults in there, however. |
| 21:22.04 | Corydon76-lap | Backporting ast_safe_fork() would probably cleanup a lot of forking code |
| 21:26.23 | seanbright | well ya learn something new everyday i s'pose |
| 21:37.50 | seanbright | well. i can't duplicate that behavior in my code. |
| 21:37.59 | seanbright | i.e. make the child process crash by sending it a signal. |
| 21:44.15 | seanbright | and i just checked. after a fork()/execl() the signal handler is set to NULL. |
| 21:44.40 | seanbright | that may not be defined behavior, but that is what i am seeing in my tests. |
| 21:46.22 | *** join/#asterisk-dev DarkRift (n=dark@65.92.166.229) |
| 21:48.08 | seanbright | from the execve() man page: "The dispositions of any signals that are being caught are reset to being ignored." |
| 21:48.14 | seanbright | so it's a red herring. |
| 21:50.28 | Corydon76-lap | seanbright: I'm reading the POSIX spec, and it should be "reset to the default" |
| 21:51.02 | Corydon76-lap | only signals which are ignored in the parent should be ignored in the child |
| 21:51.08 | Corydon76-lap | and I was incorrect before |
| 21:52.05 | Corydon76-lap | The only signal behavior which is ambiguous is SIGCHLD |
| 21:52.24 | Corydon76-lap | but a child process shouldn't really be receiving that anyway |
| 21:52.35 | Corydon76-lap | (well, yet) |
| 21:53.03 | Corydon76-lap | If you're curious: http://www.opengroup.org/onlinepubs/009695399/functions/exec.html |
| 21:54.55 | seanbright | reading |
| 21:56.27 | seanbright | ok, so we just need to make sure that before exec and friends, that any signals we are ignoring are set back to default |
| 21:56.36 | Corydon76-lap | What I was thinking of before was the behavior of fork() |
| 21:56.40 | seanbright | right |
| 21:57.00 | Corydon76-lap | because receiving a signal in the child there might be bad |
| 21:57.32 | seanbright | well if it is after the fork() it would still have a valid handle to the handler functions |
| 21:57.42 | seanbright | after the fork() and before the exec() |
| 21:58.04 | Corydon76-lap | Right, but depending upon which signals... might still be very bad |
| 21:58.12 | seanbright | gotcha. |
| 21:58.32 | Corydon76-lap | like a HUP might cause us to do a reload, which might try to lock a mutex that was locked at the time the child was forked |
| 21:58.59 | Corydon76-lap | and then you're stuck, because the child doesn't have multiple threads |
| 22:00.30 | seanbright | well everything i have read has said 2 things |
| 22:00.36 | seanbright | don't use signal() |
| 22:00.44 | seanbright | don't use signal() with multithreaded apps |
| 22:01.13 | Corydon76-lap | seanbright: preferring what, sigaction? |
| 22:01.18 | seanbright | yeah |
| 22:01.30 | seanbright | the ubuntu man page says that is preferable and more portable |
| 22:01.36 | Corydon76-lap | We seem to manage okay |
| 22:01.39 | seanbright | indeed. |
| 22:03.45 | Corydon76-lap | Perhaps one day, we'll convert |
| 22:03.57 | Corydon76-lap | Janitor project! |
| 22:03.59 | seanbright | heh |
| 22:04.20 | kpfleming | yes, sigaction() is much better indeed |
| 22:12.41 | russellb | crashy code makes me sad |
| 22:14.34 | seanbright | what is crashy now? |
| 22:15.38 | seanbright | i can make asterisk 1.4 svn crash pretty much 100% of the time |
| 22:15.50 | seanbright | and i think it's MoH related |
| 22:15.55 | seanbright | i just can't figure out why |
| 22:23.34 | seanbright | if someone smarter than me wants to take a whack at it: |
| 22:23.36 | seanbright | http://pastebin.ca/1452463 |
| 22:24.32 | russellb | who cares about a crash on stop now? |
| 22:24.32 | russellb | heh |
| 22:25.19 | seanbright | seriously? |
| 22:25.44 | seanbright | and actually, i can make it do it with only musiconhold loaded |
| 22:26.02 | russellb | well, not totally seriously ... |
| 22:26.05 | seanbright | http://pastebin.ca/1452469 |
| 22:26.14 | russellb | but I mean, a crash when you're stopping anyway ... i'd consider it a lower priority at least |
| 22:26.14 | seanbright | there are crash bugs on mantis related to a double free |
| 22:26.26 | seanbright | on an 'moh reload' |
| 22:26.39 | seanbright | ok, here: |
| 22:26.39 | seanbright | *CLI> moh reload == Parsing '/etc/asterisk/musiconhold.conf': Found |
| 22:26.40 | seanbright | *CLI> moh reload == Parsing '/etc/asterisk/musiconhold.conf': Found |
| 22:26.40 | seanbright | Killed |
| 22:26.46 | seanbright | there you go. |
| 22:26.58 | seanbright | not while 'stop now'ing |
| 22:29.02 | seanbright | gah. i hate programs. |
| 22:44.28 | seanbright | any reason i wouldn't see mpg123 as a child process of asterisk via 'ps' but i would still be getting data from it? |
| 22:44.40 | seanbright | or does that just sound like silly talk? |
| 22:49.02 | seanbright | because it keeps dying, apparently... |
| 22:51.31 | seanbright | wow... |
| 22:54.16 | seanbright | so apparently... |
| 22:54.21 | seanbright | application=mpg123... |
| 22:54.23 | seanbright | vs. |
| 22:54.28 | seanbright | application=/usr/bin/mpg123... |
| 22:54.30 | seanbright | makes a difference. |