IRC log for #asterisk-bugs on 20080415

06:57.16*** join/#asterisk-bugs oej (n=olle@bkkb-gw.voop.net)
07:19.36*** join/#asterisk-bugs oej_ (n=olle@bkkb-gw.voop.net)
08:49.21*** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it)
10:31.26*** join/#asterisk-bugs mbranca (n=matteo@mi-gw1.voismart.net)
10:36.18*** join/#asterisk-bugs magumbade (n=magumbad@p5497BFA6.dip.t-dialin.net)
12:04.29*** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982)
13:08.39*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
13:08.39*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
13:33.07*** join/#asterisk-bugs mbranca (n=matteo@mi-gw1.voismart.net)
13:35.53*** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir)
13:46.54*** join/#asterisk-bugs Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844)
14:05.19jsmithM12449
14:05.20MuffinMan[new] [Asterisk] Applications/app_voicemail 0012449: app_voicemail doesn't correctly handle multiple names assigned to a mailbox reported by jsmith  http://bugs.digium.com/view.php?id=12449
14:05.41jsmithI love starting the day with a bug report
14:08.19Juggiehah.
14:28.13jsmithJuggie: You laughing at me?
14:28.35jsmithpicks a fight with Juggie
15:06.46*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
15:06.46*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
15:17.35*** join/#asterisk-bugs elguero (n=elguero@ns1.nashuacs.com)
15:19.42*** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1)
15:19.42*** mode/#asterisk-bugs [+o putnopvut] by ChanServ
15:20.02Corydon76-digputnopvut: you've been nominated
15:20.08putnopvutuh oh...
15:20.15Corydon76-digM12450
15:20.16putnopvut"nominated" or "voluntold"
15:20.17MuffinMan[new] [Asterisk] PBX/General 0012450: It happens when the calls reach more than 100 calls reported by falves11  http://bugs.digium.com/view.php?id=12450
15:20.26putnopvutHow...descriptive.
15:20.28Corydon76-digOur favorite reporter
15:21.16putnopvutI love it. "Please see the valgrind capture" and he posts backtraces from gdb.
15:21.36putnopvutAnd it's just ... more crashes in poll()
15:22.17Corydon76-digWanna bet that he's still running third party apps?
15:23.55putnopvutI didn't know he had been doing that.
15:25.16jpeelerjust out of curiosity, does BE prevent running third party apps?
15:25.36Corydon76-digjpeeler: it does not
15:26.03jpeeleri guess not that many people do that anyway
15:26.05*** join/#asterisk-bugs seanbright (i=seanbrig@65.207.74.18)
15:26.05Corydon76-digjpeeler: but it will now prevent you from running objects not compiled with the same flags
15:26.19jpeelerCorydon76-dig: that's helpful
15:30.05Corydon76-digSo will Asterisk-1.4, in fact
15:30.15fileno facts allowed.
15:30.42Corydon76-digtickles file silly
15:49.40lmadseno.O
15:54.55Corydon76-diglmadsen: IOW, not at all.  He was already silly
15:55.06filefalls over
16:59.12putnopvutM11999
16:59.15MuffinMan[feedback] [Asterisk] Core-General 0011999: memory leak reported by destiny6628  http://bugs.digium.com/view.php?id=11999
16:59.34putnopvutThe valgrind output shows that in app_dial, there are cases where we call ast_hangup on the outbound channel.
16:59.47putnopvutIf that channel is a ZAP channel with a DSP, we free the DSP in the hangup call.
17:00.15putnopvutThe frame that we got in ast_read earlier came from that DSP, so later, when we call ast_frfree on that frame, we are reading from and writing to freed memory.
17:00.45fileeep
17:01.03putnopvutAt least that's my interpretation of it (and I'm pretty sure I'm right)
17:01.11*** join/#asterisk-bugs Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844)
17:01.55*** join/#asterisk-bugs ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br)
17:37.54*** join/#asterisk-bugs ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br)
17:45.45*** join/#asterisk-bugs elguero (n=elguero@ns1.nashuacs.com)
18:27.00Qwelljsmith: the problem with the old way, is that it was actually creating duplicate entries for the same mailbox in app_voicemail
18:27.28jsmithQwell: Right... duplicate entries in memory, right?
18:27.33Qwellyes
18:27.51jsmithQwell: That was the goal... so that you could call Directory() and it would find *any* of the listed names
18:27.53Qwellapp_directory doesn't care.  it's just going to get the first box it finds with that name
18:28.00Qwellit doesn't use the list in memory
18:28.05jsmithOh?
18:28.37Qwellit reads the config file as needed
18:29.29jsmithSo, then... what's the recommended way to add duplicate names to a mailbox for app_directory to be able to find them?
18:30.00Qwellyou mean without adding a way to specifically add aliases? :D
18:30.12Qwell123 => 1111,Bob
18:30.14Qwell123 => 1111,Alice
18:30.21*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
18:30.21*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
18:30.38Qwellthough, I don't think you'll get the expected name/options there
18:31.32jsmithQwell: If I do that, Directory() works just fine, but if Alice changes her PIN, then we're in trouble
18:31.48QwellI would've expected that to always be the case
18:32.07Qwellthough I guess it would stop at the first match for mailbox
18:32.35Qwellideally, you want an alias => 123,Alice feature for app_directory
18:32.47Qwellfair statement?
18:33.22jsmithSure!
18:36.49Corydon76-digThat could be done
18:36.57Qwelltrying something for that now
18:37.00Qwellshould be easy
18:37.21Corydon76-digJust need to make sure that we ignore it for app_voicemail
18:37.25Qwellright
18:37.39Corydon76-digProbably in append_mailbox()
18:47.38Qwelldoes directory even work in 1.6? O.o
18:47.56Corydon76-digYes, with some new enhancements
18:48.16QwellDirectory(default) isn't finding my user...
18:48.38*** join/#asterisk-bugs oej (n=olle@212.33.142.229)
18:48.55Corydon76-digBy last name?
18:49.02Qwellboth names are "Blah"
18:49.07Qwell252 finds nothing
18:49.46Qwell5555 => 5555,Blah Blah,jparker@digium.com
18:49.48Corydon76-digHmmm
18:50.37Corydon76-digIn the meantime, try l(3) as the 3rd argument to directory
18:51.31Qwellnothing
18:52.00Qwellexten => 6028,1,Directory(default,,l(3))
18:52.59Corydon76-digWeird... my test was using Directory(default,digium,f(2))
18:53.07Qwellwhat's the second arg?
18:53.20Corydon76-digcontext in which to dial the extension
18:53.26Qwelloh
18:53.26jsmithQwell: The context in the dialplan in which to dial the extension
18:53.44jsmithDirectory(vm-context,dialplan-context,options)
18:55.32Corydon76-digHuh, not working for me now, either
19:00.12jsmithQwell, Corydon76-dig I broke it for both y'all?
19:00.25jsmithblinks in disbelief... twice...
19:02.31Corydon76-digHang loose
19:02.38*** join/#asterisk-bugs elguero (n=elguero@66.251.53.194)
19:03.16Corydon76-digI'm trying something to check
19:15.39Corydon76-digOkay, that didn't work
19:17.02*** join/#asterisk-bugs tuxd00d (n=tuxd00d@128.187.132.25)
19:21.04Corydon76-digQwell: figured it out
19:21.27Corydon76-digIf you enter digits while the prompts are playing, it finds no match.  If you wait until the prompts are done, it works perfectly
19:21.34QwellO.o
19:32.04Corydon76-digsomething in the core, I guess.  Where, I don't know
19:45.56*** join/#asterisk-bugs mvanbaak_ (n=michiel@vanbaak.xs4all.nl)
20:00.25*** join/#asterisk-bugs ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br)
20:06.03*** join/#asterisk-bugs Corydon76-dig (i=gray@pdpc/supporter/bronze/Corydon76-home)
20:06.03*** join/#asterisk-bugs jpeeler (n=jpeeler@216.207.245.1) [NETSPLIT VICTIM]
20:06.03*** mode/#asterisk-bugs [+o Corydon76-dig] by ChanServ
20:20.19*** join/#asterisk-bugs oej_ (n=olle@212.33.142.229)
20:27.08QwellA114149
20:27.10MuffinMan[114149] Committed by  on :
20:27.11QwellCorydon76-dig: ^^
20:27.19Qwellerm
20:28.16Qwellmirror is taking it's sweet time
20:28.34QwellA114149
20:28.36MuffinMan[114149] Committed by qwell on 2008-04-15 17:27:04: If somebody enters a digit during ast_stream_and_wait, the return value is the digit, which we need to use later.
20:29.04QwellCorydon76-dig: it was ||ing a bunch of ast_stream_and_wait() calls
20:31.48Corydon76-digQwell: it wasn't keeping it?
20:32.03Corydon76-dig|| should keep it
20:32.03Qwellres = ast_stream_and_wait() || ast_stream_and_wait()
20:32.09Qwellit was 1
20:32.17Qwellres = (ast_stream_and_wait() || ast_stream_and_wait())
20:32.19Qwellclearer
20:32.30Corydon76-digOh...
20:32.34Qwellsubtle
20:32.46Corydon76-digYeah, I'm used to Perl, where that works...
20:32.48Qwellres = ast_stream_and_wait() || res = ast_stream_and_wait()
20:32.53Qwellthat might've worked, but..*shrug*
20:33.17Corydon76-digDamn, that sucks
20:33.21Qwellfix was simple once I found it.  I was banging my head trying to figure out why it worked when I set directoryintro=dirintro
20:34.36Corydon76-digWe should try the (res = ...) || (res = ...)
20:34.50QwellI'm sure that'd work
20:34.51Corydon76-digI was looking for elegant logic
20:36.39Corydon76-digWell, thank you for figuring it out, though
20:37.22Qwellit isn't liking the ||.  error: invalid lvalue in assignment
20:37.35Corydon76-digCrud
20:37.40Corydon76-digOh well
20:37.43Qwelllots of places do it like this
20:38.03Qwellideally...
20:38.14Qwellthat function should be able to take multiple prompts
20:38.31Corydon76-digActually, we could just macroize it...
20:40.13Corydon76-digor... if ((res = ...) || (res = ...) || (res = ...)) { /* Nada */ }
20:41.18*** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir)
20:47.18Corydon76-digYes, it likes that syntax fine
20:47.46putnopvutM11999
20:47.49MuffinMan[feedback] [Asterisk] Core-General 0011999: memory leak reported by destiny6628  http://bugs.digium.com/view.php?id=11999
20:47.52putnopvuthttp://pastebin.ca/986482
20:48.06putnopvutBased on the valgrind output from that bug, I want to make the change in the pastebin above.
20:48.31putnopvutI've been discussing it some with file today, but I'd like to hear any naysayers' opinions just to be on the safe side before I commit that.
20:52.46Corydon76-digputnopvut: Actually...
20:53.13Corydon76-digRussell did something similar to that already, with the translation, I think
20:53.24Corydon76-digand my fix (which was wrong) was identical to yours
20:53.44putnopvutRussell's fix was sort of for the reverse problem if I recall correctly.
20:54.19putnopvutI thought he made a fix where translators were being freed but not the frame pointers inside the translators.
20:54.25Corydon76-digSame kind of problem... frame is part of a structure, which is freed while the frame is still in queue
20:54.34putnopvutAh, gotcha.
20:55.21Corydon76-digSo he set a flag inside the frame, when the translator was freed, to signal that when the frame is released, it should release the whole structure
20:55.22putnopvutI'll look a bit closer at Russell's translator fix.
20:55.46putnopvutNow, here's something that may be different...
20:55.58putnopvutI need to check the ast_translator struct to be certain.
20:57.23putnopvutCorydon76-dig: you're right, it appears to be the same.
20:57.31putnopvutLooks like I will be mimicking Russell for this fix.
20:58.19putnopvutThanks for the feedback. I would have hated to put the wrong fix in.
20:58.42fileyay for having peers
21:00.08Corydon76-digputnopvut: Now I have to wonder, in what other structures do we have embedded frames?
21:00.39putnopvutCorydon76-dig: 'twould be interesting to check.
21:00.48putnopvutMaybe try getting them all taken care of at once.
21:01.00Corydon76-digExactly
21:01.50putnopvutI suppose a cleverly crafted regex could maybe find those...
21:03.02jsmithUgh...
21:04.40Corydon76-digast_prod wouldn't be unsafe, would it?
21:05.15Corydon76-digYou're looking at the case in dsp.c right now, correct?
21:05.51Corydon76-digThere's one in the smoother in frame.c
21:06.39Corydon76-digAnd there's one in playtones_state, in indications.c
21:07.04Corydon76-digand there's one in struct ast_rtp
21:07.50Corydon76-digand 16 in struct ast_udptl in udptl.c
21:08.03putnopvutWhat is you're question regarding ast_prod?
21:08.21Corydon76-digast_write queues a frame, right?
21:08.29putnopvutyes.
21:08.39Corydon76-digbut that frame exists on the stack, so if the stack is quickly replaced, boom
21:09.09putnopvutno it doesn't exist on the stack to my knowledge.
21:09.16putnopvutI thought it queued a duplicate frame.
21:09.42Corydon76-digNope
21:09.55Corydon76-digNot in trunk as of a few minutes ago, anyway
21:10.01filequeue a frame? ast_write writes it out to the channel technology
21:10.24Corydon76-digfile: oh, so when ast_write returns, it's finished with the frame?
21:10.52filenods
21:11.01Corydon76-digOkay, so that one is safe
21:13.08Corydon76-digbut... smoother, indications... rtp... udptl...
21:13.45putnopvutThey all have embedded frames?
21:14.24Corydon76-digYeppers
21:14.32putnopvutSounds like we may need to change ast_translate_frame_freed into a macro that uses some typeof magic if possible.
21:14.50Corydon76-digNo, just multiple flags
21:14.58Corydon76-digOne for each type
21:15.13Corydon76-digudptl is going to be tricky, though, since there are 16 frames in an array there
21:15.15putnopvutyuck...
21:16.02putnopvutThat "yuck" was to the multiple flags comment.
21:16.27Corydon76-digmultiple flags isn't that bad
21:16.36putnopvutCorydon76-dig: well, it also may not be possible.
21:17.10Corydon76-digWhy not?
21:17.40putnopvutWell, I'm thinking about the case where a structure that embeds a frame is not exposed to the rest of the code.
21:18.00putnopvutI'm probably not being very clear here...
21:18.02Corydon76-digThat's why we need new API
21:18.16Corydon76-digjust like Russell did with the translator fix
21:48.15*** join/#asterisk-bugs dlynes (n=dlynes@216.251.149.69)
22:06.38putnopvutCorydon76-dig: Not sure if you saw but 12450 has valgrind output now, and ... I have to say I don't recognize any of that.
22:07.39fileyarrrrrr chan_h323
22:07.51putnopvutOne of the traces is showing stuff in chan_h323 apparently doing bad things, but other traces show non-asterisk things happening.
22:08.05putnopvutvalgrind4.txt for instance.
22:24.16Corydon76-digputnopvut: that's all h323 stuff
22:24.53putnopvutCorydon76-dig: yeah, I'm looking at one of the valgrind outputs right now. One that mentions an invalid free as the bottom-most violation.
22:25.00putnopvutThe problem is, I can't see how that free is invalid.
22:26.02Corydon76-digcould be memory corruption of the pointer
22:28.36Corydon76-digOh... the problem is that it's probably trying to free something already freed (and has been allocated to something else)
22:29.22Corydon76-digSee that the pointer is inside another block
22:32.11putnopvutI totally don't follow.
22:32.22putnopvutIt looks like a pointer is allocated, then it's freed.
22:32.32Corydon76-digAddress 0x1100c90c is 140 bytes inside a block of size 184 alloc'd
22:32.56Corydon76-digSo the pointer passed to free() was located inside another block
22:33.21Corydon76-digwhich we generally see with dangling pointers (after a region has already been freed)
22:33.35Corydon76-digand subsequently allocated by something else
22:33.39putnopvutOkay.
22:33.55putnopvutSo hmm, and this section of code is pretty compact so it shouldn't be too difficult to find the problem.
22:34.00putnopvut...hopefully...
22:35.45Corydon76-digProblem is, it could just as easily be somewhere off in h323 code
22:36.09Corydon76-digwhich is long since abandoned in favor of h323plus
22:39.16Corydon76-digWe could so do with refcounting in there, too
22:42.23putnopvutAre you talking about the h323 stuff?
22:42.29putnopvutrefcounting in there?
22:42.37Corydon76-digYes
22:42.44putnopvutInteresting idea.
22:42.48Corydon76-digIt's using the scheduler for DTMF
22:43.29Corydon76-digthough I'm mystified why that would matter... the scheduler never reschedules...
22:43.51Corydon76-diganyway
23:22.01*** join/#asterisk-bugs JunK-Y (n=junky@modemcable153.55-201-24.mc.videotron.ca)
23:22.01*** mode/#asterisk-bugs [+o JunK-Y] by ChanServ

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