| 01:06.15 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 01:06.15 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:07.10 | *** join/#asterisk-dev WIMPy (~wimpy@85.183.95.26) |
| 01:14.47 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 01:26.25 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 01:26.26 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:39.02 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 01:39.02 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:50.54 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 01:50.54 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 03:29.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 03:29.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 05:31.38 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 06:08.18 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 06:29.00 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 06:59.53 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 07:40.52 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 08:14.57 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:14.57 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:28.30 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 08:29.05 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 08:43.03 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 14:49.12 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 17:15.17 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-131-241.cablep.bezeqint.net) |
| 17:15.17 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:02.50 | file | coreyfarrell, I'm going to go out on a limb and say the line numbers are a lie |
| 18:05.47 | coreyfarrell | and the commit-id in the git log he posted does match head of 13, so I'm not sure how to believe this is unintentional. |
| 18:06.05 | file | the UBSAN tool might be lying |
| 18:08.26 | coreyfarrell | like maybe it inserts lines during an intermediate build stage? |
| 18:08.31 | file | dunno |
| 18:08.36 | coreyfarrell | either way if it doesn't report the correct lines it's useless |
| 18:08.51 | coreyfarrell | well mostly |
| 18:13.43 | file | I took a gander but nothing stood out for what it would be complaining about |
| 18:14.54 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 18:14.55 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:17.06 | file | A wild leedm777 appears. |
| 18:20.20 | coreyfarrell | file: hmm I might have found something. __make_room in vector.h. maybe it's possible for (vec)->elems to be NULL and memcpy is getting flagged? called by AST_VECTOR_APPEND so it could match both backtraces. |
| 18:21.41 | file | I'd expect current to be 0 in that case, in which case the memcpy would do nothing... but maybe? |
| 18:27.31 | coreyfarrell | yeah I just checked /usr/include/string.h, it declares that arg1 and arg2 cannot be NULL.. when the count is 0 it probably doesn't matter at runtime but the non-null attribute is unconditional |
| 18:28.28 | file | nods |
| 18:29.31 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 18:29.31 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:29.34 | file | it appears as though he is on a filing spree |
| 18:37.16 | coreyfarrell | guess so |
| 18:37.32 | coreyfarrell | I'm going to open the vector / memcpy NULL arg issue. |
| 18:48.12 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 19:05.57 | file | I foresee a lot of going through issues to figure out if/how they are applicable |
| 19:06.57 | coreyfarrell | actually he just closed a whole bunch of them |
| 19:07.05 | file | and opened more |
| 19:07.42 | file | he's in left shift of negative value territory |
| 19:13.21 | coreyfarrell | yeah don't know if that matters in codecs.. for all I know it could be intentional that a*b should use signed math and a<<1 does binary/unsigned math which intentionally replaces the MSB. |
| 19:13.52 | file | aye |
| 19:14.37 | coreyfarrell | when a math based algorithm has strange code but functions correctly I tend to leave it alone, or at least leave it to those who fully understand the algorithm |
| 19:14.43 | file | agreed |
| 19:18.58 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 19:25.20 | coreyfarrell | ok I'll close the 4 codec issues "Not a bug".. I'm thinking the same for ast_str_case_hash integer overflow, it's an intentional part of hashing. |
| 19:25.51 | file | nods |
| 19:39.20 | gtjoseph | file: did you reconnect my jenkins nodes? |
| 19:42.09 | coreyfarrell | file: actually http://www.cse.yorku.ca/~oz/hash.html uses 'unsigned long hash' where we use 'int hash'. maybe the ast_str_case_hash issue has something (but it can only be fixed in master). |
| 19:46.51 | gtjoseph | @coreyfarrell: i think i can get the ref_debug periodics running on a regular basis |
| 19:48.49 | gtjoseph | i've got a bunch of cores to add to jenkins and i can assign labels to the jobs and the nodes so the ref_debug jobs will only run on core and memory rich nodes. |
| 19:49.04 | coreyfarrell | cool, but just so you know I disabled building res_pjsip for that job. can still get good coverage for a lot of the asterisk core though. |
| 19:49.35 | gtjoseph | yep, i know. still good to get it running again though |
| 19:52.17 | file | gtjoseph, nope |
| 19:52.24 | file | I haven't touched Jenkins |
| 19:52.51 | gtjoseph | ok |
| 22:18.35 | *** join/#asterisk-dev klow (~textual@c-67-161-106-89.hsd1.wa.comcast.net) |
| 22:34.08 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 22:34.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |