| 00:01.16 | *** join/#asterisk-bugs Mackes (n=root@cpe-76-180-236-119.buffalo.res.rr.com) |
| 01:06.02 | *** join/#asterisk-bugs fedealves (i=johndoe@97-243.187-72.tampabay.res.rr.com) |
| 01:06.33 | fedealves | hello dear gentlemen, I opened a new case for a blow up on the current trunk |
| 01:06.48 | fedealves | the number is 0011253 |
| 01:07.08 | fedealves | could somebody take a quick look at the traces? I did a bt full on the core dump |
| 01:08.02 | fedealves | also I think that I misconfigued the section, it is not add on, it os core, how do I change that? |
| 02:06.30 | fedealves | my asterisk is blowing up with trunk every 10 minutes |
| 02:07.02 | fedealves | how can I download an earlier version of trunk? this one is very unstable |
| 02:09.51 | fedealves | I uploaded the file valgrind.txt , issue 11253 |
| 02:10.19 | fedealves | malloc_debug.txt is empty |
| 02:13.07 | fedealves | it just blew up again |
| 02:13.29 | fedealves | I am getting a heart attack |
| 02:19.18 | file | define "earlier version" |
| 02:19.46 | file | svn co http://svn.digium.com/svn/asterisk/trunk@<revision number> will give you trunk at the given revision. |
| 02:26.07 | Qwell | more importantly, why are you running trunk in production? |
| 02:33.15 | Corydon76-dig | Also, it appears that you're running a really old version of glibc |
| 02:35.06 | fedealves | what is the current version of glibc? |
| 02:35.10 | *** join/#asterisk-bugs enst (n=enst@60.28.119.64) |
| 02:39.25 | fedealves | red hat says that glibc is up2date |
| 02:39.35 | fedealves | it just blew up again |
| 02:41.13 | fedealves | did you take a look at valgrind?? |
| 02:41.51 | fedealves | I can not go back to stable because somethings like comma escaping in odbc does not work |
| 02:42.17 | fedealves | also I need core show concise with the extra field |
| 02:50.36 | Qwell | fedealves: what distro? |
| 03:00.44 | *** part/#asterisk-bugs Mackes (n=root@cpe-76-180-236-119.buffalo.res.rr.com) |
| 03:22.54 | Corydon76-dig | fedealves: in include/asterisk/autoconfig.h, comment out the line that says "#define HAVE_EPOLL 1" and recompile |
| 03:27.12 | fedealves | I already did that and went back because it blew up again |
| 03:27.17 | fedealves | but I will do it again |
| 03:29.49 | fedealves | I use red hat 4 latest update, and up2date says glibc is up to date |
| 03:30.26 | Qwell | RH4 or RHEL4? |
| 03:30.34 | fedealves | RHEL |
| 03:30.45 | fedealves | licensed, I use up2date |
| 03:31.55 | fedealves | I got this valgrind.txt.core.18155 |
| 03:38.38 | fedealves | can somebody look at the valgrind files posted and see if something transpires?? |
| 04:37.02 | fedealves | I did recompile it without epoll support and it blew up again |
| 05:02.57 | *** join/#asterisk-bugs enst (n=enst@60.28.119.64) |
| 05:03.55 | enst | d |
| 05:19.06 | fedealves | ?? |
| 05:26.02 | *** join/#asterisk-bugs Pagautas (n=bigman@83.171.14.250) |
| 05:43.03 | *** join/#asterisk-bugs enst (n=enst@60.28.119.64) |
| 06:06.20 | fedealves | I found a falw in Set(timeout(absolute)=xx), please look at my case 11253 |
| 06:08.56 | fedealves | I can reproduce at will |
| 07:35.24 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 08:51.16 | *** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 12:45.10 | *** join/#asterisk-bugs michael-i (n=michael-@Lc371.l.pppool.de) |
| 13:19.23 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:19.23 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 14:13.16 | *** join/#asterisk-bugs Lasse123 (n=Lasse@int-gw.algitech.com) |
| 14:40.22 | *** join/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-255-162-167.bstnma.east.verizon.net) |
| 14:47.55 | *** join/#asterisk-bugs d1mas (n=chatzill@host-99.dataart.net) |
| 14:48.22 | d1mas | file: hello. are you there? wanted to discuss T38 changes... |
| 14:48.35 | file | go ahead |
| 14:48.54 | file | (note I'm not messing with udptl, just the way negotiation works and such) |
| 14:49.28 | file | (well... at present... I might mess with udptl later) |
| 14:50.18 | blitzrage | you mess with everything |
| 14:51.16 | d1mas | file: I was mostly interested about SIP part anyway :=) Do you have changes which provide some ast_* call to request T38 on a channel? |
| 14:51.38 | file | I didn't go that way |
| 14:51.45 | file | I used control frames |
| 14:51.47 | d1mas | I'm asking because we added these for T38 support in ReceiveFAX, but my addition is clearly a hack |
| 14:52.07 | file | so you send a control frame to get the channel to switch to T38, then get an accept/reject back if it worked |
| 14:52.17 | d1mas | great |
| 14:52.30 | d1mas | that is even better :) |
| 14:52.55 | d1mas | file: and when do you expect your changes to be merged to tunk ? |
| 14:52.59 | d1mas | trunk |
| 14:53.04 | file | not for awhile |
| 14:53.07 | file | I just started playing with things |
| 14:53.49 | d1mas | file: do you have that T38 swithover code already available? (without other improvements) |
| 14:54.03 | file | I have a branch |
| 14:54.05 | file | t38insanity |
| 14:54.14 | d1mas | hm... |
| 14:54.39 | d1mas | will take a look. Another question: |
| 14:55.05 | d1mas | file: there currently is some code in the chan_sip.c supposed to detect fax tones and switch to T38 |
| 14:55.38 | d1mas | file: first of all it does not wok ebcause of two issues. Second - I really doubt it should be there at all |
| 14:55.41 | file | aye, questionble |
| 14:55.44 | file | questionable rather |
| 14:55.45 | file | I agree |
| 14:55.58 | file | it should be the responsibility of the ATA |
| 14:56.16 | d1mas | 1. Even whn fixed, chan_sip won't detect fax if dtmfmode != inband |
| 14:56.56 | d1mas | file: so can I assume you will most likely remove that piece in your branch? |
| 14:58.57 | d1mas | very good. I have fixed ReceiveFax to support faxes over T38 but we are currently depend on our (hacky) changes to chan_sip for T38 switchover and also on UDPTL fixes (i already submitted them) |
| 15:00.25 | oej | I don't think the code to detect anything is in chan_sip.c |
| 15:00.34 | file | oej: it is |
| 15:00.36 | d1mas | oej: it is there |
| 15:00.41 | d1mas | oej: sip_read |
| 15:00.50 | d1mas | oej: sip_rtp_read |
| 15:00.58 | oej | Well, the actual code isn't there, the detection code |
| 15:01.01 | oej | We do enable the dsp |
| 15:02.35 | d1mas | Another q (hope the last one) :=) is 10815 going to be added to tunk someday? :) |
| 15:02.48 | oej | What's 10815 |
| 15:02.49 | d1mas | (addons-trunk) |
| 15:02.52 | oej | M10815 |
| 15:02.54 | MuffinMan | [ready for testing] [Asterisk] Applications/NewFeature 0010815: [patch] SendFAX/ReceiveFAX reported by dimas http://bugs.digium.com/view.php?id=10815 |
| 15:04.27 | file | any other T38 stuffz? |
| 15:04.56 | d1mas | file: nope. Will take a look at your branch and try to fix my code for "frame" approach |
| 15:05.06 | file | it should be relatively easy |
| 15:05.12 | d1mas | hope so |
| 15:05.28 | file | that branch is a work in progress though, it has the potential to explode in the t38 stuff :D |
| 15:06.06 | d1mas | no problem, even 1.4 branch has that potential ;=) |
| 15:56.48 | *** join/#asterisk-bugs russellb (i=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:56.48 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 16:07.40 | *** join/#asterisk-bugs jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 17:17.40 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:17.40 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 17:19.18 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 18:44.06 | *** join/#asterisk-bugs agx (n=badpengu@81-174-44-24.dynamic.ngi.it) |
| 19:31.01 | d1mas | file: I'm looking at your t38insanity branch. Couple of questions: |
| 19:32.11 | d1mas | 1. file: I do not see a way to check T38 status of the channel - if T38 already negotiated or not. Am I missing something? |
| 19:33.38 | d1mas | file: 2. Do I understand correctly that in situation when T38 is already negotiated bu some means, if remote party switches back to voice, AST_CONTROL_T38_REJECT frame will be received? |
| 20:22.20 | agx | file, can i help in some way about ticket 11169 ? |
| 20:23.57 | file | d1mas: there is currently no way, and I have not moved on to switching back to voice |
| 20:24.20 | file | agx: not really |
| 20:25.19 | agx | file, i mean if is a sip only issue i can help investigate chan_sip.c code: instead if it involves bridging with chan_misdn i really don't know how "briding" works :-( |
| 20:29.10 | d1mas | file: i see. Actually I think there are not enough different AST_FRAME_* constants in your branch because of this |
| 20:29.43 | file | d1mas: it is certainly possible |
| 20:31.15 | d1mas | I guess at least 4 are necessary - to request t38 on, to request t38 off, to notify t38 has setup, to notify t38 has shut down. |
| 20:32.21 | d1mas | file: and if you want let application be notified in case remote end refused t38 proposal - even more |
| 20:33.00 | file | so, when do you go back to voice? |
| 20:33.37 | d1mas | file: I think fax application should shut t38 down when transmission is over... |
| 20:34.20 | d1mas | file: I know that around a world people using fully-automated fax machines, but here voice is quite often used pre- and post- fax |
| 20:34.31 | file | really? interesting |
| 20:35.46 | d1mas | file: alot of companies have one line - they use it for both voice and fax. So basically a person calls, says "I want to send a fax" and receptionist pushes "Start" |
| 20:37.41 | d1mas | file: and usually receptionist, keeps headset off hook so when transmission is over fax machine connects receptionist back to remote end and ppls usually just ask for confirmation fax was sent ok |
| 20:38.01 | d1mas | I know it is ancient technology :) but it is widely used |
| 20:39.02 | file | I have never heard of someone doing that |
| 20:39.15 | file | silly faxing |
| 20:41.50 | d1mas | file: but leaving that ancient aspect aside - as far as I understood specification, it is clearly valid operation to request voice back. So why developing something which completely eliminate possibility of such an operation? :) |
| 20:42.13 | file | that is true |
| 20:47.26 | d1mas | file: another thing worrying me a bit - according to your code, SIP channel driver _asks_ application if it wants to accept T38 offer. But it means that if application misses that control frame, proposal will be rejected. And I can imagine such a scenario. |
| 20:47.56 | file | yes, like I said it's an experimentation branch right now to try out an approach and ponder |
| 20:48.03 | d1mas | One alternative I see is to accept automatically if some channel variable is set |
| 20:49.21 | d1mas | ok, I will :) |
| 20:49.40 | d1mas | I will followup result + ideas by emil |
| 20:49.54 | file | good plan |
| 21:18.53 | blitzrage | putnopvut: I've confirmed an issue in 1.4.13 with a one-way audio issue. Customer is going to try SVN tomorrow morning and see if the issue still exists. If it does, then I'll lab it up and reproduce the issue for you :) |
| 21:19.21 | blitzrage | *one-way audio issue in Queue(). |
| 21:21.51 | putnopvut | All right. I'm looking forward to it. |
| 21:22.53 | *** part/#asterisk-bugs agx (n=badpengu@81-174-44-24.dynamic.ngi.it) |
| 21:23.57 | blitzrage | bah! No 'core show locks' in 1.4.9... |
| 21:24.00 | blitzrage | anyone know when it was put in? |
| 21:24.26 | blitzrage | I have core show threads.... |
| 21:24.26 | blitzrage | heh |
| 21:27.51 | blitzrage | hrmmm... 1.4.10.1 it seems |
| 21:28.10 | blitzrage | or r78995 |
| 22:00.27 | *** join/#asterisk-bugs Pagautas (n=bigman@83.171.14.250) [NETSPLIT VICTIM] |
| 22:00.31 | *** join/#asterisk-bugs Deeewayne (i=dwayne@nat/digium/x-78db5d584ebf2189) |
| 22:00.31 | *** mode/#asterisk-bugs [+o Deeewayne] by irc.freenode.net |
| 22:00.32 | *** join/#asterisk-bugs russellb (i=russell@asterisk/developer-and-stable-maintainer/drumkilla) [NETSPLIT VICTIM] |
| 22:00.32 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) [NETSPLIT VICTIM] |
| 22:00.32 | *** join/#asterisk-bugs Juggie (n=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) [NETSPLIT VICTIM] |
| 22:00.33 | *** join/#asterisk-bugs putnopvut (i=putnopvu@nat/digium/x-724b8ba603112084) [NETSPLIT VICTIM] |
| 22:00.33 | *** join/#asterisk-bugs kpfleming (i=kpflemin@nat/digium/x-ee9a72ebe0879471) [NETSPLIT VICTIM] |
| 22:00.33 | *** mode/#asterisk-bugs [+oooo russellb Juggie putnopvut kpfleming] by irc.freenode.net |
| 22:00.33 | *** join/#asterisk-bugs d3wayne (n=deeewayn@76.29.245.9) [NETSPLIT VICTIM] |
| 22:00.33 | *** join/#asterisk-bugs Corydon76-vcch (n=tilghman@pdpc/supporter/bronze/Corydon76-home) [NETSPLIT VICTIM] |
| 22:00.33 | *** join/#asterisk-bugs MuffinMan (n=muffins@neutrino.joshua-colp.com) [NETSPLIT VICTIM] |
| 22:00.33 | *** mode/#asterisk-bugs [+o Corydon76-vcch] by irc.freenode.net |
| 22:49.17 | *** join/#asterisk-bugs agx (n=badpengu@81-174-45-170.dynamic.ngi.it) |