| 00:01.48 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 00:11.25 | wonderworld | [TK]D-Fender: still here? |
| 00:11.31 | [TK]D-Fender | yup |
| 00:11.46 | wonderworld | ok, i managed to log the thing |
| 00:11.57 | wonderworld | sorry for my bad english, maybe looking at the logs would be more easy |
| 00:12.31 | wonderworld | https://pastebin.com/dkadyMbn |
| 00:16.00 | wonderworld | hardware is Digium B410P |
| 00:16.23 | [TK]D-Fender | You were supposed to show the channels already in progress as well... |
| 00:16.32 | [TK]D-Fender | You need to be complete in showing your situation |
| 00:17.13 | [TK]D-Fender | And you should also be at verbose 10. Make sure we see that |
| 00:19.16 | wonderworld | ok. what do you need? would "pri set debug on span 4" with verbose 10 for all calls be enough? |
| 00:19.30 | wonderworld | or do you need anything else? |
| 00:19.41 | [TK]D-Fender | And prrof of the status of those existing calls before the 3rd comes in that you figure shouldn't |
| 00:20.12 | wonderworld | i checked with "dahdi show channels" they were in use |
| 00:20.23 | [TK]D-Fender | This is very easy. PROVE that things are actually happening the way you felt it was before. |
| 00:20.33 | [TK]D-Fender | "i checked" != I SHOWED |
| 00:20.46 | [TK]D-Fender | And we should see * channels, not jsut DAHDI |
| 00:20.46 | wonderworld | ok, i will show you :) |
| 00:21.25 | wonderworld | how would i access information on the * channels? |
| 00:21.43 | [TK]D-Fender | "core show channels" |
| 00:21.46 | wonderworld | ok |
| 00:21.53 | wonderworld | will be back in 10 |
| 00:58.29 | wonderworld | hey |
| 00:58.39 | wonderworld | [TK]D-Fender: still there? |
| 00:58.55 | [TK]D-Fender | For a few minutes only |
| 00:59.21 | wonderworld | https://pastebin.com/1Q80CXpJ |
| 01:02.50 | wonderworld | hmm, maybe it's because it's sending CAUSE 34 (congestion) intead of CAUSE 17 (busy)? but i am not familiar with ISDN on the protocol level. no idea what my telco would expect.... |
| 01:13.15 | *** join/#asterisk blast_hardcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635) |
| 01:21.38 | *** join/#asterisk blast_ha1dcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635) |
| 02:14.52 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 02:51.48 | *** join/#asterisk Shorty_ (~shanes@membrane.webinabox.net.au) |
| 02:53.09 | Shorty_ | howdy guys, I've found some segfaults with T.38 faxing.. I've done some gdb debugging but I'm not familiar enough with the code to really nut it out.. what's the best process for getting some assistance on it? |
| 03:04.53 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 05:42.35 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 06:29.55 | *** join/#asterisk maus (~quassel@88.147.154.146) |
| 06:49.34 | *** join/#asterisk jeffspeff (~jeffspeff@12.49.160.131) |
| 07:04.26 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 07:07.20 | *** join/#asterisk pchero_work (~pchero@87.213.240.121) |
| 07:07.46 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 07:22.19 | *** join/#asterisk blast_hardcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635) |
| 08:11.25 | *** join/#asterisk thanhtruong (~thanhtruo@116.100.139.165) |
| 08:29.45 | wdoekes | Shorty_: please file a bug report the asterisk issue tracker, and attach the backtrace ('bt' and 'bt full') and possibly also backtraces of the other threads (unsure if needed) |
| 08:30.38 | wdoekes | and.. can you reproduce it? you can enable faxdebug ('fax set debug') and collect the entire fax conversation in fax.log (see logger.conf) |
| 08:31.09 | wdoekes | (you'll need to re-enable fax debug after starting asterisk, there is no setting for it) |
| 08:32.34 | wdoekes | if you have a fax.log, you can create a pcap from it to replay the fax (see spandspflow2pcap.py in contrib/scripts/) |
| 08:40.14 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
| 08:43.44 | *** join/#asterisk manticorpus (~manticore@129.125.14.46.static.wline.lns.sme.cust.swisscom.ch) |
| 08:46.48 | manticorpus | Hi there, I have some bad behavior in one of my custom asterisk module. When there is a lots of calls on this module, I receive sometimes -1 as return code. Does the following code is thread safe : ( https://pastebin.com/Kwftua2K) |
| 08:50.11 | *** join/#asterisk pyro25 (c44123d7@gateway/web/freenode/ip.196.65.35.215) |
| 08:55.26 | Shorty_ | wdoekes: yeah, I've got everything bar the fax PCAP |
| 08:55.31 | Shorty_ | I'll do that in a moment |
| 08:55.59 | Shorty_ | I tried to disable T.38 completely but I'm now stuck in a re-invite->488->reinivite->488->BYE situation |
| 08:58.52 | manticorpus | Second question: There is a place for best-practice during writing custom module ? |
| 09:01.41 | *** join/#asterisk defsdoor (~Andrew@46.16.211.156) |
| 09:13.53 | wdoekes | manticorpus: for starters, you shouldn't use malloc/free but the ast_* prefixed versions. as for the return code being -1: you should figure out where the -1 comes from: either the fork() failed (in which case you have a WARNING in your logs) or waitpid returned -1 or waitpid returned success, but the script terminated abnormally (segfault? sigabort?) |
| 09:15.23 | manticorpus | wdoeskes: First point, as the command is called (I log the return code in my script) -> So I suppose the fork has not failed |
| 09:16.09 | manticorpus | wdoeskes: For the second part, where from the -1, is exactly what I am seeking for. But I see nothing special otherwise the snipped I have provided |
| 09:18.27 | manticorpus | wdoeskes: The only point I can figure out, is this snippet of code has work billions on times in a "less concurrency" environment and now there are maybe 10 call of this module in the same second instead of 1. So I think, the problem is a thread-safety one |
| 09:18.36 | wdoekes | you can strace your asterisk daemon, with '-e waitpid,waitid' |
| 09:19.11 | wdoekes | (and -f) |
| 09:20.09 | manticorpus | wdoeskes : yes, I suppose I can attach to the process, but as it's very difficult to reproduce the problem, I will first work on static analysis |
| 09:21.47 | wdoekes | well. if it's hard to reproduce, I suggest you add some logging. for starters near the waitpid in safe_exec_wait() |
| 09:23.25 | manticorpus | wdoekes: Yes, I suppose I have to... But just some theoretical question : Does Asterisk module is thread safe ? I can't find any input about thread-safety |
| 09:23.38 | wdoekes | (having said that: I think doing loads of fork()s from a multithreaded application is a bad design. if possible, you should consider refactoring that to having a (script) daemon you can talk to instead) |
| 09:24.44 | wdoekes | asterisk is very multithreaded. some things are safe, some things are not. but mostly the function calls document whether you need to lock something. (when in doubt, look at other callers and how they do it) |
| 09:26.29 | *** join/#asterisk K0HAX (~michael@gateway/tor-sasl/k0hax) |
| 09:27.46 | manticorpus | wdoekes: Ok, I have always read that the only things you can do safely in fork is execve. So even if there are better design, I can seek for any bug here |
| 09:46.25 | *** join/#asterisk maus (~quassel@88.147.154.146) |
| 09:51.59 | wdoekes | there are limited things you should do when forking from multithreaded applications, but you're definitely allowed to do more than only execve (close() and setsid() spring to mind) |
| 09:55.42 | manticorpus | wdoeskes: Ok thanks for your time very appreciated. I will try to reproduce this issue in lab, and strace to check where the problem come from. |
| 09:58.33 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 10:00.28 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 10:08.25 | *** join/#asterisk maus (~quassel@88.147.154.146) |
| 10:47.23 | *** join/#asterisk pchero_work (~pchero@87.213.240.121) |
| 11:05.06 | *** join/#asterisk miralin (~Thunderbi@81.177.202.137) |
| 11:12.47 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 11:14.14 | *** join/#asterisk rpifan (~rpifan@p578D20EA.dip0.t-ipconnect.de) |
| 11:16.37 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 11:24.35 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-pufemyluqhejmhzt) |
| 11:24.35 | *** mode/#asterisk [+o bford] by ChanServ |
| 11:26.32 | *** join/#asterisk miralin1 (~Thunderbi@81.177.202.137) |
| 11:51.28 | *** join/#asterisk Mr_Pleb_Mgoo (~jakeb@103.46.212.49) |
| 12:11.35 | Zhadnost | I'm getting a strange problem, often when making outgoing calls (IAX) asterisk doesn't seem to notice when the call has been answered. (and doesn't pass this on to the handset). This leaves the call being marked as UNANSWERED in the call logs and the handset ring timeout triggering and cutting the call. |
| 12:12.03 | Zhadnost | Looking at an IAX debug on such a call, it looks like an ANSWER message is coming from the remote end. |
| 12:12.28 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 12:12.57 | Zhadnost | (No audio issues). |
| 12:14.43 | wonderworld | is there a way to map the ISDN cause codes dahdi/libpri sends out to different codes? our asterisk sends out CAUSE 34 (congestion) when both B-channels are in use but our telco expects CAUSE 17 (busy) to play the right tones to the calling user. |
| 12:15.40 | wonderworld | i thought i might fix it by changing it in libpris source code and recompile but i am unsure if that might cause other problems |
| 13:03.18 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:34.46 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 13:37.04 | *** join/#asterisk pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 13:43.02 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:43.02 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:03.48 | *** join/#asterisk kkocaerkek (~kkocaerke@195.142.112.66) |
| 14:07.13 | *** join/#asterisk miralin1 (~Thunderbi@81.177.202.137) |
| 14:16.18 | *** join/#asterisk kharwell (kharwell@nat/digium/x-gwpmwjfrbmnhzied) |
| 14:16.18 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:21.59 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 14:24.40 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 14:28.54 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 14:30.18 | *** join/#asterisk stevedav_ (~stevedavi@197.155.252.3) |
| 14:30.31 | *** join/#asterisk krueger (~krueger@unaffiliated/krueger) |
| 14:36.20 | *** join/#asterisk jeffspeff (~jeffspeff@12.49.160.131) |
| 14:39.44 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 14:48.19 | *** join/#asterisk pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 14:56.18 | *** join/#asterisk pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 15:00.02 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-tznndmdpcbhlcpjb) |
| 15:00.02 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:18.48 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 15:45.11 | *** part/#asterisk manticorpus (~manticore@129.125.14.46.static.wline.lns.sme.cust.swisscom.ch) |
| 15:46.11 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 15:55.46 | *** join/#asterisk rpifan (~rpifan@p578D20EA.dip0.t-ipconnect.de) |
| 16:25.46 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 17:06.22 | *** join/#asterisk miralin (~Thunderbi@81.177.202.137) |
| 17:59.10 | *** join/#asterisk blast_hardcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635) |
| 18:04.32 | *** join/#asterisk blast_ha1dcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635) |
| 18:17.24 | *** join/#asterisk blast_hardcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635) |
| 18:20.56 | *** join/#asterisk salviadud (~ralfalfa@187-162-213-198.static.axtel.net) |
| 18:33.41 | *** join/#asterisk jeffspeff (~jeffspeff@12.49.160.131) |
| 18:35.43 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 18:38.44 | *** join/#asterisk Terrell (~terr@66.18.218.43) |
| 18:40.21 | Terrell | Samot, Hey many thanks. I think I have all sorted out. I don't need Asterisk right now but there is a church group and they may benefit. In hte mean time I think I have my issues resolved and it is thanks to your (plural) help |
| 18:45.33 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 19:15.32 | *** join/#asterisk Chex (sss@sleepl.northnook.ca) |
| 20:29.03 | *** join/#asterisk blast_hardcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635) |
| 20:45.11 | *** join/#asterisk Downlots (~Downlots@ppp091138243190.dsl.hol.gr) |
| 20:47.22 | *** join/#asterisk Downlots_ (~Downlots@2a02:85f:f07:1200:6313:e683:ed0:9612) |
| 20:48.14 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 20:57.29 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 21:19.18 | *** join/#asterisk azyl (~azyl@71-80-227-144.dhcp.mghl.ca.charter.com) |
| 21:34.44 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 21:54.19 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
| 22:39.20 | *** join/#asterisk Cory (Cory@unaffiliated/cory) |
| 22:58.11 | *** join/#asterisk stevedavies (~stevedavi@197.155.252.3) |
| 23:01.18 | *** part/#asterisk kharwell (kharwell@nat/digium/x-gwpmwjfrbmnhzied) |
| 23:09.26 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |