| 00:01.42 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 00:57.11 | *** join/#asterisk-dev Bhakimi (~textual@cpe-104-33-221-31.socal.res.rr.com) |
| 01:33.32 | *** join/#asterisk-dev libardi (~libardi@201.53.215.24) |
| 02:02.16 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 02:10.58 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/drc) |
| 02:46.37 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 04:49.35 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 05:35.49 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:12.53 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:22.56 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:27.23 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 06:53.37 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:55.00 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.121) |
| 07:16.29 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 07:45.45 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 07:47.33 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 07:56.53 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 08:10.43 | *** join/#asterisk-dev CELYA_ (~Thunderbi@46.218.88.74) |
| 08:42.19 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.121) |
| 08:57.47 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 09:10.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:27.15 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 10:28.29 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 11:01.31 | *** join/#asterisk-dev CELYA_ (~Thunderbi@46.218.88.74) |
| 11:34.39 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 12:04.23 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 12:52.18 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-lcsumwrkdodseekr) |
| 12:52.18 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 13:05.14 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 13:10.11 | *** join/#asterisk-dev ThE-mASkBG (~mASk@94.26.62.87) |
| 13:25.32 | file | seanbright: I don't libss7 so my +1 isn't a +1 from cresl1n :P |
| 13:28.29 | seanbright | k |
| 13:39.22 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.121) |
| 13:52.08 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 14:09.41 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-tfbdihbvvmxefett) |
| 14:09.41 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:26.50 | cresl1n | I'll check it out |
| 14:40.26 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 15:21.51 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 15:24.02 | gtjoseph | @kharwell: did the formula for subtracting 18 from the exponent come from someplace else? It doesn't look right. |
| 15:27.16 | kharwell | nowhere else. The mantissa is an 18 bit integer so any exponent over that must subtract 18 from it to get the correct exponent value. Then dividing the bitrate by 2^exponent gives you the appropriate mantissa that'll fit in an 18-bit integer |
| 15:27.56 | gtjoseph | hmmmm. |
| 15:28.13 | gtjoseph | examples would be good so we don't have this discussion again. |
| 15:28.38 | kharwell | like in a comment? |
| 15:28.48 | gtjoseph | yep |
| 15:28.50 | file | Yesssss |
| 15:28.55 | kharwell | alrighty |
| 15:30.20 | seanbright | well. so much for the timer patch. |
| 15:30.37 | seanbright | i like that it "just occurred" during the merge |
| 15:31.32 | gtjoseph | eh what? |
| 15:31.55 | seanbright | https://issues.asterisk.org/jira/browse/ASTERISK-28161 |
| 15:32.34 | gtjoseph | oh he had it again. |
| 15:32.42 | seanbright | yes, just as it was being merged. |
| 15:32.50 | seanbright | what unfortunate timing |
| 15:32.59 | gtjoseph | same backtrace though? |
| 15:33.09 | seanbright | appears to be |
| 15:33.11 | gtjoseph | pop_freelist |
| 15:33.14 | gtjoseph | bah |
| 15:34.06 | gtjoseph | double check that he's actually running with the patch :) |
| 15:34.12 | seanbright | yeah |
| 15:34.54 | seanbright | g |
| 15:34.58 | seanbright | GIT-13-13.15.0-rc1-2191-g664f706M |
| 15:35.05 | seanbright | whatever fucking version that is |
| 15:35.23 | gtjoseph | it's 2191 commits after 13.15.0-rc1 :) |
| 15:35.51 | seanbright | ok |
| 15:35.54 | seanbright | how is that useful? |
| 15:35.58 | gtjoseph | or commit 664f706 |
| 15:36.54 | gtjoseph | that's the alembic merge fix |
| 15:37.54 | seanbright | ok, let me know if i should put a revert up for review |
| 15:38.25 | gtjoseph | i'd say no since we'll get that fix eventually anyway |
| 15:38.30 | seanbright | good point |
| 16:23.50 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:54.22 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 17:00.28 | seanbright | so that backtrace makes no sense |
| 17:00.45 | seanbright | new_id = -139916075862319 |
| 17:01.14 | seanbright | so the negative of that is supposed to index into an array? |
| 17:11.29 | seanbright | ignoring that pj_timer_heap_set_lock() is racy |
| 17:11.33 | seanbright | this code is awful |
| 17:54.50 | gtjoseph | seanbright: agreed. in that case, something stomped on the timer entry or more likely, the memory got re-used while the timer was on the heap. |
| 17:55.46 | gtjoseph | it's an artifact of the timer entries being allocated in the parent object rather than getting allocations and refcounts of their oen. |
| 18:17.31 | *** join/#asterisk-dev libardi (~libardi@201.53.215.24) |
| 18:54.52 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 19:28.36 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 19:28.36 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:29.45 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 21:30.25 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 21:39.22 | cresl1n | seanbright: I merged those libss7 reviews |
| 21:39.35 | cresl1n | I didn't compile test them, as I assume you did |
| 22:02.51 | csavinovich | Hi Sean, are you around? |
| 22:11.57 | csavinovich | @seanbright, there is a change you made to chan_sip.c , dated 3/6, Replace calls to strtok() with strtok_r(). A new issue came in informing us that GCC 6.3 on Debian gives a warning when strtok_r() is used. https://issues.asterisk.org/jira/browse/ASTERISK-28362 , Just running it by you. Without having dwelled much on it I wonder how come there is a call to strtok_r() somewhere earlier in the same file but the |
| 22:11.57 | csavinovich | same compiler doesn't complaint.... makes me think maybe changing the way it is called the warning might be avoided? |
| 23:21.42 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-tfbdihbvvmxefett) |