| 00:01.06 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 00:10.38 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 00:30.44 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 01:37.15 | gtjoseph | hey file: is master broke? manager.c:8984:6: error: format â%sâ expects a matching âchar *â argument [-Werror=format=] |
| 01:37.15 | gtjoseph | <PROTECTED> |
| 01:41.41 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 02:05.59 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:05.59 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:17.26 | snuff-work | any1 have ideas on my question earlier.. why cdr variables when doing 'core show channel X' only show 7 chars |
| 03:00.06 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-rwqjxqwnopxirjbj) |
| 03:00.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:04.19 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-omkntpkkastokltp) |
| 04:07.44 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 04:07.44 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 05:42.37 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 06:02.18 | *** join/#asterisk-dev dustinm (~dustinm@105.ip-167-114-152.net) |
| 06:09.31 | *** join/#asterisk-dev oej (~oej@scandic818.host.songnetworks.se) |
| 06:09.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:53.37 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:55.09 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 07:05.56 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:06.07 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:20.15 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:20.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:49.45 | skrusty | morning |
| 09:00.29 | *** join/#asterisk-dev russellb (~rustlebee@redhat/russellb) |
| 09:00.29 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 09:00.29 | *** mode/#asterisk-dev [+oo russellb malcolmd] by sendak.freenode.net |
| 10:57.23 | *** join/#asterisk-dev MrTAP (~MrT@76-10-185-217.dsl.teksavvy.com) |
| 11:04.29 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:04.29 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:04.46 | file | nods to mjordan |
| 11:32.25 | mjordan | nods back |
| 11:32.28 | mjordan | Coffe. |
| 11:32.33 | mjordan | with an extra e, even. |
| 11:33.56 | file | mjordan, you should invest in a coffee company or two |
| 11:34.20 | mjordan | No need, I already send them my money |
| 11:41.29 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 11:50.57 | mjordan | master may be broke, but on the plus side: https://bamboo.asterisk.org/bamboo/browse/AST-ATSF1-255 |
| 11:51.46 | file | mjordan, indeed |
| 12:08.28 | *** join/#asterisk-dev newtonr (~RustyNewt@173-21-90-203.client.mchsi.com) |
| 12:08.28 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 12:19.32 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:50.27 | *** join/#asterisk-dev y_ateya (~y_ateya@41.45.42.254) |
| 12:57.01 | *** join/#asterisk-dev oej (~oej@81-235-151-123-no33.business.telia.com) |
| 12:57.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:16.56 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-esmknkduxjavkddx) |
| 13:57.39 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 13:58.02 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-hnxvisvnphmlqiuk) |
| 13:58.02 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:00.17 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-rfmfgflygzdxuzys) |
| 14:10.09 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 14:31.10 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 14:33.58 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-bnjvhrcduphqpbxf) |
| 14:59.40 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-hlaxmnpfzjcfwlmw) |
| 15:25.35 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 15:40.18 | *** join/#asterisk-dev sudharshaw (~sudharsha@175.157.25.209) |
| 16:02.22 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-mmunqvjjwzitergo) |
| 16:10.59 | gtjoseph | mjordan: what's the deal with asterisk-ng-doxygen? Should that really be a checked-in file? |
| 16:11.22 | gtjoseph | I just ran make progdocs and it regenerated it |
| 16:33.45 | mjordan | huh |
| 16:33.58 | mjordan | gtjoseph: if it gets regenerated, probably not |
| 16:34.01 | mjordan | I'm not that familiar with it |
| 16:34.31 | gtjoseph | ok. i'll do a patch to remove it. |
| 16:34.43 | gtjoseph | and ignore it |
| 16:42.54 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-gqqleimltlrjdjwy) |
| 17:10.46 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 17:15.00 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-unrbkubwuqefclgl) |
| 18:21.19 | file | what's the deal with airline food?!? |
| 18:21.41 | gtjoseph | what airline food?? |
| 18:22.31 | file | ooo |
| 18:23.05 | gtjoseph | hey, what does this mean?? res_pjsip.c:1962 ast_sip_requires_authentication: No SIP authenticator registered. Assuming authentication is not required |
| 18:23.44 | file | no module loaded to perform authentication? |
| 18:24.08 | gtjoseph | hmmm. this just started on a production pbx |
| 18:25.43 | mjordan | weird |
| 18:26.07 | mjordan | file: also, the deal is that our tastebuds taste differently at 30000 ft. Hence, they have to put more sodium and fat in the food to make it taste palatable. |
| 18:26.14 | gtjoseph | yeah, especially since autoload is on and there are no noloads |
| 18:26.26 | mjordan | gtjoseph: is the module loaded? |
| 18:26.30 | mjordan | or can it be loaded? |
| 18:26.32 | file | mjordan, logic belongs NOWHERE |
| 18:26.35 | coreyfarrell | seems backwards.. if no authentication module is available shouldn't it fail to authenticate? IE deny by default unless an auth module says to permit? |
| 18:28.15 | gtjoseph | stranger...this pbx takes over a minute to load. it stalls for 30 seconds while loading res_pjsip modules. |
| 18:28.27 | gtjoseph | i think i need to reinstall it. |
| 18:28.29 | file | DNS? |
| 18:28.35 | gtjoseph | oh, |
| 18:28.41 | gtjoseph | maybe |
| 18:29.09 | file | at startup it'll try to figure out it's local address, if that's not setup in /etc/hosts it'll do a DNS lookup and if that takes awhile it'll hang |
| 18:29.39 | gtjoseph | <PROTECTED> |
| 18:31.37 | mjordan | coreyfarrell: maybe. In this case though, the thought was that if there was no authenticator loaded, it doesn't authenticate (for situations, for example, where authentication is front-ended by something like Kamailio) |
| 18:35.46 | coreyfarrell | still seems like not requiring authentication should be done explicitly / never assumed |
| 18:43.52 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 18:48.43 | *** join/#asterisk-dev nightwolf_ (4055f7c7@gateway/web/freenode/ip.64.85.247.199) |
| 18:49.28 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 18:49.28 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 18:49.28 | *** join/#asterisk-dev Corydon76 (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 18:49.28 | *** join/#asterisk-dev snuff-home (~brad@203-219-29-182.tpgi.com.au) |
| 18:49.28 | *** mode/#asterisk-dev [+oo Corydon76 snuff-home] by sendak.freenode.net |
| 18:49.40 | *** join/#asterisk-dev russellb (~rustlebee@redhat/russellb) |
| 18:49.41 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:49.41 | *** mode/#asterisk-dev [+oo russellb malcolmd] by sendak.freenode.net |
| 18:56.23 | mjordan | GAH |
| 18:56.24 | mjordan | https://bamboo.asterisk.org/bamboo/browse/AST-ATTSCD-C632TE-734/test/case/8454222 |
| 18:57.30 | file | [May 6 12:20:04] DEBUG[5275] bridge_channel.c: Bridge test_bridge: pushing 0xb7332248(Local/_attended@transfer-00000001;1) into bridge failed |
| 18:57.32 | file | that's probably bad. |
| 18:58.34 | mjordan | yeah, same thing. |
| 18:58.45 | mjordan | That test is the devil. Also, the code is pretty nuts too. |
| 18:58.55 | mjordan | on a completely different note, sorcery caching! |
| 18:59.06 | mjordan | 1) First question: why couldn't we use the AstDB wizard as a cache? |
| 18:59.53 | file | you could, but you'd have to go from a text representation into a data structure each time you wanted it, and it also may hit the disk which can be slow |
| 19:00.09 | file | it's still likely faster than a database |
| 19:00.23 | mjordan | the one benefit is that it is permanent |
| 19:00.29 | mjordan | which means your cache survives across restarts/reloads |
| 19:00.43 | mjordan | given sorcery's "flexibility", I'm wondering if you can't do: |
| 19:00.50 | mjordan | endpoint/cache=memory |
| 19:00.53 | mjordan | endpoint/cache=astdb |
| 19:01.00 | mjordan | endpoint=realtime,ps_endpoint |
| 19:01.05 | mjordan | i.e., create an L2 cache |
| 19:01.29 | file | you could |
| 19:01.39 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 19:02.11 | mjordan | well, what this drives to, is that the caching policies and cache management would want to be independent of the underlying storage mechanism |
| 19:02.26 | mjordan | if I'm reading the proposal correctly, you're proposing what is essentially a new memory wizard |
| 19:03.09 | file | that is correct - as it is currently written |
| 19:03.39 | mjordan | I'm not entirely sure it is worth doing |
| 19:03.52 | mjordan | since persisting a cache is kind of... good, but not great. |
| 19:04.02 | mjordan | The only benefit is that we wouldn't necessarily slam the DB as hard on startups |
| 19:04.31 | mjordan | of course... |
| 19:04.35 | mjordan | Hum. |
| 19:04.40 | mjordan | So, I kind of did part of this already. |
| 19:05.07 | mjordan | For the media caching stuff I was working on, there is an in-memory cache that sits in front of the bucket API |
| 19:05.35 | mjordan | when retrieving something, it doesn't manage its caching policies - it asks the bucket API if what it has is still valid, and the underlying bucket implementation comes back with a 'yay' or 'nay' |
| 19:06.01 | mjordan | but what it also does is write out the elements in the in-memory cache to the AstDB |
| 19:06.05 | mjordan | and rebuilds itself on restart. |
| 19:06.23 | mjordan | It might be that - if we want to persist cached items - its easier to just do that, rather than build out a very generic concept of caching |
| 19:06.36 | mjordan | because I suspect that doing that as a middleware between sorcery and the wizards would be rather challenging |
| 19:06.50 | mjordan | and I can't see wanting to insert anything more than (a) memory and (b) AstDB into the mix. |
| 19:07.44 | file | nods |
| 19:08.47 | mjordan | I do think we could probably get away with not doing as much as what you put in there |
| 19:09.39 | file | what do you think we could axe? |
| 19:10.06 | mjordan | I think you could probably axe the rebalancing |
| 19:10.22 | mjordan | at least until we know if the size of the cache varies wildly |
| 19:10.39 | file | nods |
| 19:10.44 | mjordan | having a background thread that refreshes the cache may or may not be necessary |
| 19:10.55 | mjordan | you could let a stale item hang out until someone asks for it, then fall through and hit the DB |
| 19:11.24 | file | it was originally that way, but I liked sgriepentrog's idea of doing it that way |
| 19:11.28 | mjordan | that's fair |
| 19:11.44 | mjordan | expiration could happen naturally when a stale item is asked for, and isn't found in the backend |
| 19:11.54 | mjordan | the risk there is that someone may never ask for an item again... |
| 19:13.14 | mjordan | so I'm not really against being a bit agressive on killing expired items. |
| 19:13.21 | mjordan | be be aggressive |
| 19:13.33 | mjordan | I'm going to walk. |
| 19:13.34 | mjordan | :-P |
| 19:13.40 | file | lawl |
| 19:18.20 | file | walk the walk, talk the talk |
| 19:19.14 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 19:19.14 | *** join/#asterisk-dev Corydon76 (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 19:19.14 | *** join/#asterisk-dev snuff-home (~brad@203-219-29-182.tpgi.com.au) |
| 19:19.14 | *** mode/#asterisk-dev [+oo Corydon76 snuff-home] by sendak.freenode.net |
| 19:38.15 | file | mjordan, did you walk enough? |
| 19:46.03 | mjordan | file: probably |
| 19:46.11 | mjordan | file: do we create any sorcery caches by default? |
| 19:46.24 | file | no |
| 19:46.30 | mbowie | Good afternoon folks... I'm gearing up to slap a backtrace on the issue tracker, but wonder if someone might be good enough to give it a once over before I make noise which might not require an entry. http://pastebin.com/bZ9vmUFh |
| 19:47.09 | mjordan | file: hm. Thought on the expire_on_reload - that really means that you'll have to support storing cached items in the AstDB |
| 19:47.42 | mjordan | mbowie: since the crash is actually happening in pjproject, it would be nice if you had the symbols from that library |
| 19:47.48 | file | mjordan, pour quoi? |
| 19:48.17 | mjordan | file: ah, you said reload, not restart. |
| 19:48.21 | file | correct |
| 19:48.30 | mjordan | nm then, moving along, nothing to see here, enjoy the show folks |
| 19:49.05 | file | don't scare me like that! |
| 19:49.15 | mbowie | mjordan: That certainly makes sense. Let me see about addressing that and trying to catch it again. Thanks for the quick assist. |
| 19:54.21 | mbowie | Am I correct that libbfd is required in order to get symbols included in modules? |
| 20:02.13 | mjordan | that's useful for better backtraces, which makes backtraces super more useful |
| 20:20.00 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-yabetcyfyqayslwk) |
| 20:21.07 | mjordan | file: how would we do prefetch in sorcery caching? |
| 20:21.30 | mjordan | file: if I'm thinking about this correctly, when loading, we don't actually know what objects to get, as we have no persistence of objects across restart |
| 20:21.41 | file | prefetch means all |
| 20:21.49 | mjordan | hum. |
| 20:21.57 | mjordan | can you ask sorcery for all? |
| 20:22.01 | file | yes |
| 20:22.04 | mjordan | I'm not sure I love that. |
| 20:22.28 | mjordan | I might punt on a few of these options until we know for sure we are actually going to need them |
| 20:22.34 | file | go ahead |
| 20:22.51 | mjordan | I'm not convinced that the background refresh/expiration thread is going to work as well as hoped either, but I'm thinking about implementation here. |
| 20:23.07 | mjordan | feels like with a few thousand endpoints, I could do some really terrible things to my system. |
| 20:23.35 | file | I think that's the crux of this - there is no perfect way to do it for everything |
| 20:24.18 | mjordan | well |
| 20:24.25 | mjordan | the more you get creative with things, the worse it can get |
| 20:24.33 | mjordan | hence why caching is one of those two hard problems |
| 20:24.42 | mjordan | I'm concerned that if we get too clever, we'll just make things worse |
| 20:24.59 | mjordan | I'm not against trying the ideas out, but we need to consider systems with 4000 endpoints |
| 20:25.05 | mjordan | that's not impossible |
| 20:25.21 | mjordan | and if you're spending all your time because someone said "expire my endpoints after 30 seconds", things will suck a lot |
| 20:25.29 | file | sure |
| 20:25.35 | mjordan | in fact, the design would be worse than simply checking the timestamp and pulling from the DB as requested |
| 20:25.55 | mjordan | as we'd have to update all 4000 endpoints, regardless of whether or not someone wanted it updated |
| 20:26.08 | mjordan | 4000 endpoints, I'm only using 4 of them, and yet my system is thrashed 10 ways from Sunday |
| 20:26.57 | mjordan | I think we should start simple, write unit tests, and see how things flow from there |
| 20:26.59 | file | they'd only get updated if they are actively used |
| 20:27.49 | mjordan | hm. That isn't how the page seems to describe it. |
| 20:28.03 | mjordan | Say I use the following: |
| 20:28.03 | mjordan | endpoint/cache=memory_cache,maximum_objects=1000,object_lifetime=300 |
| 20:28.14 | file | the object will be automatically refreshed in the background if it is used when stale but before the maximum lifetime has been met |
| 20:28.26 | file | ah without stale enabled |
| 20:28.26 | mjordan | okay, so |
| 20:28.27 | mjordan | endpoint/cache=memory_cache,maximum_objects=1000,object_lifetime_maximum=600,object_lifetime_stale=300 |
| 20:28.32 | mjordan | doesn't really matter |
| 20:28.39 | mjordan | but lets say we're using the refresher |
| 20:28.46 | mjordan | that means I have to update all 1000 objects every 5 minutes |
| 20:29.22 | file | if something requests the object after 5 minutes of being put in the cache, then it will do the refresh |
| 20:29.25 | mjordan | I'm not sure how you can guarantee expiration either unless you actively look for the objects |
| 20:29.44 | mjordan | file: that doesn't seem to match the explanation on the wiki page. |
| 20:30.05 | mjordan | if I request the object, why would I not just use the expiration for everything? |
| 20:30.19 | file | expand on that question |
| 20:30.23 | mjordan | if it is expired, remove the item from the cache, and let the next layer handle it. If it finds it, re-add to the cache. |
| 20:30.33 | mjordan | either way, you're hitting the next layer down. |
| 20:30.41 | file | sgriepentrog proposed the stale thing so that the current requesting thread isn't blocked |
| 20:31.16 | mjordan | ah. So the idea is not to have an actual scheduled refresher, but rather that if it is stale, we queue it up |
| 20:31.21 | file | yes |
| 20:31.33 | mjordan | gotchya. That felt unclear. |
| 20:31.44 | file | if you request it, it's stale, queue it up - background thread will eventually do something |
| 20:33.30 | mjordan | works for me |
| 20:33.46 | file | I sorta wonder if that's how cache management should happen - serialized in a separate thread |
| 20:34.01 | file | keep the cache access as slim as possible |
| 20:34.59 | file | but, impl |
| 20:39.46 | file | um um um |
| 20:39.51 | file | (unrelated - having an idea) |
| 20:42.32 | rmudgett | Is it a food idea? |
| 20:42.37 | file | no |
| 20:55.55 | mjordan | btw, for the CLI, we need a command to show the cache |
| 20:58.17 | file | wiki page updated |
| 21:06.10 | gtjoseph | rmudgett: what's the issue with the ast_realloc? I'm not sure why REPLACE used calloc in the first place. |
| 21:06.56 | rmudgett | When you realloc a larger buffer, the new memory is not zeroed. |
| 21:07.11 | gtjoseph | so |
| 21:07.24 | mjordan | there are things that really want items in a vector to either be NULL or valid |
| 21:07.39 | rmudgett | If you insert an element at 5 when there are only 3 elements in the vector then element 4 is not zeroed. |
| 21:07.42 | mjordan | vaguely recalls that at least |
| 21:07.51 | mjordan | ah, there it is. |
| 21:07.52 | file | yeah. |
| 21:08.01 | gtjoseph | ok, us that valid |
| 21:08.05 | gtjoseph | is that valid |
| 21:08.07 | mjordan | I'm pretty sure I made endpoints do stuff like that |
| 21:08.08 | mjordan | yeah |
| 21:08.10 | file | yes |
| 21:08.35 | mjordan | a vector with a size of 8 is essentially a contiguous array that self-grows. Having that all initialized to NULL is quite helpful. |
| 21:08.45 | gtjoseph | but if i realloc a block of 5 where 4 is null is should be null in the new copy |
| 21:09.08 | mjordan | true, but if you realloc 4 items to 8, 5,6,7 are not NULL, right? |
| 21:09.27 | mjordan | so my property of having all items in the array be NULL if not holding a valid item is now not true |
| 21:09.43 | rmudgett | New memory added by realloc is not initialized to anything. It is whatever garbage was there. |
| 21:10.01 | mjordan | so if we realloc, we'd have to at least memset the new chunks of memory |
| 21:10.26 | mjordan | anywho, I'm off early today |
| 21:10.31 | mjordan | AVENGERS! |
| 21:10.36 | file | ASSEMBLE! |
| 21:10.37 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-hnxvisvnphmlqiuk) |
| 21:12.57 | gtjoseph | i'm still not following. if vec->current = 5 and vec->max = 5 and the elements are 1, 2, 3, NULL, 5 and you realloc vec->max = 10. current (and the end of the vector) is still 5 |
| 21:12.58 | rmudgett | assembly language |
| 21:13.41 | gtjoseph | you can't put something in 8 |
| 21:13.41 | rmudgett | if vec->current = 5 and you insert at index 10 then the elements 5 - 9 are filled with garbage. |
| 21:13.49 | gtjoseph | you can't |
| 21:14.02 | gtjoseph | , er shouldn;t |
| 21:14.20 | gtjoseph | how do you even know that the vector max is now 10 |
| 21:14.27 | rmudgett | Yes you can. Look at AST_VECTOR_REPLACE. It allows that. |
| 21:14.41 | gtjoseph | which is a bug |
| 21:14.45 | rmudgett | The max vector is now 10 because you just put something at 10 |
| 21:14.49 | file | it's not a bug |
| 21:14.52 | file | it's done that way on purpose |
| 21:15.09 | gtjoseph | hmmm |
| 21:15.36 | file | it's existence actually stems from RTP payloads, which are numerical and have gaps, so you can do an immediate lookup in an array to get a format |
| 21:15.39 | gtjoseph | yeah, that's really well documented then |
| 21:15.40 | file | plus codecs |
| 21:16.08 | gtjoseph | so you're examining vec->max |
| 21:16.11 | gtjoseph | directly |
| 21:16.31 | file | what is? |
| 21:16.41 | gtjoseph | nevermind |
| 21:16.42 | rmudgett | Only the VECTOR macros are looking at max |
| 21:16.45 | gtjoseph | i think i see now |
| 21:18.25 | rmudgett | Though I've just thought of an interaction between AST_VECTOR_APPEND and AST_VECTOR_REPLACE that can allow unset elements to have garbage in them. |
| 21:18.44 | gtjoseph | yeah? |
| 21:19.32 | gtjoseph | since I didn't touch either of those, file a bug. :) |
| 21:20.58 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 21:21.03 | rmudgett | AST_VECTOR_APPEND uses realloc. If you then AST_VECTOR_REPLACE an element at idx that is beyond current but less than max then the elements between current and idx will be garbage |
| 21:21.30 | gtjoseph | ok, i'll just chaneg append to use calloc and memcpy |
| 21:22.13 | gtjoseph | i'll create a make_room internal macro |
| 21:26.40 | *** join/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 21:28.42 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:42.27 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 22:54.18 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 22:59.12 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-rfmfgflygzdxuzys) |