| 00:43.10 | mjordan | file: on the plus side, all the tests in 11 passed |
| 00:43.50 | file | gold stars for all |
| 00:44.14 | file | and don't you have a game to play? |
| 00:44.30 | mjordan | I'm done for now |
| 00:44.32 | mjordan | Evil was slain |
| 00:44.37 | mjordan | Hamsters everywhere rejoiced |
| 00:45.11 | mjordan | So, I don't want to move failing tests to the check pipeline just yet, since that will kill our verification step |
| 00:45.11 | file | oic |
| 00:45.34 | file | yeah, no, not yet |
| 00:49.51 | mjordan | that assert crash in the DTMF INFO test is weird |
| 00:50.31 | file | where is it? |
| 00:51.03 | mjordan | on a number of the channel driver runs |
| 00:51.06 | mjordan | goes to get it |
| 00:51.11 | mjordan | https://jenkins.asterisk.org/jenkins/job/gate-asterisk-channel-drivers/91/artifact/testsuite/ |
| 00:51.13 | mjordan | artifacts there |
| 00:52.34 | file | that is interesting |
| 00:53.01 | file | very odd indeed |
| 00:54.23 | file | er |
| 00:55.47 | mjordan | every time I've seen it blow up on those asserts it is due to it thinking the request in the rdata is an ACK |
| 00:55.55 | mjordan | almost like something is getting overwritten or re-used |
| 00:56.33 | file | well, so |
| 00:56.37 | file | #3 0xb3994b75 in dtmf_info_incoming_request (session=0xb6b56688, rdata=0xb6dd00dc) at res_pjsip_dtmf_info.c:148 |
| 00:56.37 | file | #4 0xb5ebe54b in handle_incoming_request (session=0xb6b56688, rdata=0xb6dd0ddc, type=PJSIP_EVENT_TSX_STATE) at res_pjsip_session.c:2202 |
| 00:56.40 | file | look at rdata |
| 00:57.06 | mjordan | whatt about it? |
| 00:57.07 | file | I may be half asleep, but those should be the same |
| 00:57.22 | mjordan | er |
| 00:57.24 | mjordan | that's odd. |
| 00:57.30 | mjordan | looks some more. |
| 00:57.32 | file | ain't it |
| 00:58.59 | mjordan | am I crazy |
| 00:59.02 | mjordan | or does that not make any sense. |
| 00:59.43 | file | I JUST DON'T EVEN |
| 00:59.49 | file | dunno |
| 00:59.49 | mjordan | even weirder, we've already parsed part of it out |
| 00:59.56 | mjordan | So the body was valid |
| 01:00.00 | mjordan | and was parsed out of that rdata object |
| 01:01.00 | mjordan | HUM. |
| 01:01.09 | mjordan | would declaring struct before pjsip_rx_data matter at all... |
| 01:02.08 | file | hrm |
| 01:02.53 | file | I don't... know... |
| 01:03.40 | mjordan | tests |
| 01:04.01 | mjordan | not in my run. |
| 01:04.05 | mjordan | It shouldn't. |
| 01:04.09 | mjordan | BUT who knows. |
| 01:04.46 | file | there's quite a few cases of it |
| 01:05.06 | mjordan | yeah. |
| 01:05.17 | mjordan | It shouldn't; pjsip_rx_data is a typedef for struct pjsip_rx_data |
| 01:05.27 | file | aye |
| 01:05.40 | mjordan | hence why the compiler just don't care. |
| 01:05.45 | mjordan | But that's is awfully strange. |
| 01:05.51 | mjordan | it certainly doesn't fail on my machine |
| 01:07.15 | file | and on that bombshell I'm off to bed |
| 01:07.26 | file | disappears |
| 01:11.17 | mjordan | g'night! |
| 05:33.52 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 06:21.32 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 06:21.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:38.01 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 06:46.09 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:49.45 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:12.08 | *** join/#asterisk-dev doome_ (~doome@82.150.48.146) |
| 07:22.55 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 07:22.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:25.34 | oej | Morning folks! |
| 08:26.13 | *** join/#asterisk-dev stefan27 (~stefan27@212.247.4.149) |
| 09:30.20 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 11:07.33 | toresbe | wdoekes: OK, I'll try valgrind |
| 11:12.45 | toresbe | wdoekes: now it doesn't crash anymore |
| 11:14.51 | toresbe | console dial to a MoH would almost always trigger the crash - but in this case it just won't |
| 11:49.36 | *** join/#asterisk-dev flo291288 (~flo291288@mx306-1-88-173-34-251.fbx.proxad.net) |
| 11:49.51 | flo291288 | Hello, |
| 11:50.32 | flo291288 | Where is the lib src for make an originate or redirect from one res_module? regards. |
| 11:53.02 | file | the functionality required exists in the core, and the AMI versions are implemented in main/manager.c |
| 11:53.12 | file | but it really depends on what exactly you are wanting to do |
| 11:54.40 | flo291288 | Ok, thx you, i juste give to originate or redirect one channel if the channel is != DOWN |
| 12:00.04 | flo291288 | Juste i don't inderstand what is the "struct ast_format_cap" |
| 12:00.23 | file | it defines format capabilities, media codecs |
| 12:01.46 | flo291288 | Have you got an exemple for use this struct? |
| 12:02.07 | file | not off the top of my head and it depends on the version of Asterisk in use |
| 12:02.27 | file | the best approach is to look for something that does what you need now, experiment with it, and learn it |
| 12:02.43 | file | otherwise you'll have a lot of questions |
| 12:07.24 | flo291288 | OK, sorry, thx you for all, I just thought that it existed in the libraries existent a more intuitive approach . |
| 12:07.59 | file | there's an API for dialing, there's an API for redirecting a channel |
| 12:08.20 | file | everything needed is there :D but you still have to know how to use it |
| 12:09.27 | file | and seeing it in use already is the easiest way to put the pieces together |
| 12:14.00 | flo291288 | While agree with you: D |
| 12:17.22 | flo291288 | I see the app_originate module. |
| 12:20.24 | file | yes, that implements the dialplan application |
| 12:23.58 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:34.58 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:34.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:35.56 | mjordan | file: good morning |
| 12:36.06 | file | mjordan, hello! it appears as though your ARI change is still sad |
| 12:36.16 | *** join/#asterisk-dev Marquis42 (~mrbmw@d192-24-112-5.try.wideopenwest.com) |
| 12:36.20 | mjordan | er |
| 12:36.24 | mjordan | that's weird. |
| 12:36.37 | file | https://jenkins.asterisk.org/jenkins/job/periodic-asterisk-13/lastSuccessfulBuild/testReport/ |
| 12:37.01 | file | better on Ubuntu mind you |
| 12:37.23 | flo291288 | hello mjordan. |
| 12:39.20 | file | good lord the speed difference is substantial |
| 12:39.28 | mjordan | file: maybe we should just upgrade autobahn |
| 12:39.38 | mjordan | or |
| 12:39.48 | mjordan | I suppose I could call __init__ in a try catch for new style classes only |
| 12:40.02 | mjordan | file: but srsly, omg, periodic runs worked |
| 12:40.06 | file | yes |
| 12:40.08 | mjordan | flo291288: hola |
| 12:40.09 | file | I'm extremely happy |
| 12:40.38 | mjordan | AH |
| 12:40.40 | mjordan | hm. |
| 12:40.48 | mjordan | I think I'll have to do the try/catch |
| 12:40.52 | mjordan | exceptions.AttributeError: class WebSocketClientProtocol has no attribute '__init__' |
| 12:40.55 | file | aye |
| 12:41.09 | mjordan | k, I'll go with that. What version of autobahn are you running? |
| 12:41.21 | file | latest |
| 12:42.51 | file | well, close to it |
| 12:42.54 | file | 0.10.4 |
| 12:44.00 | file | if we get that sorted I'll kick off new periodics and then gather consistent failing tests |
| 12:47.54 | mjordan | k |
| 12:47.59 | mjordan | about to toss up a patch |
| 12:48.42 | file | ack |
| 12:50.43 | mjordan | file: and away it goes |
| 12:51.42 | file | looks good! |
| 12:51.51 | file | and merged |
| 12:52.02 | mjordan | ah, auto-merge |
| 12:52.03 | mjordan | so sweet |
| 12:52.08 | file | periodics kicked off |
| 12:52.18 | file | or not |
| 12:52.28 | file | right, on-demand doesn't work |
| 12:56.55 | mjordan | hm. |
| 12:56.57 | mjordan | It worked for 11. |
| 12:57.03 | mjordan | Looks like it is the PROJECT thing again. |
| 12:57.07 | file | yes |
| 12:57.13 | file | would expect nothing less |
| 12:57.34 | mjordan | which is odd |
| 12:57.43 | mjordan | ah |
| 12:57.45 | mjordan | I know why. |
| 12:57.48 | mjordan | goes to fix it. |
| 12:57.49 | file | did you do ZUUL_PROJECT or use PROJECT? |
| 12:57.52 | mjordan | I hacked it in. |
| 12:57.54 | mjordan | ZUUL_PROJECT |
| 12:57.56 | file | ah |
| 12:57.57 | mjordan | but I forgot an export |
| 12:58.09 | file | do you work in import/export? |
| 12:58.13 | mjordan | er |
| 12:58.15 | mjordan | hm. |
| 12:58.25 | mjordan | it should have taken. That means the cron job isn't working. |
| 12:58.26 | mjordan | sighs |
| 13:05.03 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-unwyxynzlbqkzyvx) |
| 13:05.03 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:05.17 | mjordan | file: should work now |
| 13:05.45 | file | it does |
| 13:25.07 | mjordan | ah, race conditions in tests. |
| 13:25.10 | mjordan | IT NEVER ENDS. |
| 13:26.13 | file | yes |
| 13:26.52 | file | maybe the world is one big race condition... |
| 14:08.52 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ffxsulyuyhjpanhw) |
| 14:18.52 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ubkblhdpbqrpyaqj) |
| 14:19.10 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-seqgmwvpoofopxyz) |
| 15:16.58 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-sjpaiupmtszzqntd) |
| 15:53.47 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 15:53.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:54.07 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-qwsytiawfgtelmak) |
| 15:54.07 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:54.17 | mjordan | file: woot - https://jenkins.asterisk.org/jenkins/job/periodic-asterisk-13/8/ |
| 15:54.19 | mjordan | progress |
| 15:54.42 | stefan27 | I don't get it... I have a spam of ERROR every 2-3 minutes: bad magic number for object 0x7faf5c0fe2b8. Object is likely destroyed for a certain test case, but when I repeat the test case when recompiled with REF_DEBUG there's no trace of that error (after running the test for 30 minutes). It's probably just a concern for my development-test-branch, but is there any way of finding out |
| 15:54.42 | stefan27 | what '0x7faf5c0fe2b8' is without REF_debug and without explicitly logging the memory address of every single object that I create or use |
| 16:00.19 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:22.09 | file | stefan27, nothing springs to mind |
| 16:39.10 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:03.41 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 17:03.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:01.27 | seanbright | any of you fine ladies/gentleman have a working kamailio + asterisk/pjsip config you've used for testing or whatever? |
| 18:09.26 | file | depends on what you're trying to do... |
| 18:10.42 | seanbright | yeah... that's a great question |
| 18:10.45 | seanbright | or point, rather |
| 18:11.05 | seanbright | inbound load distribution |
| 18:11.16 | seanbright | i can't seem to get asterisk to use the external_media_address |
| 18:11.20 | seanbright | so i assume i'm fucking something up |
| 18:14.15 | seanbright | i'll eventually figure it out - was just hoping for a head start |
| 18:27.52 | file | has nothing |
| 18:31.40 | seanbright | no worries |
| 18:44.35 | rmudgett | stefan27: Use MALLOC_DEBUG to catch your bad magic number bug. Since you are using an object after it has been destroyed you will likely get a crash trying to dereference 0xdeaddead. |
| 18:45.42 | rmudgett | If you also enable DO_CRASH when in developer mode then you would also get a crash when an assertion fails. |
| 18:46.04 | rmudgett | An assertion is triggered when the bad magic number message is generated. |
| 18:47.01 | rmudgett | With those backtraces you just need to figure out why the object that caused a crash is dead. |
| 18:47.19 | rmudgett | s/dead/destroyed/ |
| 20:07.33 | *** join/#asterisk-dev Demon_VoIP (~demon@ip253.net222.n37.ru) |
| 21:39.11 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:14.19 | seanbright | so what's the difference between transport.external_media_address and endpoint.media_address? |
| 22:18.08 | file | transport is applied depending on localnet |
| 22:18.10 | file | endpoint is always set |
| 22:18.55 | seanbright | excellent |
| 22:28.11 | seanbright | that actually makes the proxy setup pretty trivial |
| 22:28.14 | seanbright | you guys are smart |
| 22:58.06 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ffxsulyuyhjpanhw) |
| 23:52.55 | coreyfarrell | stefan27: sometimes the overhead of REF_DEBUG changes the run order between threads, this can sometimes work around the issue you were trying to troubleshoot. I would start by turning REF_DEBUG off and DO_CRASH on, see what you can find in the core dump. |