IRC log for #asterisk-dev on 20180321

00:23.15*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
00:23.15*** mode/#asterisk-dev [+o cresl1n] by ChanServ
00:50.47*** join/#asterisk-dev libardi (~libardi@187.64.235.152)
01:08.39*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
01:08.39*** mode/#asterisk-dev [+o cresl1n] by ChanServ
01:37.29*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
01:37.29*** mode/#asterisk-dev [+o cresl1n] by ChanServ
01:39.37*** join/#asterisk-dev coreyfarrell (~coreyfarr@68-118-180-100.dhcp.asfd.ct.charter.com)
01:39.37*** mode/#asterisk-dev [+o coreyfarrell] by ChanServ
01:56.27*** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
01:56.27*** mode/#asterisk-dev [+o cresl1n] by ChanServ
06:47.03*** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net)
06:56.46*** join/#asterisk-dev CELYA_1 (~Thunderbi@2a01cb0583d31d00152209e4225443b3.ipv6.abo.wanadoo.fr)
07:24.32*** join/#asterisk-dev tsearle (~tsearle@37.19.10.33)
07:24.32*** mode/#asterisk-dev [+o tsearle] by ChanServ
07:50.25*** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:8574:2240:fd7f:8fe7)
08:11.33*** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com)
08:11.33*** mode/#asterisk-dev [+o tzafrir] by ChanServ
09:11.18*** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net)
10:39.06*** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr)
10:41.38*** join/#asterisk-dev scgm11_ (~scgm11@2800:a4:179d:4700:d40f:cdd:af69:8c50)
11:46.45*** join/#asterisk-dev scgm11_ (~scgm11@2800:a4:179d:4700:854:9d7e:a043:c1d)
12:42.19*** join/#asterisk-dev pchero (~pchero@x1-6-d8-d7-75-5e-99-79.cpe.webspeed.dk)
13:27.32*** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n)
13:27.32*** mode/#asterisk-dev [+o cresl1n] by ChanServ
13:33.46*** join/#asterisk-dev scgm11_ (~scgm11@r186-52-128-254.dialup.adsl.anteldata.net.uy)
13:57.57*** join/#asterisk-dev kharwell (kharwell@nat/digium/x-nakusbdgsnhgxocp)
13:57.57*** mode/#asterisk-dev [+o kharwell] by ChanServ
14:11.57*** join/#asterisk-dev CELYA_1 (~Thunderbi@2a01:e0a:d:1111:8574:2240:fd7f:8fe7)
14:42.56*** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-mdusrulxufmgzips)
14:42.56*** mode/#asterisk-dev [+o bford] by ChanServ
14:58.15*** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd)
14:58.15*** mode/#asterisk-dev [+o malcolmd] by ChanServ
14:59.29*** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-osqhvsxytonqhxqj)
14:59.29*** mode/#asterisk-dev [+o rmudgett] by ChanServ
15:25.11*** join/#asterisk-dev razzex (~razzex@77.48.251.5)
15:28.38razzexHere's the code, I commented out the unneccessary things atm. The module crashes Asterisk whenever sip message arrives (SIGSEGV memory error). Whenever I for example try to send REGISTER, the module prints the line that its a "REGISTER" message (see code) but there's no next step. It just crashes.
15:28.39razzexhttps://pastebin.com/8iXxydSi
15:29.05razzexI detected that lines 47 and 48 are the reason for the crash
15:29.40seanbrighthave you run it under gdb to see exactly where it is crashing?
15:29.56gtjosephif you run gdb on the resulting core file, you should get more info
15:30.05gtjosephah, what he said. ^^
15:30.23razzexUmm, would you mind telling me how can i do that?
15:30.34seanbrighti mean... given that all of the other code besides those 2 lines have been commented out, i would agree with your assessment
15:31.05gtjosephhttps://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace
15:31.06razzexyeah ^^
15:31.39razzexthanks, I'M gonna check it out
15:32.18cresl1nfile, bford, so when we shrink a data_bufferI, do we care that we always discard the end of the list?
15:32.32cresl1n*ast_data_buffer
15:32.59cresl1nwishes his monitor was bigger
15:33.00bfordmmm, yeah, maybe the oldest ones should be discarded
15:33.04bfordfrom the head
15:33.06cresl1nNot sure, that's what I was wondering
15:33.21cresl1nwell, age isn't explicitly known in the list
15:33.32cresl1nso is there an implicit assumption about age in the ordering of the list?
15:33.47fileposition, basically
15:33.51cresl1nSo....
15:33.53bfordtrue. i guess you could argue that position is the age
15:34.12bfordprobably free from the head
15:34.16cresl1nSo list head is oldest?
15:34.20bfordand keep most recent at tail
15:34.22bfordyeah
15:34.26bfordshould be
15:34.45cresl1nI'm still not through the whole file yet
15:34.58bfordunless your position means nothing and you just want to put stuff in a buffer :)
15:34.58fileyeah
15:35.01cresl1nbut is there a reason we have a pos filed in struct ast_data_buffer_payload_entry?
15:35.08cresl1ns/filed/field)
15:35.13cresl1nUgh
15:35.17cresl1nI can't type
15:35.29filehow else would you pull specific entries?
15:35.43cresl1nUmmm
15:35.44bfordyou have to have position on the payload_entry
15:35.44cresl1ngood question
15:35.56cresl1nI probably just haven't gotten to that part of the API yet :-)
15:36.01gtjosephyou missed the eralier discussion we had about that :)
15:36.04cresl1nbummer
15:36.05cresl1nsorry guys
15:36.11bfordall good :)
15:36.14fileyou could probably assume that the payload itself has a position embedded in it, and could provide a callback mechanism for that, but that's an assumption and also makes it a bit more heavy
15:36.34cresl1nSo what is pos supposed to be?
15:36.40cresl1ncorresponding to RTP seqno?
15:36.44bfordcould be anything
15:36.45cresl1nor some other offset
15:36.45bfordyeah
15:36.46gtjosephyeah you'd have to provide a cmp/lookup function
15:36.48filefor the first use case, yes
15:36.53fileit's the seqno.
15:36.55cresl1nok
15:37.05cresl1nthat helps my brain to think about this code better
15:37.29cresl1nthanks for the context
15:37.56filethis covers the sending use case, where a remote endpoint can request one - I think when we get to receiving we'll end up revisiting and tweaking/extending the data buffer
15:38.17cresl1nThat's good to know
15:38.32filebut covering that initially I felt was ambitious until it is more flushed out with some usage
15:38.54cresl1nGood catches, btw, kharwell
15:38.56bfordthat's also why it's generic, so it can be used for both
15:38.59cresl1njust saw your response
15:39.11bfordand more than RTP potentially
15:41.06coreyfarrellrazzex: one thing I'm noticing your AST_MODULE_INFO uses AST_MODFLAG_LOAD_ORDER but then doesn't set load_pri.  in Asterisk 15/older this will make your module load immediately after modules which provide global symbols.  in master (16+) this will cause the module to load first.
15:42.44coreyfarrellnot sure how that would effect things but figured I'd mention it.  also the fact that you had to comment out CHECK_PJSIP_MODULE_LOADED(); makes me suspect you might be compiling against master.
15:45.45gtjosephah ha, that's why he had to comment it out.
15:46.06gtjosephi couldn't figure out why that was an issue when i was helping him the other day
15:48.39*** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.39.128)
15:50.13coreyfarrellif the intended target is master/Asterisk 16 then CHECK_PJSIP_MODULE_LOADED() should be replaced by adding to the AST_MODULE_INFO block: .requires = "res_pjsip"
15:50.16bfordcresl1n: i went ahead and changed to removing from head for shrinking, but keep going through the review if you don't mind - more feedback is appreciated :)
15:52.52cresl1nok
15:53.14razzexcorey: I had no idea, will remove that and add the line into the block, thanks
15:54.02coreyfarrellrazzex: also the '#define AST_MODULE' at the top is suspicious to me.. this should be set by the Makefile.  see MOD_ASTCFLAGS in Makefile.moddir_rules for the CFLAGS which should be used when compiling a module.
15:55.26rmudgettyay.  We're down to one 50 line page in gerrit.
15:55.36seanbrightshhhh
15:55.41coreyfarrellif you are building your module with Asterisk then MOD_ASTCFLAGS should be used automatically, but if you are compiling the module stand-alone you will need to do that yourself.
15:55.43seanbrightdon't jinx it
16:01.24*** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru)
16:09.35seanbrightre: 8182 - why is the double 'fi' required? i'm missing something
16:10.00seanbrightoh, i see it now. the else if.
16:10.03seanbrightlamesies
16:10.59razzexgtjoseph: i tried running asterisk with -g parameter, upon crash a file called "core" was generated. Is it possible that it contains this? Its not much of a help if it thats it. https://pastebin.com/Te0D1Qna
16:11.08seanbrighti guess that could just be an elif... but WHATEVER
16:12.04gtjosephrazzex: if you follow the instructions and run ast_coredumper, you'll get more information
16:12.31gtjosephast_coredumper --no-default-search ./core
16:12.53gtjoseph<PROTECTED>
16:13.29gtjosephyou can also just run gdb /usr/sbin/asterisk ./core
16:13.34razzexyay!! going to review these, sec
16:14.11gtjosephthread 1 will always be the thread the crash was in
16:14.26*** join/#asterisk-dev scgm11_ (~scgm11@r186-52-133-254.dialup.adsl.anteldata.net.uy)
16:23.30razzexumm i cant really tell whats going on in there https://pastebin.com/PY79Jqf8
16:24.02razzexI can see the incoming packet in #0
16:26.47razzex(thats thread1)
16:27.00gtjosephrazzex: did you follow the instructions about using DONT_OPTIMIZE and did you use --with-pjproject-bundled?
16:28.16razzexi used --with-pjproject-bundled?, not DONT_OPTIMIZE, im gonna do it now then
16:33.12razzexI also enabled BETTER_BACKTRACES
16:34.25gtjosephok
16:40.11razzexwow thats what i call a long compiling
16:44.01razzexhere is new core dump thread1: https://pastebin.com/sErBBpBB
16:45.32seanbrightdo REGISTER messages have from and to URIs?
16:46.12seanbrightapparently yes
16:46.52razzexyeah they do¨
16:47.06gtjosephit's weird.  the backtrace isn't diving into the pjsip functions
16:47.23gtjosephis this the same source code you pasterbinned earlier?
16:47.26seanbrightrazzex: what is line 47?
16:47.50razzexthats the line that makes it crash
16:47.52gtjosephuri_from = pjsip_uri_get_uri(rdata->msg_info.from->uri);
16:47.56razzexsec
16:47.58razzexyeah
16:47.58gtjosephif the source is the same
16:48.02razzexit is
16:48.14fileI vaguely recall that depending on where you insert yourself in the stack headers may not be parsed
16:48.21razzexsource here  https://pastebin.com/8iXxydSi
16:49.16gtjosephi'm thinking that the from->uri is not available and the virtual function that does the get is NULL
16:49.22fileyeah
16:49.31gtjosephrun gdb /usr/sbin/asterisk ./core
16:49.47gtjosephthe p *rdata->msg_info.from
16:49.53gtjosephs/the/then/
16:50.43gtjosephthat will dump the contents of "rdata->msg_info.from"
16:52.50razzexCannot access memory at address 0x0
16:53.18gtjosephso from is NULL
16:53.25gtjosephp *rdata->msg_info
16:53.30filethe stack hasn't parsed the message fully because you've inserted yourself so low
16:53.41razzex"Structure has no component named operator*."
16:54.14gtjosephyeah, what file means is that when you registered the module
16:54.29gtjosephit's set at priority 0
16:54.46gtjosephso the code that parses the message into the fields hasn't run yet
16:55.37razzexugh, makes sense. Any way to increase the priority?
16:55.45*** join/#asterisk-dev Oooohboy (~Oooohboy@2605:6000:1711:c1ff:ddec:469:ba8c:dd19)
16:55.56seanbrightyes. line 135.
16:56.24gtjosephtry using PJSIP_MOD_PRIORITY_APPLICATION
16:56.45razzexOh i see, whats the maximum value?
16:57.12gtjosephthat's it
16:57.17gtjoseph64
16:57.34razzexso 64 instead of 0, ok, will do
16:57.36gtjosephfor this purpose anyway
16:57.44gtjosephuse the PJSIP_MOD_PRIORITY_APPLICATION define
16:58.29razzexok
17:00.50razzexWohoo! It didnt crash when I registered
17:00.57razzexbut it also didnt print anything into console
17:03.00razzexI will try to debug on my own now. Ill return if im clueless again. Thanks everyone, I would have never got here without you.
18:27.34seanbrighthuh... https://gcc.gnu.org/wiki/CompileFarm
18:27.39seanbrightdidn't know this was a thing
18:27.57cresl1nThat's kinda neat
18:42.03gtjosephseanbright: you could just get one of these and create your own farm... https://natex.us/foxconn-39-server-rack/
18:43.16seanbrightalready have one, so the timing of your suggestion is fortuitous
18:43.30gtjosephuh huh
18:43.40seanbrighthow is that only $16k?
18:43.50gtjosephwell, all used
18:43.55seanbrightah, well then
18:43.57gtjosephpulled out of datacenters
18:44.23seanbrighti could probably get 40 or 50 concurrent chan_sip calls working on that
18:44.52gtjosephmaybe
18:45.03fileon a good day.
18:45.18gtjosephIf you're on a budget...
18:45.18gtjosephhttps://natex.us/ChenFox-SR0KXx10/
18:45.27seanbrightsaw that you posted to flavio's github repo
18:45.35seanbrighthave you tried to duplicate his results?
18:45.46gtjosephyeah.  i saw that you were the only watcher. :)
18:45.51gtjosephnot yet
18:46.19seanbrightheh
18:46.42gtjosephthe REGISTER results were quite interesting
18:57.27*** join/#asterisk-dev scgm11_ (~scgm11@r186-52-133-254.dialup.adsl.anteldata.net.uy)
19:05.00seanbrighti blame astdb
19:10.44*** join/#asterisk-dev scgm11_ (~scgm11@r186-52-133-254.dialup.adsl.anteldata.net.uy)
19:10.56filea reasonable choice
20:24.58*** join/#asterisk-dev csavinovich (~KingDavid@ip98-169-120-168.dc.dc.cox.net)
21:45.32jpsharpI had to patch things to move Dundi to its own astdb file.  regular asterisk traffic + dundi traffic was causing lots of system delays.
22:38.30*** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102)
22:38.31*** mode/#asterisk-dev [+o snuff-work] by ChanServ
23:12.10*** part/#asterisk-dev kharwell (kharwell@nat/digium/x-nakusbdgsnhgxocp)

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