| 00:00.17 | russellb | that's what i intended, thanks |
| 00:00.18 | russellb | :) |
| 00:12.09 | mvanbaak | ok I'm off now |
| 00:12.24 | mvanbaak | this JT is getting on my nerves |
| 02:18.17 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 02:18.17 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 02:19.10 | *** join/#asterisk-bugs russellb_ (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 02:19.10 | *** mode/#asterisk-bugs [+o russellb_] by ChanServ |
| 03:25.42 | *** join/#asterisk-bugs ZX81 (n=ZX81@202.20.97.211) |
| 04:31.03 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 04:31.03 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 07:07.11 | *** join/#asterisk-bugs ZX81 (n=ZX81@202.20.97.211) |
| 08:19.19 | *** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 11:09.19 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:15.08 | *** join/#asterisk-bugs magumbade (n=magumbad@p5497D570.dip.t-dialin.net) |
| 13:04.08 | *** join/#asterisk-bugs Victor_Yure (n=Victor_Y@esp5.deibotoch.com.br) |
| 13:34.19 | *** join/#asterisk-bugs miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 14:14.27 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:14.27 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 14:24.47 | *** join/#asterisk-bugs umay (n=chris@71-208-162-10.hlrn.qwest.net) |
| 14:29.59 | *** join/#asterisk-bugs kpfleming (n=kpflemin@216.207.245.1) |
| 14:29.59 | *** mode/#asterisk-bugs [+o kpfleming] by ChanServ |
| 14:45.06 | *** join/#asterisk-bugs kpfleming (n=kpflemin@216.207.245.1) |
| 14:45.06 | *** mode/#asterisk-bugs [+o kpfleming] by ChanServ |
| 15:10.14 | magumbade | jsmith: hi jared |
| 15:10.30 | magumbade | this is dorian |
| 15:10.46 | *** join/#asterisk-bugs jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 15:11.25 | jsmith | Hello magumbade |
| 15:11.36 | jsmith | magumbade: How was your flight back? |
| 15:11.58 | magumbade | long |
| 15:12.09 | magumbade | 4 hours in chariotte |
| 15:12.24 | magumbade | (the chairs are really good) |
| 15:12.28 | magumbade | and internet for free |
| 15:12.31 | magumbade | :-) |
| 15:12.42 | magumbade | thank you again for everything |
| 15:12.55 | magumbade | it was really great |
| 15:13.19 | jsmith | magumbade: Yeah, I ended up getting stuck in Charlotte as well... I'm glad you enjoyed the class |
| 15:13.44 | magumbade | now that I am back, I already have my first asterisk support case |
| 15:13.58 | *** join/#asterisk-bugs monkeytype (n=Bill@216.207.245.1) |
| 15:14.08 | magumbade | I asked the people on #asterisk but nobody can help me |
| 15:14.36 | magumbade | it is about Set(CALLERID(num)=123456789) sends only 12345 |
| 15:15.19 | magumbade | I am reading the source code now but on the first sight I can not discover any bugs |
| 15:15.34 | magumbade | the num is char[80] |
| 15:18.13 | magumbade | tested on B410P and a pri card |
| 15:18.42 | magumbade | ast_copy_string(buf, chan->cid.cid_num, len) seems to be ok |
| 15:18.50 | magumbade | any idea? |
| 15:20.52 | jsmith | No idea at all... must be something specific to BRI |
| 15:21.15 | jsmith | (I'm not sure if the pridialplan in zapata.conf setting makes a difference) |
| 15:21.57 | magumbade | it does not |
| 15:22.30 | magumbade | so..I should ask mulder&scully or beronet? |
| 15:22.39 | jsmith | I'd ask Beronet |
| 15:23.06 | jsmith | If someone would send me a B410P *and* a european BRI line to my house, I'd be able to help ;-) |
| 15:23.21 | jsmith | But considering I can't even get an American BRI line at my house, I'm out of luck |
| 15:23.47 | magumbade | the same happends with pri |
| 15:23.52 | magumbade | TE207P |
| 15:27.19 | magumbade | ok...I will try to ask someone from beronet....and I will let you know...for the docs |
| 15:48.27 | magumbade | wrote an email to beronet... |
| 15:48.44 | magumbade | I must tell you....you got me...I am an Asterista now... |
| 15:48.54 | magumbade | :-) |
| 15:48.56 | jsmith | w00t! |
| 15:50.13 | lmadsen | addictive stuff this asterisk |
| 15:50.40 | lmadsen | I need to get my mom to find me a lawyer at her office to get me a TN-1 visa so I can come help out with classes with jared again |
| 15:50.42 | magumbade | really true brother |
| 15:51.06 | lmadsen | or have more classes in Vancouver and Toronto :) |
| 15:51.30 | magumbade | coem to europe |
| 15:51.36 | magumbade | come to europe |
| 15:51.38 | lmadsen | I like europe |
| 15:51.47 | lmadsen | where do you reside magumbade ? |
| 15:52.01 | magumbade | germany/munich |
| 15:52.03 | jsmith | lmadsen: He's from Germany... |
| 15:52.12 | lmadsen | oooo! I like Germany |
| 15:52.19 | jsmith | lmadsen: He was in my class last week... came all the way over to Huntsville to try to see a tornado |
| 15:52.23 | lmadsen | Was in Berlin during World Cup for AstriCon |
| 15:52.23 | magumbade | but I was born in romania |
| 15:52.44 | magumbade | this was joerg...I was not that curious |
| 15:53.28 | magumbade | jsmith: remember the evening@markster ? |
| 15:53.58 | jsmith | magumbade: Of course! |
| 15:54.01 | magumbade | I got a cd from the son of sandrella...which I like very much (both, sandrella and the cd) |
| 15:54.04 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:54.04 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 15:54.18 | jsmith | magumbade: Yes, that band is called Thrice |
| 15:54.19 | magumbade | and no idea who is singing |
| 15:54.27 | magumbade | thank you |
| 15:55.00 | jsmith | magumbade: That album is called "Water", if I remember correctly |
| 15:55.24 | magumbade | you have it on your powerbook I think |
| 15:56.47 | jsmith | magumbade: Yes, I've got the files in ogg format here I think |
| 15:56.57 | jsmith | magumbade: The problem is that I have quite a bit of music on here ;-) |
| 15:57.18 | magumbade | lmadsen: the world cup was a really nice time |
| 15:57.20 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 15:57.34 | magumbade | and the weather...wow! nothing usual for germany |
| 15:59.10 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 15:59.10 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 16:01.58 | magumbade | jsmith: in fact...the bootcamp is only a scratch on the surface of what asterisk is and can.... |
| 16:02.04 | magumbade | like an iceberg |
| 16:02.22 | jsmith | magumbade: Exactly! |
| 16:02.23 | magumbade | 90% hidden....but really powerfull |
| 16:05.48 | magumbade | jsmith: 1Z 617 V13 67 4556 430 1 |
| 16:06.36 | magumbade | delivered today |
| 16:07.08 | jsmith | magumbade: Thank you very much ;-) |
| 16:07.10 | magumbade | still on the way |
| 16:07.16 | magumbade | I see now |
| 16:07.32 | magumbade | 3 phones...with sip and iax |
| 16:07.49 | magumbade | *1 dial over iax, *0 dial over sip |
| 16:08.13 | magumbade | but you can choose only one protocoll if you want |
| 16:08.51 | magumbade | u'r welcome |
| 16:09.01 | jsmith | magumbade: Very cool.. I can't wait to try them out |
| 16:09.23 | magumbade | we have a branch office in turkey |
| 16:09.40 | magumbade | vpn does not work because of the very poor quality dsl line |
| 16:11.29 | magumbade | now they talk over iax... |
| 16:12.00 | magumbade | (I had to take the transcoder card) because of the g729 |
| 16:12.14 | magumbade | the phone can not yet gsm |
| 16:12.29 | magumbade | only ulaw, alaw and g729 |
| 16:12.42 | jsmith | Yeah... I understand |
| 16:12.43 | magumbade | and because of the dsl line |
| 16:12.51 | magumbade | works prefect |
| 16:12.53 | jsmith | Most DSP chips used in phones don't support GSM |
| 16:13.07 | Qwell | jsmith: if they've got g729, what's the point? |
| 16:13.23 | Qwell | I mean...that sounded wrong. heh |
| 16:13.26 | jsmith | Qwell: That maybe the other end doesn't support g729? |
| 16:13.35 | Qwell | I'm not saying it's a good idea :) |
| 16:13.40 | jsmith | Qwell: I heard what you meant, and not what you said ;-) |
| 16:13.41 | magumbade | people will ask for gsm |
| 16:13.42 | Qwell | I was speaking as them..sort of. |
| 16:14.37 | Qwell | jsmith: I've noticed that hardware often support g729, whereas software supports gsm. I think it's pretty much assumed that if you're going to be using a phone with a system, that system will support g729 |
| 16:14.50 | Qwell | at least from their perspective |
| 16:15.02 | jsmith | Yeah... |
| 16:17.28 | caio1982 | Qwell: you said in 11771 that the fix would change the behavior buit i dont think it would... why it would change? it just correct the value, the format of it does not change (it's not the same from the CLI) |
| 16:17.33 | caio1982 | M11771 |
| 16:17.33 | MuffinMan | [closed] [Asterisk] Core/ManagerInterface 0011771: [patch] Wrong value in XML HTTP manager response reported by msetim http://bugs.digium.com/view.php?id=11771 |
| 16:17.44 | Qwell | because people could be relying on the information that is there now |
| 16:17.55 | Qwell | it's always been that way. Changing it now would be bad. |
| 16:19.04 | caio1982 | i understand... but the information is wrong, not the format... i mean, 222 (the agent) being reported as talkingto is different from 555, who's the real guy |
| 16:19.12 | Qwell | it isn't wrong |
| 16:19.30 | caio1982 | talkingto isn't the guy who the agent is talking to? |
| 16:19.32 | Qwell | it shows different information that the CLI command, but it isn't wrong. |
| 16:19.37 | Qwell | than* |
| 16:21.04 | magumbade | jsmith, lmadsen: bye...wireshark needs me...need to make a large trace |
| 16:21.08 | magumbade | cu |
| 16:21.16 | lmadsen | lates |
| 16:21.48 | jsmith | magumbade: Good luck! |
| 16:22.11 | caio1982 | Qwell: talkingto isn't the guy who the agent is talking to? or you meant that this info has been "inverted" like that since ever so it's better let it be to avoid problems in migration? |
| 16:23.07 | Qwell | see the patch that was put into trunk from 10102. it should make more sense |
| 16:26.42 | caio1982 | Qwell: ahh it does now, but just one more question: 'talkingto' is that patch shouldn't still be ast_bridged_channel(p->owner)->cid.cid_num instead of p->chan->cid.cid_num? |
| 16:30.12 | Qwell | probably |
| 16:31.20 | caio1982 | :) |
| 16:32.18 | caio1982 | Qwell: since svn is down, better I reopen it and just left a note there? |
| 16:32.21 | Qwell | the way it is now, you'd get the logged in callerid |
| 16:32.40 | Qwell | no, this is a different issue |
| 16:33.05 | Qwell | on that bug, he wants channel name. this isn't going to affect that at all |
| 16:34.03 | caio1982 | we didnt want the channel name, just callerid indeed... but it's not coming from ast_bridged_channel, that is |
| 16:34.23 | caio1982 | a new bug then? i didnt get it |
| 16:34.37 | Qwell | yes, new bug. this won't change msetim's issue |
| 16:35.33 | caio1982 | i guess we didnt explain it clearly, sorry then... i guess this is exactly what he expects (as far as he told me and what we tested) |
| 16:35.38 | caio1982 | Qwell: thank :) |
| 16:35.39 | caio1982 | s |
| 16:39.05 | caio1982 | oh, now i got it you won't really change it in 1.4, meh |
| 16:42.04 | caio1982 | Qwell: did you see info.txt attached to 11771? i dont wanna file a new bug just to bother... only to make sure it's really not going to be commited: in info.txt you see 400 as talkingto (which is an agent) but on CLI it's 'SIP/115-08513588' ... he wanted the manager to report '115' as talkingto, not 400, not 'SIP/115-08513588' neither |
| 16:42.16 | caio1982 | Qwell: that's what you understood? /me confused |
| 16:44.11 | caio1982 | the change from 10102 in trunk would change the 1.4 behavior, i know, but my patch does not change anything, just fix where the talkingto value is coming from, from 400 to 115 |
| 16:48.12 | Qwell | well |
| 16:48.18 | Qwell | so, here's the problem |
| 16:48.25 | Qwell | Say you're talking to SIP/bob |
| 16:48.40 | Qwell | CLI would show SIP/bob-111111 |
| 16:48.53 | Qwell | bob is *not* the callerid num, so it would still be different |
| 16:49.13 | Qwell | this might fix his particular case, but it would not fix the bug that he actually reported |
| 16:50.44 | caio1982 | CLI would show SIP/bob-11111 but the manager would show talkingto=my_agent_cid_num |
| 16:50.56 | caio1982 | maybe we just mixed up the issues and got lost |
| 16:51.35 | Qwell | his issue is that the manager and CLI should show the same thing. In the case of SIP/bob, it would mean seeing bob in the manager. The issue we're talking about, is who's callerid should be seen. |
| 16:58.15 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:58.16 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 16:58.16 | Qwell | caio1982: make sense? |
| 16:58.36 | caio1982 | Qwell: exactly, and it's reporting the agent's cid_num right now, it should be from ast_bridged_channel instead |
| 16:58.46 | Qwell | I would agree with that |
| 16:59.12 | caio1982 | can i reopen 11771 then? |
| 16:59.22 | Qwell | that's still a different issue |
| 16:59.45 | caio1982 | i guess msetim just misunderstood the issue and reported it wrong, really |
| 16:59.48 | Qwell | it's a very subtle difference if you're using numeric SIP accounts (there is no difference at all, actually). but if you use non-numeric, it is different |
| 17:00.08 | caio1982 | if it'snot numeric it then would be 'n/a', right? |
| 17:00.16 | Qwell | no, it would be "bob" |
| 17:00.29 | caio1982 | but would change the behavior... it already uses cid.cid_num |
| 17:00.36 | Qwell | exactly :p |
| 17:00.50 | caio1982 | Qwell: i guess we have been talking the same thing for minutes hahah |
| 17:01.05 | Qwell | there's a very fine line between the issue that I feel was reported, and the issue we discovered |
| 17:02.06 | caio1982 | Qwell: the problem is that i talked on phone to msetim and I'm pretty sure he didnt explain it very well, what we've been talking about is his problem, the other issue discovered is not what he found (the problem with non-numeric cids if i got it right) |
| 17:02.26 | Qwell | is 11771 not the same as 10102? |
| 17:02.31 | caio1982 | no |
| 17:02.47 | Qwell | I read his report as "the manager event and CLI should match", which is what 10102 was |
| 17:03.17 | caio1982 | match as in "the same cid.cid_num" not "the same whole information from cli" |
| 17:03.25 | caio1982 | same cid.cid_num not being the agent's |
| 17:03.27 | Qwell | k, sounds like a language issue then |
| 17:03.34 | caio1982 | Qwell: i'm sorry for that :/ |
| 17:03.40 | Qwell | no worries :) |
| 17:04.00 | Qwell | I will reopen |
| 17:08.07 | Qwell | done |
| 17:08.53 | caio1982 | Qwell: just noticed, thank you! can i ping you when svn is up again or you want to think more about this? |
| 17:08.58 | caio1982 | :) |
| 17:10.27 | Qwell | caio1982: yeah |
| 17:10.35 | Qwell | remind me later |
| 17:11.14 | caio1982 | ok... now, to the mr. jobs keynote's live coverage |
| 17:11.48 | Qwell | aren't they supposed to be announcing...umm...something? |
| 17:11.57 | Qwell | I forget what it was now |
| 17:12.05 | caio1982 | macbook air |
| 17:12.10 | caio1982 | sub-notebook or kind of |
| 17:12.24 | Qwell | right |
| 17:14.30 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 18:33.39 | *** join/#asterisk-bugs kpfleming (n=kpflemin@216.207.245.1) |
| 18:33.39 | *** mode/#asterisk-bugs [+o kpfleming] by ChanServ |
| 18:34.17 | Qwell | M11243 |
| 18:34.19 | MuffinMan | [new] [Asterisk] Codecs/codec_gsm 0011243: Distortion in Playback of .gsm files over non-GSM channel reported by whiskerp http://bugs.digium.com/view.php?id=11243 |
| 18:34.25 | Qwell | Corydon76-dig: See that patch? It's cheeky, but... |
| 18:45.34 | putnopvut | Is it the one that does -O2 instead of -O6? |
| 18:45.46 | Qwell | yeah |
| 18:46.11 | putnopvut | If I actually knew the differences between those, I'd comment, but I don't so... |
| 19:00.36 | *** part/#asterisk-bugs magumbade (n=magumbad@p5497D570.dip.t-dialin.net) |
| 19:28.30 | *** join/#asterisk-bugs ZX81 (n=ZX81@202.20.97.211) |
| 19:37.56 | ZX81 | hi, someone has uploaded a show locks output for M11181 |
| 19:38.03 | ZX81 | M11181 |
| 19:38.04 | MuffinMan | [new] [Asterisk] Core/ManagerInterface 0011181: Manager API hangs on "Command: show channels" reported by acunningham http://bugs.digium.com/view.php?id=11181 |
| 19:38.23 | ZX81 | anyone able to take a look at it? |
| 19:39.09 | putnopvut | I just did. |
| 19:39.26 | putnopvut | There's another open bug with the same deadlock, and I uploaded a patch for it recently. Let me find the number. |
| 19:39.37 | ZX81 | cool cheers |
| 19:39.42 | putnopvut | M11730 |
| 19:39.43 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_agent 0011730: Multiple deadlock / show channels freeze on Queues 1.4.16/17 reported by UDI-Doug http://bugs.digium.com/view.php?id=11730 |
| 19:39.51 | ZX81 | sweet |
| 19:39.59 | putnopvut | That's the one. I'll make a note on 11181 to use the patch from 11730. |
| 19:40.11 | ZX81 | cool thanks |
| 19:42.31 | putnopvut | Note added. Thanks for bringing it up! |
| 19:53.47 | ZX81 | sweet cheers man |
| 20:00.27 | Qwell | M11674 |
| 20:00.27 | MuffinMan | [feedback] [Asterisk] Applications/app_voicemail 0011674: Voicemail(103@other,u)does not allow voicemail retrieval when x103 is in [other] in voicemail.conf reported by dcantera http://bugs.digium.com/view.php?id=11674 |
| 20:00.34 | Qwell | I kinda want to close that one |
| 20:00.56 | putnopvut | I think my note on that one hit the nail on the head. |
| 20:01.13 | putnopvut | I haven't looked to see if anyone responded or not, though. |
| 20:02.43 | Qwell | he hasn't, which is why I want to close.. |
| 20:02.50 | Qwell | and yeah, I agree. I'm sure you're right |
| 20:03.28 | Qwell | thoughts? |
| 20:03.43 | file | I would agree. |
| 20:03.47 | Qwell | closing |
| 20:05.16 | file | yay 337 |
| 20:05.22 | Qwell | I just had a funny thought |
| 20:05.28 | Qwell | if we're bug marshals... |
| 20:05.36 | Qwell | does that make russellb the bug sheriff? :P |
| 20:05.47 | file | eep |
| 20:11.10 | file | 336! |
| 20:19.42 | *** join/#asterisk-bugs kpfleming (n=kpflemin@216.207.245.1) |
| 20:19.42 | *** mode/#asterisk-bugs [+o kpfleming] by ChanServ |
| 20:21.32 | Qwell | 336? |
| 20:21.40 | Qwell | did something get reopened? |
| 20:22.00 | file | what? |
| 20:22.06 | Qwell | 337 now :( |
| 20:22.33 | file | 336 for me |
| 20:22.38 | Qwell | O.o |
| 20:22.44 | Qwell | oh, 336 now |
| 20:22.52 | Qwell | it was totally just 337 |
| 20:23.07 | Qwell | M11605 |
| 20:23.08 | MuffinMan | [new] [Asterisk] Core/Configuration 0011605: [patch] Optionally swap the first and second CLI arguments for a more "human" interface reported by Corydon76 http://bugs.digium.com/view.php?id=11605 |
| 20:23.10 | Qwell | Corydon76-dig: ^^ thoughts? |
| 20:23.58 | Corydon76-dig | Mmm? |
| 20:24.10 | Qwell | is there any reason that needs to stay open? |
| 20:24.16 | Corydon76-dig | Nope |
| 20:24.19 | Qwell | I added a comment |
| 20:27.07 | Qwell | if you agree, I can close if you'd like (or you can) |
| 20:29.14 | putnopvut | I like Corydon76-dig's description on that bug. |
| 20:34.25 | file | (closing) |
| 20:34.31 | Qwell | yay |
| 21:59.41 | Qwell | how odd.. a module reload chan_zap.so causes a segfault during a SIP register |
| 22:00.49 | Qwell | actually! maybe not |
| 22:00.52 | russellb | that ... doesn't make sense |
| 22:00.57 | russellb | they are in no way related |
| 22:00.57 | Qwell | huh |
| 22:01.03 | russellb | other than both being in the same process ... |
| 22:01.05 | Qwell | interesting |
| 22:01.18 | file | disturbing. |
| 22:01.19 | Qwell | so, I'm testing 11594, I recompiled with LOW_MEMORY, and I was doing a module reload chan_zap.so |
| 22:01.31 | Qwell | and it would crash, and it appeared to need to be timed right |
| 22:01.32 | Qwell | BUT |
| 22:01.43 | Qwell | I didn't bother with the reload this time, and...bam, segfault |
| 22:01.54 | Qwell | so chan_sip is crashing on register with LOW_MEMORY, reliably |
| 22:02.14 | russellb | yeah, actually, at astricon there were some messed up crashes that Jim Dixon was having |
| 22:02.18 | russellb | turned out LOW_MEMORY caused the |
| 22:02.22 | russellb | so i just turned that off ... |
| 22:02.24 | Qwell | heh |
| 22:02.52 | russellb | it was related to thread local storage not working properly with LOW_MEMORY defined |
| 22:03.03 | Qwell | it's happening in...snprintf |
| 22:03.09 | russellb | beautiful |
| 22:03.17 | Qwell | let's see |
| 22:03.22 | russellb | it's possible that we ran out of stack space |
| 22:03.32 | russellb | we only allocate 64 kB stacks in that mode i think\ |
| 22:03.33 | Qwell | any way to check that in gdb? O.o |
| 22:03.41 | russellb | Qwell: ummmm |
| 22:03.44 | russellb | not that i know of |
| 22:04.00 | russellb | but you can usually tell because gdb shows a crash on the _entry_ into a function or block of code |
| 22:04.08 | Qwell | snprintf(resp->header[0], sizeof(resp->data), "SIP/2.0 %s\r\n", msg); |
| 22:04.15 | russellb | of course, you'd need the debug version of glibc |
| 22:04.27 | Qwell | sizeof(resp->data) is 4096, and msg is "correct" |
| 22:05.17 | Qwell | I suppose I could change the sizeof() to a 1, to test if it changes where the segv happens |
| 22:08.07 | Qwell | note to self: `rm core.<tab> *` is a bad idea |
| 22:11.57 | *** join/#asterisk-bugs outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 22:22.23 | Qwell | yeah, it's a stack size issue...ugh |
| 22:25.55 | russellb | Qwell: i win |
| 22:25.56 | russellb | ! |
| 22:26.14 | russellb | wait a second |
| 22:26.21 | russellb | why is the sizeof() and destination different? |
| 22:26.30 | Qwell | no idea |
| 22:26.31 | russellb | that sounds like a bug waiting to be exploited |
| 22:27.19 | russellb | unless data is the buffer that all headers go in ... which it probably is |
| 22:28.03 | putnopvut | the line above is resp->header[0] = resp->data |
| 22:28.09 | putnopvut | So they're the same buffer. |
| 22:28.36 | Qwell | right - what he said |
| 22:28.40 | file | all pointers lead to rome |
| 22:29.22 | *** join/#asterisk-bugs codefreeze (n=steve_mu@216.166.159.235) |
| 22:29.22 | *** mode/#asterisk-bugs [+o codefreeze] by ChanServ |
| 22:32.56 | russellb | O.o |
| 22:33.36 | file | russellb: WHAT |
| 22:33.45 | russellb | file: your pointers comment. |
| 22:33.55 | file | :D |
| 22:34.18 | russellb | also, if you used ast_str, pointers to header locations could not be pointers, but they could be stored as pointer offsets |
| 22:34.21 | russellb | annnnnnyway. |
| 22:34.56 | mvanbaak | hhmm |
| 22:35.04 | mvanbaak | lot of stuff that can be set to 'Feedback' |
| 22:35.05 | russellb | <3 code |
| 22:35.40 | Qwell | is there a way to tell a polycom to unregister? O.o |
| 22:35.48 | russellb | unplug it? |
| 22:35.50 | Qwell | without waiting 8 minutes to reboot |
| 22:35.52 | mvanbaak | erm, unplug the power ? |
| 22:35.59 | russellb | unplug the net cable |
| 22:36.03 | russellb | not the power |
| 22:36.04 | Qwell | poe |
| 22:36.05 | Qwell | :p |
| 22:36.07 | russellb | owned |
| 22:36.10 | mvanbaak | Qwell: module reload chan_sip.so ? |
| 22:36.15 | putnopvut | ask it nicely? |
| 22:36.17 | Qwell | mvanbaak: asterisk isn't running |
| 22:36.28 | russellb | Qwell: add an ACL to it's peer entry to deny everything? |
| 22:36.54 | Qwell | I mean without asterisk running |
| 22:36.54 | russellb | well, if asterisk isn't running ... i would think it would deem the server unreachable after a minute or so ... |
| 22:37.01 | Qwell | you'd think so... |
| 22:37.36 | Qwell | it's been sitting there thinking it's registered for the past 5 minutes or so |
| 22:37.47 | putnopvut | How often is it set to attempt to re-register? |
| 22:38.28 | russellb | just reboot the phone |
| 22:38.30 | russellb | it's not 8 minutes :) |
| 22:38.38 | Qwell | it is totally 8 minutes |
| 22:38.43 | russellb | it is totally not |
| 22:38.46 | mvanbaak | it's 7 minutes 42 |
| 22:38.52 | file | time it! |
| 22:38.52 | russellb | time it |
| 22:38.55 | russellb | jinx |
| 22:39.15 | Qwell | --mark-- |
| 22:39.17 | mvanbaak | there you go |
| 22:39.25 | file | russellb: no! :( |
| 22:39.27 | putnopvut | Qwell: what do you need? |
| 22:39.40 | Qwell | "Waiting for network to initialize..." |
| 22:39.47 | mvanbaak | now qwell is watching the computer clock and will reply --mark-- after exactly 8 minutes |
| 22:39.51 | putnopvut | Oh, not that sort of mark... |
| 22:39.52 | Qwell | ., .., ..., ...., ., .., ..., .... |
| 22:39.58 | file | putnopvut: lol |
| 22:41.32 | Qwell | 2 minutes later, still waiting for network to initialize... |
| 22:43.01 | mvanbaak | holy crap |
| 22:43.10 | mvanbaak | that's the most buggy DHCP client I've seen |
| 22:43.13 | Qwell | 4 minutes, running sip.ld |
| 22:43.27 | russellb | mvanbaak: it's lying, i'm sure |
| 22:43.27 | mvanbaak | the cisco one sux with the vlan timeouts |
| 22:43.38 | mvanbaak | but it's faster then 2 minutes |
| 22:43.43 | russellb | by "waiting for network to intialize", it means "initializing hardware, booting kernel, blah blah" |
| 22:43.54 | mvanbaak | yeah |
| 22:44.03 | mvanbaak | must be running hurd ;) |
| 22:44.19 | Qwell | 5 minutes |
| 22:44.52 | mvanbaak | if something fails you'll see: RMS is ranting on theo@ again, please wait till he returns to fix hurd bugs |
| 22:45.17 | Qwell | --mark-- |
| 22:45.20 | Qwell | 6 minutes... |
| 22:45.25 | russellb | 6 != 8 |
| 22:45.29 | Qwell | 6 > 0 |
| 22:45.31 | putnopvut | pwnd! |
| 22:45.54 | mvanbaak | you seen this funny movie about boardmeetings with msn and irc language ? |
| 22:45.57 | mvanbaak | it's funny |
| 22:46.01 | putnopvut | I saw that. |
| 22:46.09 | Qwell | anyways, yeah, if I change data size to not be 4096, it appears to not crash |
| 22:46.09 | russellb | 6 == (8 >> 1) & 2 |
| 22:46.14 | russellb | errr |
| 22:46.17 | russellb | s/&/|/ |
| 22:46.34 | putnopvut | 6 == 8 - 2 |
| 22:46.46 | mvanbaak | putnopvut: I find it funny when this one guy yells pwnd!!!!!!!!! |
| 22:46.49 | file | putnopvut: madness |
| 22:47.34 | Qwell | changing chan_sip to stringfields is going to take some serious effort, I'd bet.. the question is, is it worth it? |
| 22:47.48 | putnopvut | That's not already done in trunk? |
| 22:47.55 | jsmith | Qwell: Of course it will be... just as long as I'm not the one to do it ;-) |
| 22:47.55 | russellb | 6 == sin(8 * PI/8) * 6 |
| 22:47.57 | Qwell | umm, maybe |
| 22:48.14 | putnopvut | Yes, it is, at least for sip_pvt |
| 22:48.16 | Qwell | putnopvut: nope, not this one |
| 22:48.22 | Qwell | this is sip_request |
| 22:48.28 | putnopvut | Ah... |
| 22:48.47 | mvanbaak | send oej a mail ;) |
| 22:48.53 | putnopvut | Yeah, that will be a pain. |
| 22:49.12 | russellb | i don't know if it makes sense to use stringfields there |
| 22:49.33 | file | I would not go down that path. |
| 22:49.33 | Qwell | char data[4096], heh |
| 22:49.44 | russellb | change char data to struct ast_str *data; |
| 22:49.55 | putnopvut | 4096 is a mistake anyway according to RFC 3261. |
| 22:50.00 | russellb | and change cha r*header[blah] ... to ... size_t header[MAX_HEADERS] |
| 22:50.01 | putnopvut | It should be 65535 :) |
| 22:50.02 | mvanbaak | dont think so. olle has spend a great deal of time to convert the sip_pvt to stringfield. if this one was worth it he would have done it already I think |
| 22:50.23 | russellb | Qwell: it's not trivial |
| 22:50.29 | Qwell | well then |
| 22:50.33 | russellb | but that's how i want to see it done :) |
| 22:50.57 | *** topic/#asterisk-bugs by file -> Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Overall issue count: 334 -=- Monitor new reports in #asterisk-commits -=- Want to help? Test bugs marked Ready For Testing |
| 22:50.58 | russellb | mvanbaak: just because oej hasn't done it, doesn't mean it's not worthy of doing ... |
| 22:50.58 | mvanbaak | about the new line of development |
| 22:51.18 | russellb | he's not the _only_ person who can improve chan_sip |
| 22:51.19 | putnopvut | I don't think stringfields are right for that since there is a maximum packet size as described in the RFC. |
| 22:51.20 | russellb | :) |
| 22:51.27 | mvanbaak | new features will be created in dev branches that get branched of branches/1.6 right ? |
| 22:51.41 | russellb | s/branches\/1.6/trunk/ |
| 22:51.44 | Qwell | putnopvut: it's blowing the stack limit... |
| 22:51.45 | mvanbaak | russellb: I know. but I do know he was working on the stringfield stuff. |
| 22:51.54 | russellb | mvanbaak: *nods* |
| 22:52.09 | mvanbaak | ok, so 1.6 will be next to branches and trunk ? |
| 22:52.13 | mvanbaak | in the root of the repos |
| 22:52.21 | russellb | Qwell: there may be some other things in the path to be made smaller |
| 22:52.25 | russellb | mvanbaak: trunk == 1.6 |
| 22:52.34 | russellb | Qwell: oej uses some _huge_ string buffers |
| 22:52.38 | mvanbaak | right now it is |
| 22:52.41 | mvanbaak | but in the new setup |
| 22:53.00 | mvanbaak | still 1.6 == trunk ? |
| 22:53.44 | mvanbaak | I'm having some trouble from time to time to merge stuff to branches. and since you are going to do that all the time I wonder how you guys do/will do it |
| 22:54.01 | Qwell | cute... char md5secret[256] |
| 22:54.17 | mvanbaak | say, I create a branch to implement chan_skinny realtime |
| 22:54.17 | putnopvut | My favorite feature of SIP is the magic cookie. |
| 22:54.41 | russellb | anywhere that says BUFSIZ is _huge_ |
| 22:54.44 | mvanbaak | and Qwell gets on a skinny spree and I have to svnmerge like 280 commits into my branch before it's done |
| 22:54.57 | russellb | Qwell: ^^^ |
| 22:54.59 | mvanbaak | how the hell can I merge my work back to the patch I branched from ? |
| 22:55.05 | file | putnopvut: MAGIC! |
| 22:55.18 | putnopvut | russellb: what is BUFSIZ? |
| 22:55.20 | russellb | Qwell: BUFSIZ was 8 kB on the last system i checked |
| 22:55.42 | russellb | putnopvut: it's a standard define, traditionally used to define the maximum size in a FILE I/O buffer |
| 22:55.59 | russellb | completely useless and careless the places it is used in asterisk |
| 22:56.18 | russellb | char r[BUFSIZ*2], |
| 22:56.21 | russellb | for example ... |
| 22:56.21 | Qwell | <PROTECTED> |
| 22:56.22 | Qwell | <PROTECTED> |
| 22:56.44 | russellb | <PROTECTED> |
| 22:56.44 | russellb | <PROTECTED> |
| 22:57.00 | russellb | add_sdp() allocates a _lot_ of stack space |
| 22:57.03 | putnopvut | Qwell: that's a lotta stack space. |
| 22:57.23 | Qwell | that's in process_sdp |
| 22:57.28 | russellb | 20+ kB |
| 22:57.55 | russellb | Qwell: can you post the backtrace that led to the crash? |
| 22:58.18 | Qwell | yeah, lemme see if it's still built right |
| 22:58.26 | Qwell | yep |
| 22:58.50 | Qwell | no add_sdp in the trace :p |
| 22:58.53 | russellb | damn |
| 22:58.59 | file | you lose! |
| 22:59.14 | russellb | well what is darnit! |
| 22:59.18 | Qwell | http://pastebin.com/d1bf4c797 |
| 22:59.31 | russellb | yikes |
| 22:59.36 | Qwell | or, rather, it isn't directly in the trace. it may be though |
| 23:00.56 | russellb | check_auth() is an offender |
| 23:01.13 | Qwell | yay for *2 |
| 23:01.29 | russellb | and then of course, the respprep() which allocates the sip_request |
| 23:01.35 | russellb | the sip_request will be difficult to improve |
| 23:01.47 | russellb | in the short term, we can improve check_auth() |
| 23:01.50 | russellb | 1.4 or trunk? |
| 23:01.56 | Qwell | this was 1.4 |
| 23:01.59 | russellb | ok |
| 23:03.05 | russellb | <PROTECTED> |
| 23:03.06 | russellb | <PROTECTED> |
| 23:03.20 | Qwell | heh |
| 23:04.24 | Qwell | s/BUFSIZE * 2/256/ == happy chan_sip |
| 23:04.50 | russellb | heh |
| 23:05.05 | russellb | gotta do something else for commit though ... |
| 23:05.19 | Qwell | nod, was just testing |
| 23:05.43 | russellb | HRM |
| 23:05.45 | russellb | idea. |
| 23:08.14 | JunK-Y | russellb: do you think func_devstate.c could set non-custom state?? |
| 23:08.21 | russellb | JunK-Y: no |
| 23:08.24 | russellb | Qwell: patch coming |
| 23:08.31 | Qwell | excellent |
| 23:08.46 | JunK-Y | cause ive a customer which specifiquely needs to set his state to NOT_INUSE even if hes on MOH. |
| 23:09.55 | JunK-Y | if the lock is properly made, in what that would hurt exactlyÉ? |
| 23:10.07 | russellb | it can't work |
| 23:12.57 | JunK-Y | russelb: but why exactly it cant work? |
| 23:13.11 | JunK-Y | cause otherwise, i will have to change custom state everywhere. |
| 23:13.21 | russellb | JunK-Y: i can't answer that quickly ... |
| 23:13.40 | russellb | but i just know that with the current device state code, it won't work |
| 23:13.49 | russellb | Qwell: http://pastebin.ca/856674 |
| 23:13.51 | JunK-Y | russellb: ha okay, when you have time, just drop a post on asterisk-dev. |
| 23:13.55 | JunK-Y | okay |
| 23:14.13 | russellb | you can drop a post on -dev, and i'll answer when i have time if someone doesn't before i do |
| 23:14.42 | JunK-Y | all right, will do. |
| 23:15.02 | russellb | Qwell: thread local dynamically allocated string buffer ... will grow as needed, but gets re-used, instead of malloc/free over and over on every auth |
| 23:15.42 | Qwell | appears to have no crashed |
| 23:15.48 | russellb | actually, with the knowledge that this function will _only_ get called by one thread, we can optimize it further |
| 23:15.57 | russellb | but that feels dirty |
| 23:18.09 | Qwell | russellb: yeah, seems to works fine |
| 23:19.01 | russellb | Qwell: w00t |
| 23:19.19 | russellb | i'm backed up on patches to commit now, heh |
| 23:21.28 | *** join/#asterisk-bugs ZX81 (n=ZX81@202.49.106.158) |
| 23:52.40 | *** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 23:53.43 | d1mas | ppl, what is going with Mantis? it looks like you are restoring repository from backup or something and svnbot actively copies old commits to Mantis... |
| 23:55.13 | putnopvut | d1mas: yeah, there was a problem with svn yesterday and now everything's coming back on line slowly. |
| 23:55.32 | putnopvut | Apparently that means svnbot is going nuts. |
| 23:55.42 | Qwell | was |
| 23:55.55 | putnopvut | Ah, okay. |
| 23:57.27 | d1mas | yeah.. it stopped |
| 23:57.50 | russellb | i disabled it pretty quickly |
| 23:57.56 | russellb | it should have only been the first set of commits |
| 23:58.03 | russellb | like ... 25 revs or so |
| 23:58.13 | d1mas | well, it looks it still updated bugs - 6670 was just updated |
| 23:58.26 | russellb | oh crap |
| 23:58.28 | russellb | i know why |
| 23:59.34 | russellb | fixed |
| 23:59.40 | d1mas | well there is a positive side too :) looking at these old issues I found two wonderful patches (0006512 and 0006504) - yesterday I was planning to do exactly the same :) Now need to find oej to know the status... |