IRC log for #asterisk-bugs on 20090113

00:12.06*** part/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-1839f9f224df9648)
02:04.59*** join/#asterisk-bugs ZX81 (n=matt@202.49.106.158)
02:05.03ZX81happened again
02:05.22ZX813 crashes today
02:05.22ZX81customer starting to spit the dummy
02:05.22ZX81don't optimize now on
02:05.25ZX81uploading bt
02:05.28ZX81core
02:06.03ZX81M14086
02:06.05MuffinMan[ready for testing] [Asterisk] Applications/app_queue 0014086: Address out of bounds in queue_log using transfer reported by ZX81 (Karma: +11.75) http://bugs.digium.com/view.php?id=14086
02:06.36ZX81I've added the core and the bt full to:
02:06.37ZX81http://bugs.digium.com/view.php?id=14086#97557
02:08.45ZX81anyone have any ideas of how to work around in the meantime?
02:09.17ZX81we have the potential to lose hundreds of thousands in referal sales if we can't get this working
02:11.16*** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb)
02:11.16*** mode/#asterisk-bugs [+o russellb] by ChanServ
02:11.39ZX81russellb, don't suppose you know anyone that can help with M14086 ?
02:12.19ZX81I just need a workaround or something to stop their pbx crashing
02:12.27ZX81government call center
02:13.44russellbI can't right now ...
02:13.49russellbit looks like it's assigned to the best person
02:13.53ZX81all good
02:13.58ZX81thanks anyway
02:14.08russellbsorry for the delay
02:14.18ZX81:) all good man
02:14.19russellbsometimes (often) we are behind
02:14.28ZX81:)
02:14.43ZX81it's only an issue when I've got an issue :D
02:14.46ZX81hehe
02:14.56ZX81'spose everyone's the same :)
02:15.02russellbpretty much, heh
02:15.08russellbbut i certainly don't wish it on anyone.
02:15.40ZX81yah - we normally run older versions but it crashed once last year and we had to upgrade
02:21.09ZX81if I don't destroy the datastore on a channel, would it just leak memory? I.e. would that maybe get me through till tomorrow?
02:22.25russellbit would leak memory, yes
02:22.38russellbshouldn't be huge amounts ... but depending on your call load, it can add up
02:23.25ZX81ok cool
02:23.34ZX81:) that'll be the test for tonight then :D
02:23.35JunK-Yhave you run it with valgrind?
02:23.39ZX81nah
02:23.43ZX81that was the other option
02:23.54ZX81call quality would be ok?
02:24.10JunK-Yand i guess its happening like random or can you reproduce it really easily?
02:24.18JunK-Yit depends of of number of sim calls
02:24.20JunK-Yhow many?
02:24.48ZX81random
02:24.48ZX81bout 10-20 simul usually
02:24.51russellbZX81: valgrind will eat the system up ...
02:24.55russellb10-20 is probably too much
02:24.58russellbi wouldn't do it
02:25.02ZX81yeah thought so
02:25.28ZX81will let it leak ram for a bit - well will make the change and if it crashes it'll go into leak mode
02:25.29ZX81:)
02:26.11JunK-Yrussellb: you would not run valgrind with this many calls?
02:26.37JunK-Ydepending on the machine i think i would.
02:27.55russellbit _might_ be ok ...
02:28.21russellbif it's transcoding, call recording, etc. (like I might expect in a call center install), it could hurt
02:28.28russellbalso in a call center, lots of call setups hurt, too
02:28.48ZX81no transcoding but yeah the call recording could hurt
02:32.25*** join/#asterisk-bugs sysreq (n=sysreq@unaffiliated/sysreq)
02:39.34*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
02:39.34*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
04:02.23*** join/#asterisk-bugs bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net)
04:02.23*** mode/#asterisk-bugs [+o bbryant] by ChanServ
04:11.38*** part/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb)
08:21.56*** join/#asterisk-bugs MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman)
10:43.05*** join/#asterisk-bugs ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br)
11:00.07*** join/#asterisk-bugs festr_ (n=festr@ns.hiro.cz)
11:00.10festr_hi
11:00.31festr_i'm seeing crashes in the latest svn 1.4 which is releated to datastore and queues
11:00.43festr_any open issues regarding this?
11:05.05ccesarioCorydon76-dig, I see the you suggest one patch to try queue problem (http://bugs.digium.com/view.php?id=14209) ... this patch can too fix this  http://bugs.digium.com/file_download.php?file_id=21155&type=bug   ?
11:12.38*** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982)
11:25.20*** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim)
11:37.36festr_i've found it. http://bugs.digium.com/view.php?id=14086 and posted my backtraces
11:37.53festr_it seems there is problem accessing datastore->info structure which points wto nowhere or is null
11:38.07festr_look at the bug
12:41.13*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
12:41.13*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
14:01.25*** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb)
14:01.25*** mode/#asterisk-bugs [+o russellb] by ChanServ
14:20.59*** join/#asterisk-bugs sysreq (n=sysreq@unaffiliated/sysreq)
14:58.51*** join/#asterisk-bugs awk_r (n=awk_r@nat/digium/x-2ba79f0e5ac7b9d3)
15:35.17*** join/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-757a7d80f3298645)
15:35.17*** mode/#asterisk-bugs [+o Deeewayne] by ChanServ
16:00.19*** join/#asterisk-bugs putnopvut (n=putnopvu@nat/digium/x-a970440124c1c189)
16:00.19*** mode/#asterisk-bugs [+o putnopvut] by ChanServ
16:01.11lmadsenjeebuz... I have 46 bug updates since last night@
16:02.00putnopvutheh, that's a drawback of being Mr. Triage, I suppose.
16:02.10putnopvutyou're essentially a watcher of almost every issue :)
16:03.12lmadsenpretty much :)
16:05.33lmadsenit just means I know every bug in asterisk right? :)
16:08.31putnopvutRight!
16:14.58Juggielmadsen, thats your job! :)
16:15.19lmadsenpart of one of my jobs anyways :)
16:15.29Juggieits what we pay you the big bucks for :P
16:15.35lmadsenha!
16:15.38lmadsenwe?! :)
16:16.05Juggiei have some abe licenses :P
16:17.21lmadsenheh
16:18.37Entomologist*** CLOSED (14218) [Channels/chan_sip/General] [patch] Not possible to disguise display name on calls to trunks even though user can be disguised
16:18.37EntomologistAssigned to: otherwiseguy
16:18.37EntomologistReported by: Nick_Lewis  Karma: 1
16:18.37Entomologisthttp://bugs.digium.com/view.php?id=14218
16:18.37Entomologist*********************************************************
16:34.50*** join/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb)
16:34.50*** mode/#asterisk-bugs [+o russellb] by ChanServ
16:43.09*** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982)
16:45.57*** join/#asterisk-bugs ZX81 (n=matt@202.20.97.211)
16:46.11ZX81hi
16:46.18lmadsenhowdy
16:46.18ZX815:46am here
16:46.21ZX81:)
16:46.22lmadsenouch
16:46.26lmadsen11:46am here :)
16:46.49mvanbaak5:46PM here
16:46.55ZX81trying to get info out of crashing pbx before the office starts
16:47.05ZX81M14086
16:47.09MuffinMan[ready for testing] [Asterisk] Applications/app_queue 0014086: Address out of bounds in queue_log using transfer reported by ZX81 (Karma: +11.75) http://bugs.digium.com/view.php?id=14086
16:47.20ZX81putnopvut: so, what do you want from me
16:47.22ZX81:)
16:47.25ZX81oh
16:47.31ZX81and can you delete the cores
16:47.58lmadsendone
16:48.05ZX81ty
16:48.50putnopvutZX81: If you have a new crash with the patch attached, I'd like to see a backtrace.
16:48.58ZX81yep
16:49.05ZX81which command
16:49.14ZX81threads?
16:49.28putnopvutbt and bt full will probably be sufficient
16:49.33ZX81ok
16:50.19ZX81bt and bt full uploaded to notes
16:50.34ZX81http://bugs.digium.com/view.php?id=14086#97578
16:54.06putnopvutZX81: thank you very much
16:54.35ZX81no probs, have a thread apply all bt if required
17:02.18ZX81I uploaded the thread apply all bt and the dates of the cores - 5 crashes yesterday, 1 the day before - all on weekdays
17:04.31lmadsenrussellb: I suppose that crash issue couldn't be something related more to dtmf features?
17:04.35lmadsenM14228
17:04.37MuffinMan[new] [Asterisk] Resources/res_features 0014228: 1.4.22 crash with Park reported by kobaz (Karma: neutral) http://bugs.digium.com/view.php?id=14228
17:06.38ZX81putnopvut: if you need root access to the machine, just let me know - they have about another 1.5 hours before properly opening - although are starting to get calls to the automated ivr ordering via the AS400
17:07.04putnopvutZX81, that probably won't be necessary, but thanks for offering :)
17:07.11ZX81:)
17:07.13ZX81sweet
17:07.42russellblmadsen: it's possible ... though for that issue, i wonder why he doesn't use the normal park feature ..
17:08.09lmadsentrue... maybe he has to trigger something outside of asterisk first... who knows
17:08.18lmadsenor maybe he doesn't know about it :)
17:08.33Corydon76-digrussellb: ping
17:09.00russellbpong
17:09.11Corydon76-digmurf and I found an opportunity for you
17:09.18russellbo.O
17:09.38Corydon76-digRecall #13962, where we reversed the change made in #6176
17:09.44russellbM13962
17:09.45Corydon76-digThis has to do with app_macro
17:09.46MuffinMan[closed] [Asterisk] Channels/General 0013962: Blind transfer does not work upgrade to 1.4.23-rc1 reported by francesco_r (Karma: +3.75) http://bugs.digium.com/view.php?id=13962
17:09.56russellbM6176
17:09.57MuffinMan[closed] [Asterisk] Applications/app_macro 0006176: [patch] Segfault in pbx_builtin_setvar_helper.  Looks like the channel is being closed down underneath us reported by stevedavies (Karma: +62.75) http://bugs.digium.com/view.php?id=6176
17:10.05russellbyeah, i think so
17:10.30Corydon76-digWell, 6176 introduced a different behavior change, which we reverted, though I didn't know it at the time
17:10.53Corydon76-digThe behavior change was that "h" started being run from the macro context, instead of the original context
17:11.04russellboh geez
17:11.24Corydon76-digSooooo... how should we go forward?
17:11.27russellbheh
17:11.40russellbif it did it for that long, I guess we need to restore that behavior
17:12.04russellbrun "h" from macrocontext if it is there, and if not, run it from the original context
17:12.11ZX81yeah
17:12.16Corydon76-digOooo.  Okay.
17:12.42Corydon76-digThat's an even better behavior
17:12.50russellbyeah :)
17:13.57russellband I think it's what most people would expect (before testing to see what really happens)
17:14.49lmadseninteresting... another bug related to parking (this time on 1.6 though... hmmmm)
17:15.28Qwellblinks
17:15.34russellbthey might be fixed already
17:15.36Qwell14232 is...amusing
17:15.45ZX81M14232
17:15.47MuffinMan[new] [Zaptel] wcfxo 0014232: [patch] Failed to initailize DAA, giving up... reported by tallen8840 (Karma: +4.00) http://bugs.digium.com/view.php?id=14232
17:15.51russellba lot of work has gone in to fixing up some parking
17:15.55Qwellthe summary does it no justice
17:17.04ZX81:D
17:17.34russellbI love when people start out a problem description with "Everything is working fine, but when I do X this bad thing Y happens"
17:17.34ZX81"I reverse engineered the card and found that the DAA's reset pin is connected to the PCI chip's AUX5 pin not, as one might expect the RESET# pin"
17:18.44ZX81:) heh yeah - I called our customer yesterday and said "hey, looks like the crash might be associated with transfers - can you get the call centre to not transfer calls - i.e. take a message and get someone to run round the building with postit notes"
17:21.23ZX81it's a mental site - they have 3 different types of staff (and phones) - factory (analog phones), office staff (linksys spa's), call centre (snom 360s) - I was down there the other day and recognised one of the forms they were printing, had a closer look and realised they were speeding fines :)
17:22.51ZX81putnopvut: with 20 simul calls and call recording I'm not sure I can run in valgrind
17:23.32putnopvutZX81: yeah, I'm still trying to figure it out on this end. Hopefully I'll get it done sometime soon. Did you at least see fewer crashes with the patch applied?
17:23.53ZX812 in the afternoon - after I applied the patch
17:24.01ZX81so same or more
17:24.09ZX81it's not a huge number of crashes
17:24.16ZX81well - customer thinks so
17:24.18putnopvutcrap
17:24.20ZX81but not regular
17:24.52putnopvutYeah, when I put that patch on my local test setup, all the crashes I could reproduce went away.
17:24.59russellbputnopvut: you could give him the "install SIGSEGV signal handler" patch in the mean time ^_^
17:25.03ccesarioCorydon76-dig, I see the you suggest one patch to try queue problem (http://bugs.digium.com/view.php?id=14209) ... this patch can too fix this  http://bugs.digium.com/file_download.php?file_id=21155&type=bug   ?
17:25.17putnopvutrussellb: I haven't seen that one :)
17:25.29ZX81sounds good - if it stops crashes :D
17:25.30russellbheh, well it's exactly that ...
17:25.42russellba signal handler for SIGSEGV that does nothing ...
17:26.07ZX81MX?
17:26.08putnopvutStill wouldn't help with SIGABRT though :)
17:26.13russellbheh
17:26.25Corydon76-digccesario: Please refer to bug numbers, not download links
17:26.58ccesarioCorydon76-dig, ok... sorry
17:27.15ZX81russellb: where would I find that patch?
17:28.00ZX81malloc_debug safe for production?
17:28.07ZX81ish?
17:28.08ZX81:)
17:31.41russellbmalloc debug is safe
17:31.45russellbbut it will not prevent crashes
17:32.34russellbZX81: don't know if it's posted anywhere
17:32.37russellbit was only half-serious
17:32.42russellbbecause it likely wouldn't help
17:33.28russellbit might catch the signal, but the process will come down in flames for other reasons most likely
17:33.45ZX81kk
17:34.12ZX81heh running in valgrind doesn't include screen
17:34.32festr_hi
17:34.33ZX81if I'm going to run for a while screen means I can disconnect
17:34.37festr_i've the same issue
17:34.40festr_:)
17:34.48putnopvutfestr_: yeah, i saw your note on that issue.
17:34.56festr_and if you need, I can help. I've also some expirience in valgrind
17:34.56ZX81I'm in valgrind now
17:35.13ZX81same - all of SmoothTorque runs permanently in valgrind :D
17:35.21putnopvutfestr_: all right, have you tried using the patch that's attached to the issue.
17:35.30lmadsenM14226
17:35.32MuffinMan[acknowledged] [Asterisk] General 0014226: crash in comparation with 'nothing' reported by caspy (Karma: +5.75) http://bugs.digium.com/view.php?id=14226
17:35.47lmadsenCorydon76-dig: can I assign that to you? I've reproduced the issue. I'm going to attach a backtrace shortly.
17:36.20festr_putnopvut: i've looked at it but now i dont. I'm not able to reproduce the issue by my self. I have to wait on production system to crash. I'll try to isolate it and reproduce. Once I can handle this I'll try patch and do valgrind.
17:36.38putnopvutfestr_: thanks very much
17:36.46festr_ZX81: are you able to reproduce?
17:36.51ZX81nah
17:36.55ZX81production crash
17:36.56ZX81:)
17:37.00ZX81loverly
17:37.00festr_same here
17:37.01ZX81:)
17:37.17festr_putnopvut: do you thing it is some racecondition or it could happen on one call too?
17:37.29ZX81I'm running patch and in valgrind
17:37.51putnopvutfestr_: I haven't yet figured that much out. valgrind output will likely tell me though :)
17:37.51Entomologist*** CLOSED (14229) [Addons/cdr_addon_mysql] [patch] Asterisk exits when trying to load cdr_addon_mysql.so
17:37.51EntomologistAssigned to: Corydon76
17:37.51EntomologistReported by: sergee  Karma: 60.5
17:37.51Entomologisthttp://bugs.digium.com/view.php?id=14229
17:37.51Entomologist*********************************************************
17:37.53lmadsencould it be load related?
17:38.25festr_lmadsen: i think not. on p4 with 1-3 calls with minimal load crashes very soon
17:38.31ZX81yes and no, the machine only sees like 20 simul calls
17:38.44ZX81but the machine has seen pauses in the past
17:38.54ZX81festr_: what motherboard?
17:39.06ZX81supermicro?
17:39.17putnopvutI doubt it's a mobo issue. It's probably just some bad code somewhere in Asterisk.
17:39.18festr_ZX81: it is irrelevant
17:39.25ZX81kk
17:39.42ZX81I've seen pauses on the supermicro
17:39.51ZX81which could make a race easier to trigger
17:40.01putnopvutah, interesting
17:40.19festr_putnopvut: i was able to always reproduce on a little older version (but I think not older than month) in this situation: Call in -> Queue -> SIP member -> 302 Moved temporarily to 14 -> Call Local/14 -> immidiately crashed
17:40.50putnopvutLet me try that.
17:40.54ZX81we're not using any local chans
17:41.11ZX81302 is call forwarding?
17:41.14lmadsenyes
17:41.17lmadsen302 Redirect
17:41.18festr_ZX81: nor me, but when SIP reply to INVITE 302 it will use Local channel
17:41.22ZX81yeah
17:41.28ZX81hence the q :)
17:41.51festr_ZX81: what is the last few lines from asterisk log before crashes?
17:42.02ZX81sec will check
17:42.12ZX81heh
17:42.17ZX81crashed at 4:20pm
17:42.20ZX81hmmm
17:42.26ZX81my server went for a smoke
17:42.27ZX81:D
17:42.46festr_ZX81: do you save logs verbose/debug ?
17:42.47lmadsenheh
17:43.04ZX81just checking log levels - had full last year for some reason
17:43.17ZX81messages => notice,warning,error
17:43.46putnopvutOne thing I just noticed is that there are some datastore operations done in app_queue without holding the channel lock. That seems bad.
17:44.28festr_ZX81: sometimes it is good to log debug => verbose,debug,notice,warning,error
17:44.43festr_ZX81: when there is trouble off course.
17:44.43ZX81yeah
17:44.51ZX81nothing in the logs
17:44.55ZX81will up the level
17:45.57ZX81k full -> debug
17:46.46festr_putnopvut: the last thing at the logs before crash is always DEBUG[27651]: chan_sip.c:3580 in sip_hangup: Hangup call SIP/crystalis
17:46.49festr_followed by
17:46.52festr_DEBUG[27651]: chan_sip.c:3362 in update_call_counter: State of SIP/crystalis changed - Caller: 774320231 <774320231>
17:48.00putnopvutHmm, that info doesn't really pertain to the crash.
17:48.02Entomologist*** CLOSED (14226) [General] crash in comparation with 'nothing'
17:48.02EntomologistAssigned to: Corydon76
17:48.02EntomologistReported by: caspy  Karma: 5.75
17:48.02Entomologisthttp://bugs.digium.com/view.php?id=14226
17:48.02Entomologist*********************************************************
17:48.12lmadsenCorydon76-dig: next time can you let me know you took the issue so I don't spend the time getting the backtrace... ?
17:48.38putnopvutI'm starting to think that the lack of locking around datastore operations in app_queue may be part of the problem. I'll definitely be fixing that. valgrind will tell us exactly what the problem is though
17:48.41Corydon76-diglmadsen: I took the issue and fixed it in less time than I could notify you
17:49.09festr_putnopvut: valgrind.. you mean after you fix queue locking or before?
17:49.18lmadsenCorydon76-dig: ya, but I spent more time on the issue that I could have been spending on other issues
17:49.47putnopvutfestr_: I'll upload a patch. If the crashes still occur, then you can give me the valgrind output.
17:50.03festr_putnopvut: what about previous patch you mentioned?
17:50.24lmadsencodefreeze-lap: could the patch you just put on 14122 help jmls at all?
17:50.42putnopvutThe previous patch definitely fixes some bad code. I will include the contents of the previous patch in the new one I upload. I'll be sure to add a note explaining that too.
17:50.44codefreeze-laplmadsen: No, I doubt it
17:50.49lmadsencodefreeze-lap: okie, thanks
17:50.51ZX81cool - I'm running in vg but would rather not - I'll try the patch you upload and then if it crashes again run in vg
17:50.55festr_putnopvut: and also I've this crashing versions on several other production servers without crashing. This server differs from other by queue usage
17:50.58Corydon76-diglmadsen: I think we collided on that issue, actually
17:51.11ZX81so I'll revert the previous before applying the new
17:51.52lmadsenCorydon76-dig: entirely possible
17:52.25festr_putnopvut: coool. anyway, I'll try to reproduce without patches. But you mentioned locking in queue datastore and I'm thining if it is possible to reproduce with one SIP client :)
17:53.05ZX81hmmm
17:53.15ZX81it may be nothing - but we have no crashes at lunch time
17:53.19ZX81i.e. 12-1pm
17:53.23ZX81both sides
17:53.30ZX81but only one staff online then
17:53.32festr_was there some calls?
17:53.36ZX81yeah
17:53.39festr_hm
17:53.47festr_it will be hard to reproduce
17:53.49festr_than
17:53.53ZX81yah
17:54.37festr_ok, leaving home thanks guyes will try later
17:54.53ZX81sweet
17:56.16ZX81brb ciggy
17:57.33lmadsenjpeeler: APPLICATION WARNING #300: String "needs_license_bug_title" not found.
17:57.37lmadsenjpeeler: should I file a bug for that?
17:57.57jpeelerno, i'll just fix it really quickly, but where did you see tehat?
17:58.33lmadsenwhen I went into bug 14232 and clicked on the Change Status To: button after selecting "Needs License"
17:59.14lmadsenZX81: new patch attached for you on 14086
17:59.42putnopvutfestr_: ZX81: I have uploaded a new patch to issue 14086
17:59.55putnopvutLet me know if it helps. I'm headed out for a little while.
17:59.57lmadsenputnopvut: lol... I'm too quick for ya :)
18:00.47putnopvutlmadsen: oops, I should pay attention to what you write :)
18:00.47lmadsenputnopvut: don't make that mistake again
18:01.31Corydon76-digPay attention to what you write?  Madness!
18:02.22lmadsenCorydon76-dig: that's why they call me Mad Madsen!
18:02.28lmadsenM14178
18:02.31MuffinMan[ready for testing] [Asterisk] General 0014178: CLI hang and unresponsive when issuing "show channels" or "core show channels" reported by greenfieldtech (Karma: +14.50) http://bugs.digium.com/view.php?id=14178
18:02.33lmadsenanyone want to merge that in?
18:03.57ZX81putnopvut: will apply now
18:04.55lmadsenhey, who wants an autoconf problem?!
18:05.11lmadsenthinks he will assign to putnopvut so he can "learn some new stuff" (unless someone else speaks up)
18:05.16lmadsenM14224
18:05.18MuffinMan[new] [Asterisk] Core/BuildSystem 0014224: [patch] fixes for autoconf 2.63 and ptlib-devel (Fedora 10) reported by bergolth (Karma: +0.25) http://bugs.digium.com/view.php?id=14224
18:09.05Entomologist*** CLOSED (13879) [PBX/pbx_dundi] DUNDi queries/lookups from 32-bit to 64-bit machine fails; 64-bit to 32-bit operations OK
18:09.05EntomologistAssigned to: russell
18:09.05EntomologistReported by: akkornel  Karma: 0.25
18:09.05Entomologisthttp://bugs.digium.com/view.php?id=13879
18:09.05Entomologist*********************************************************
18:20.42*** join/#asterisk-bugs ZX81_ (i=ZX81@124.6.218.246)
18:20.51ZX81_production traffic starting up with patch in place
18:21.56ZX81_my internet died, so am on 3G
18:21.58ZX81_:)
18:22.28lmadsenrussellb: do you consider all these "1.4.22 broke my CDRs" bugs to be 1.4.23 blockers?
18:23.07russellbprobably not ...
18:23.45ZX81_heh that reminds me - I have some calls which are originated with a timeout of 30 secs, length of 63 secs and disposition of noanswer (last app executed was 5 lines after Answer app)
18:23.59lmadsenM14225
18:24.01MuffinMan[new] [Asterisk] Core/ManagerInterface 0014225: manager.c poll error reported by jangjun21 (Karma: neutral) http://bugs.digium.com/view.php?id=14225
18:24.06ZX81_not too much of an issue for me as we use UserEvent to process - but weird nonetheless
18:24.22lmadsenthere is a backtrace in the notes... perhaps someone can see how to fix that one quick?
18:24.30lmadsenrussellb: ok thanks, just wanted to check
18:33.01*** join/#asterisk-bugs ZX81 (i=ZX81@124.6.218.246)
18:34.16Entomologist*** CLOSED (14176) [Channels/chan_sip/Registration] [patch] send out the incorrect register request URI to the (fromdomain) outbound proxy
18:34.16EntomologistAssigned to: otherwiseguy
18:34.16EntomologistReported by: paraeco  Karma: 0
18:34.16Entomologisthttp://bugs.digium.com/view.php?id=14176
18:34.16Entomologist*********************************************************
18:40.02*** join/#asterisk-bugs oej (n=olle@ns.webway.se)
18:41.22lmadsenoej:
18:41.36lmadsenM14230 if you would care to comment on whether that functionality is something we need/want
18:41.41lmadsenM14230
18:41.43MuffinMan[acknowledged] [Asterisk] Channels/chan_sip/General 0014230: Calls are not accepted from an outbound proxy reported by Nick_Lewis (Karma: +1.00) http://bugs.digium.com/view.php?id=14230
18:41.44lmadsenoops :)
18:42.32*** join/#asterisk-bugs ZX81_ (n=matt@202.20.97.211)
18:45.45oejlmadsen: That outbound proxy stuff is not a bug report. It's someone who needs to learn more from your book.
18:46.52lmadsenoej: that's what I was kinda thinking... but I have not used outboundproxy in many moons! :)
19:02.54*** join/#asterisk-bugs ZX81 (n=matt@202.20.97.211)
19:05.06festr_ZX81: hi, still crashing?
19:05.10festr_after patch?
19:05.18ZX81not yet
19:05.21ZX81only a few calls in
19:05.25ZX812 agents logged in
19:05.38ZX81will rise to 15 agents
19:05.41festr_how often it crashes without patch?
19:05.42ZX818:05am here
19:05.58ZX81yesterday 5 times
19:06.12ZX81first crash yesterday wasn't till 11:10am
19:06.20festr_so if there will be no crash during while day we can consider it is fixed :)
19:06.28ZX81yah
19:06.32festr_it starts crashing after upgrade?
19:06.45ZX81it crashed once last year
19:06.53ZX81was recommended an upgrade
19:06.58ZX81then it started crashing
19:07.06ZX81hasn't actually crashed that many times all up
19:07.15festr_understand
19:07.19ZX81yesterday was kinda bad though
19:08.33ZX81going out for a ciggy again :)
20:12.51putnopvutlmadsen: I hereby state that you are not allowed to assign any new issues to me.
20:12.58putnopvutI have 25(!) assigned to me right now.
20:13.12lmadsenputnopvut: maybe you should work faster?
20:13.15lmadsenducks
20:13.23lmadsenputnopvut: you're right though... that is clearly too many issues
20:13.25putnopvutaw hell naw
20:13.56putnopvutin all fairness there are probably about 5 that are just waiting for some sort of feedback before I can close them.
20:14.04lmadsenyep
20:14.14lmadsenthere are a few in there right now marked as Ready For Review I think
20:15.37ZX81putnopvut: hopefully you'll be able to close out mine by the end of my day - 8 hours from now :D
20:16.08putnopvutZX81: yeah, I consider that one to be high-priority since it is a crash that is happening multiple times, daily.
20:16.33putnopvutAnd I think that issue may be the same as 14043, so when I close yours, I can also close 14043.
20:18.08ZX81saweeet
20:54.12lmadsenputnopvut: I like when that happens!
20:54.19putnopvutYes.
20:55.36lmadsenputnopvut: let me know when I can start assigning issues to you again! :)
21:18.15Entomologist*** CLOSED (14198) [Channels/chan_sip/Registration] [patch] Not possible to register to a registrar via a host with different port number
21:18.15EntomologistAssigned to: putnopvut
21:18.15EntomologistReported by: Nick_Lewis  Karma: 1
21:18.16Entomologisthttp://bugs.digium.com/view.php?id=14198
21:18.16Entomologist*********************************************************
21:18.29putnopvut1 down, 24 to go
21:20.14seanbrightgo putnopvut, go!
21:20.22putnopvutha
21:21.29QwellM14230
21:21.31MuffinMan[acknowledged] [Asterisk] Channels/chan_sip/General 0014230: Calls are not accepted from an outbound proxy reported by Nick_Lewis (Karma: +1.00) http://bugs.digium.com/view.php?id=14230
21:21.33QwellShould that be closed then?
21:23.23putnopvutI just did :)
21:23.29putnopvutNice timing
21:26.34oejputnopvut: That port number was really not needed in register=
21:26.49putnopvutoej: why do you say that?
21:26.52oejputnopvut: Instead of having all data in one register= line, which will never happen, people need to refer to a peer
21:26.54festr_ZX81: still no crash?
21:26.59oejand in a peer section you can configure everything
21:27.33oejWe can't add all options to register= and my direction was to move away from that. The syntax is way too confused already and doesn't need more confusion.
21:27.58oejThere's no way we can configure everything in a oneliner
21:28.05putnopvutI wasn't aware of the ability to specify a peer that the register referred to.
21:28.19oejputnopvut: Maybe you should attend one of Jared's classes :-)
21:28.24putnopvutheh :)
21:28.34oejregister= checks for a peer first, then checks in DNS
21:28.41oejSo using a peer works perfectly ok.
21:28.59oejMy suggestion is really to test if that works, and if it works, just revert that change.
21:29.10oejIf it doesn't work, make it work through a peer section :-)
21:29.39oejYou can also add register=yes to a peer - in that case, you won't need a register= at all.
21:30.08oejI don't like all that transport stuff and expiry on the register= line either. It's bad architecture.
21:30.12oejBut that's another issue to fight.
21:30.20oejPlease consider my feedback :-)
21:30.22oejGood night
21:30.30putnopvutAll right, have a nice evening!
21:30.50putnopvutI agree, if the functionality is already there a different way, then I don't need to confuse matters more.
21:31.16oejWe should simplify that part of the configuration :-) Let's work on that. But not tonight :-)
21:35.05mvanbaakthe 'register=yes' stuff is great
21:35.22mvanbaakmade it possible to register a peer with a # in the password for me
21:45.15putnopvutI need to look at how that register=yes stuff works.
21:48.13putnopvutugh, it's not documented
21:48.31russellbclearly you should have known that it existed, putnopvut
21:48.36russellbyou have the source
21:48.47putnopvutI don't even see it in the source >_<
21:49.05russellbum, you're right
21:49.11russellbit's not in trunk, at least ..
21:49.24russellboh, I don't think it's register=yes
21:49.27russellbit's like ...
21:49.43russellbyou make a regular register = line that is just register => 1234@peer
21:49.44putnopvutI see callack = blah as a potential way of doing it.
21:49.46russellbor something like that
21:50.24lmadsenrussellb: I believe you are right
21:50.34russellbi don't remember the exact syntax, but it's along those lines
21:50.36lmadsenI've never heard of register=yes
21:50.44russellbwhere you are referencing the peer entry in the register => line
21:50.48lmadsenya... where peer == [peer_in_braces]
21:50.57putnopvutthat makes a bit more sense.
21:51.23putnopvutI still don't see how I could have solved that issue that oej barked at me about without the patch though.
21:51.42russellbis there a port option for peer entries?
21:51.46putnopvutthere is.
21:51.51putnopvutBut not two different ones.
21:51.56russellbshrugs
21:52.10putnopvutAnd that's what was being solved with that patch.
21:52.19putnopvutalthough...
21:52.29putnopvutnevermind
21:53.24putnopvutNope, I think that at least *part* of that patch was necessary, because of the ambiguities of specifying a username inside a peer entry with a port number in it.
21:53.34putnopvutI'll talk with oej about it more when he's back on-line.
21:53.41ZX81festr_: yeah looking good so far
21:54.59*** join/#asterisk-bugs sysreq (n=sysreq@unaffiliated/sysreq)
21:55.26lmadsenya... basically he's going to want you to implement the functionality in the peer I guess instead of in the register line... so you might need a new option... like remote_port or something equally silly
21:55.43ZX81putnopvut: oej may have been referring to users.conf
21:55.56lmadsenI doubt it...
21:56.00russellbZX81: I seriously doubt it
21:56.07russellbhe doesn't like users.conf.
21:56.12ZX81ah
21:56.13ZX81:)
21:56.16lmadsenas I've read on several bugs :)
21:56.29putnopvutI don't think anyone really "likes" users.conf though :)
21:56.57lmadsenheh... it's useful for the gui..
22:05.09*** join/#asterisk-bugs bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net)
22:05.09*** mode/#asterisk-bugs [+o bbryant] by ChanServ
22:07.53putnopvutlmadsen: ping
22:08.25putnopvutI haven't heard from the reporter of 13644 in a while, and I was wondering if you had the capability to see if the issue still exists.
22:10.32lmadsenputnopvut: pong
22:10.40lmadsenM13644
22:10.42MuffinMan[feedback] [Asterisk] Channels/chan_sip/General 0013644: insecure doesn't work reported by pj (Karma: +9.00) http://bugs.digium.com/view.php?id=13644
22:11.13putnopvutI'm going through  my backlog and that's one that I saw.
22:12.58lmadsencoolio.. I will assign to me which will note for me to test
22:13.55lmadsenI still have an issue with realtime users in trunk which I need to delve into deeper, but there are a couple of bugs open for it.
22:16.18ZX81putnopvut: have to go into meeting now - been stable so far (touch wood) - but will update the tracker issue by the end of the day
22:16.36putnopvutZX81: that's fine. Take as much time as you need.
22:16.53ZX81:)
22:17.59putnopvutM14018
22:18.01MuffinMan[feedback] [Asterisk] Channels/chan_sip/Registration 0014018: [patch] Registrations using a username without domain will fail. reported by nmav (Karma: neutral) http://bugs.digium.com/view.php?id=14018
22:18.08putnopvutIt's been nearly a month. Close?
22:19.27lmadsenI'll close it
22:20.00putnopvutThanks.
22:20.27Entomologist*** CLOSED (14018) [Channels/chan_sip/Registration] [patch] Registrations using a username without domain will fail.
22:20.27EntomologistAssigned to: putnopvut
22:20.27EntomologistReported by: nmav  Karma: 0
22:20.27Entomologisthttp://bugs.digium.com/view.php?id=14018
22:20.27Entomologist*********************************************************
22:20.35putnopvutswank
22:24.11lmadsenputnopvut: another one unassigned from you!
22:24.12lmadsen:)
22:24.18putnopvutgood
22:25.37putnopvutha! I never had even noticed issue 14172 was assigned to me :)
22:25.43putnopvutFinally, a trivial one!
22:31.01Entomologist*** CLOSED (14172) [Applications/app_queue] [patch] changing the annoying "no one is answering queue" message level
22:31.01EntomologistAssigned to: putnopvut
22:31.01EntomologistReported by: caio1982  Karma: 49
22:31.01Entomologisthttp://bugs.digium.com/view.php?id=14172
22:31.01Entomologist*********************************************************
22:44.57*** part/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-757a7d80f3298645)
22:45.23*** part/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb)
22:48.15seanbrightlmadsen: i made something for you
22:49.09*** join/#asterisk-bugs SeansAsteriskBot (n=sbright@205.232.40.114)
22:49.12seanbrightmantis project list
22:49.27SeansAsteriskBot[Mantis] Asterisk (305), Asterisk-GUI (4), AsteriskNOW (3), DAHDI-linux (25), DAHDI-tools (3), Gastman (0), LibPRI (11), LibSS7 (7), Mantis (2), Repotools (0), Zaptel (7)
22:51.00lmadsenseanbright: that depresses me :)
23:00.29Entomologist*** CLOSED (14222) [Core/General] [patch] Add config option to disable console connect messages
23:00.29EntomologistAssigned to: otherwiseguy
23:00.29EntomologistReported by: jamesgolovich  Karma: 87.5
23:00.29Entomologisthttp://bugs.digium.com/view.php?id=14222
23:00.29Entomologist*********************************************************
23:00.38*** join/#asterisk-bugs telecos (n=sergio@34.167.219.87.dynamic.jazztel.es)
23:05.45Entomologist*** CLOSED (14190) [Core/HTTP] POST files are not truncated
23:05.45EntomologistAssigned to: otherwiseguy
23:05.45EntomologistReported by: timking  Karma: 0
23:05.45Entomologisthttp://bugs.digium.com/view.php?id=14190
23:05.45Entomologist*********************************************************
23:21.09otherwiseguymatis project list
23:21.14otherwiseguymantis project list
23:21.25otherwiseguyDoh, the bot has left the room. :-)
23:46.02Entomologist*** CLOSED (14103) [General] dahdi_monitor audio level meters are cut off halfway
23:46.02EntomologistReported by: gork  Karma: 1.75
23:46.02Entomologisthttp://bugs.digium.com/view.php?id=14103
23:46.02Entomologist*********************************************************
23:46.55seanbrightheh
23:47.49*** join/#asterisk-bugs SeansAsteriskBot (n=sbright@205.232.40.114)
23:47.53seanbrightotherwiseguy: i brought him back ^^^
23:47.56seanbrightmantis project list
23:48.11SeansAsteriskBot[Mantis] Asterisk (304), Asterisk-GUI (4), AsteriskNOW (3), DAHDI-linux (25), DAHDI-tools (2), Gastman (0), LibPRI (11), LibSS7 (7), Mantis (2), Repotools (0), Zaptel (7)
23:50.44otherwiseguywoot.
23:51.32seanbrighti wonder if there is a way in freenode to give a user /topic permission without op'ing them
23:51.43seanbrightif so, we can have him auto update the topic from time to time
23:56.19seanbrightcitats: i'm testing something, can you /msg ChanServ FLAGS #asterisk-bugs SeansAsteriskBot +t
23:57.47Entomologist*** CLOSED (12887) [Channels/chan_misdn] [patch] chan_misdn.c threadsafe patch
23:57.47EntomologistAssigned to: crich
23:57.47EntomologistReported by: pputman  Karma: 6
23:57.48Entomologisthttp://bugs.digium.com/view.php?id=12887
23:57.48Entomologist*********************************************************

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.