| 00:42.46 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 00:42.46 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 06:30.46 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:30.48 | schmidts | good morning |
| 06:44.50 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:756a:18b4:df3a:9829) |
| 07:11.45 | *** join/#asterisk-dev irroot (~irroot@41.125.9.208) |
| 07:30.47 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:55.45 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:55.45 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:05.04 | *** join/#asterisk-dev Howlader (Howlader@soft.bdcom.com) |
| 08:26.14 | *** join/#asterisk-dev cemeh4 (~cemeh4@193.19.228.130) |
| 08:31.40 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 08:53.22 | *** join/#asterisk-dev cemeh4 (~cemeh4@193.19.228.130) |
| 09:05.02 | *** join/#asterisk-dev cemeh4 (~cemeh4@193.19.228.130) |
| 10:00.51 | *** join/#asterisk-dev cemeh4 (~cemeh4@193.19.228.130) |
| 10:02.23 | *** join/#asterisk-dev cemeh4 (~cemeh4@193.19.228.130) |
| 11:23.49 | *** join/#asterisk-dev cemeh4 (~cemeh4@193.19.228.130) |
| 11:23.53 | *** part/#asterisk-dev cemeh4 (~cemeh4@193.19.228.130) |
| 11:24.06 | *** join/#asterisk-dev cemeh4 (~cemeh4@193.19.228.130) |
| 11:48.41 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:48.41 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:19.04 | *** join/#asterisk-dev t_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 12:19.22 | wdoekes2 | has any one else has issues with r319652 ? (Make sure everyone gets an unhold when a transfer succeeds Some phones, like the Snom phones, send a hold to the transfer target after before sending the REFER.) |
| 12:21.34 | wdoekes2 | I have had two hangs in two days now.. among the last packets seen was a REFER-conversation and one thread was hung in handle_incoming->handle_request_refer->local_attended_transfer->ast_indicate.. and no coincidence, those ast_indicate's were added in 1.6.2.19 (r319653) |
| 12:24.05 | wdoekes2 | console could be opened, commands could be run, but no (sip) traffic was answered |
| 12:29.34 | kpfleming | wdoekes2: certainly seems plausible that it could be related |
| 12:49.09 | *** join/#asterisk-dev seraphie (~erin@207.98.195.107) |
| 12:56.11 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:56.11 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:20.39 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 13:46.51 | *** join/#asterisk-dev irroot (~irroot@197.169.189.67) |
| 14:09.09 | *** join/#asterisk-dev Ulrar (~quassel@server.aufrinfo.net) |
| 14:11.15 | Ulrar | Hi. I'm developping an asterisk module (app_*) and I want to link it with the freeradius librairy. I tried to build it directly with gcc but asterisk can't load it, saying can't load shared object : libfreeradius-client.so.2 : no such file or directory |
| 14:11.28 | Ulrar | The lib is in /etc/local/lib |
| 14:17.50 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:17.50 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:27.33 | acidfoo | if I understand correctly, asterisk set 'fd_set' at compile time to be able to fix the size of the array used to handle file descriptor ? (select.h) and if I change the limit of the files I can open per process with ulimit -n, I'm getting this error : PBX: FRACK!, Failed assertion (unsigned int) nfds <= ast_FD_SETSIZE (0) at line 78 in ast_select |
| 14:28.06 | acidfoo | so I should change the limit, and _then_ recompile to get rid of the error I presume |
| 14:28.44 | acidfoo | basically my question is : does asterisk get the limit at compile time ? |
| 14:30.09 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-gxmwotbldkubrokv) |
| 14:33.07 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:33.07 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:34.54 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:34.54 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:36.11 | wdoekes2 | acidfoo: you could try a version newer than 1.4.. the assertion is gone there |
| 14:37.26 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:37.26 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:37.46 | acidfoo | well, it was primarily for my own understanding, i'm not the one who is running this server, im just a developper ;) |
| 14:38.27 | kpfleming | acidfoo: yes, if you set the limit for open files at runtime lower than it was at compile time, you will likely run into that assert message |
| 14:38.42 | acidfoo | wdoekes2, but if you say that on 1.8, the warning have been removed, is it because there was no side effect ? |
| 14:39.23 | wdoekes2 | I would hope that the assertion was not removed while it was still useful |
| 14:39.37 | wdoekes2 | but I did not check the relevant commit |
| 14:39.55 | acidfoo | kpfleming, in fact, I increased the limit |
| 14:40.08 | acidfoo | wdoekes2, ok |
| 14:40.58 | kpfleming | acidfoo: then something is wrong... increasing the limit shouldn't cause that problem. Corydon76-home are you around? |
| 14:41.36 | acidfoo | first it was 1024, and then after compile time, we increased it to 8192 to play with sipp |
| 14:42.30 | Corydon76-home | I am around |
| 14:43.04 | kpfleming | was wondering why he's seeing an fd_setsize related assertion when he increased the open-files limit with ulimit |
| 14:43.13 | wdoekes2 | acidfoo: #if !defined(CONFIGURE_RAN_AS_ROOT) => ast_FD_SETSIZE is untouched (default? 256? 1024?) |
| 14:43.33 | russellb | FD_SETSIZE is related to the select() fdset, not related to ulimit |
| 14:44.15 | Corydon76-home | It's possible for you to exceed FD_SETSIZE, yes. |
| 14:44.18 | wdoekes2 | actually, #elif defined(HAVE_VARIABLE_FDSET) => ast_FD_SETSIZE = l.rlim_cur; |
| 14:44.39 | Corydon76-home | And the assertion is meant to detect that condition, because it could create a lockup condition later in the code |
| 14:44.43 | kpfleming | russellb: but tilghman's code now makes the select() fdset size be at least as large as the rlimit |
| 14:44.45 | acidfoo | the only thing I did is , ulimit -n 8192 (before it was 1024)... and I restarted asterisk, and im getting the warning |
| 14:44.46 | russellb | oh that's right, we made our own |
| 14:45.22 | Corydon76-home | russellb: Yes, but only if configure said we're allowed to increase it |
| 14:45.45 | Corydon76-home | If a) configure runs as a user, and b) asterisk runs as a user, then it cannot increase the limit |
| 14:46.28 | Corydon76-home | Some platforms resist increasing that limit beyond 1024. |
| 14:46.54 | acidfoo | so is it dangerous to increase limit after compile time ? Or I should recompile asterisk |
| 14:47.12 | Corydon76-home | Did you run configure as root or as your own user? |
| 14:47.49 | kpfleming | runtime behavior changes based on whether the configure script was run as root or not sounds like bad news |
| 14:48.12 | Corydon76-home | kpfleming: You're welcome to check the code, but it was unavoidable |
| 14:48.19 | acidfoo | I'm sorry I don't know, I'm not the one who installed the server, but Im happy to learn that the behavior changes based on wether its run by root or user |
| 14:48.59 | Corydon76-home | kpfleming: if configure was run as root, then Asterisk tries to run the same test at startup, if it starts as root, prior to changing the user |
| 14:49.22 | kpfleming | Corydon76-home: i'm sure that's true. my point is that if it was unavoidable, then then this side-effect needs to be *clearly* documented, or the entire thing needs to be reconsidered. this is a potentially very surprising and hard-to-debug behavior change. |
| 14:49.51 | Corydon76-home | kpfleming: only if you increase the limit beyond 1024 |
| 14:50.42 | kpfleming | which is very common in the asterisk community, and is frequently pointed out as the solution to a number of problems |
| 14:50.43 | Corydon76-home | acidfoo: what version of 1.4 are you running? The latest, or...? |
| 14:51.04 | acidfoo | Corydon76-home, well, the version of asterisk on which its happening is 1.4 |
| 14:51.19 | Corydon76-home | 1.4 is a branch, not a release version |
| 14:51.20 | acidfoo | ill tell you the exact version, sec |
| 14:51.31 | acidfoo | yeah, I misread your sentence sorry, ill check |
| 14:52.03 | acidfoo | 1.4.41 |
| 14:53.18 | acidfoo | 1.4.41 |
| 14:53.21 | acidfoo | oups |
| 14:54.21 | Corydon76-home | Looks like that version has a bug in select.h that was corrected in the next version |
| 14:54.35 | acidfoo | whats is the bug ;) |
| 14:55.28 | Corydon76-home | There's a miscalculation. In all fixed versions, you'll find a _bitsize macro |
| 14:55.29 | kpfleming | look in the changelog for 1.4.42, you should be able to find it yourself |
| 14:56.03 | acidfoo | ok thank you |
| 14:58.43 | *** join/#asterisk-dev Gugge (~gugge@91.208.16.1) |
| 15:05.04 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 15:05.16 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:05.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:12.59 | anonymouz666 | the kernel guy is in da house, please rebuild your kernels. |
| 15:13.34 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:13.34 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:37.39 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 15:54.15 | *** join/#asterisk-dev rgagnon (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 15:54.17 | *** part/#asterisk-dev rgagnon (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 15:57.32 | *** join/#asterisk-dev BMJ (~bjohns@c-24-126-158-110.hsd1.ga.comcast.net) |
| 15:57.32 | *** mode/#asterisk-dev [+o BMJ] by ChanServ |
| 17:28.31 | *** join/#asterisk-dev irroot (~irroot@41.54.163.107) |
| 17:32.28 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:35.20 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:35.20 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:49.13 | russellb | s/1.10/2.0/ ... thoughts/opinions? :-) |
| 18:49.28 | Qwell | veto |
| 18:49.36 | russellb | vetoveto |
| 18:58.10 | kpfleming | +3.1415926737 |
| 18:58.51 | tzafrir_laptop | 1.9 |
| 18:59.30 | Qwell | I like tzafrir_laptops style. |
| 18:59.36 | Qwell | just put it off for 6 months :p |
| 19:00.03 | tzafrir_laptop | Asterisk version numbers look to me like IPv4 addresses. Therefore skipping the odd ones seems like a shameful waste |
| 19:00.15 | tzafrir_laptop | And we're in short supply of addresses, right? |
| 19:00.33 | Qwell | so what you're saying, is that we should go to ::1:10:0:1 ? |
| 19:00.41 | russellb | I also thought about proposing 3.0 |
| 19:00.47 | russellb | skip even numbers on the first digit |
| 19:00.55 | kpfleming | you did propose 3.0 |
| 19:01.01 | russellb | that's true |
| 19:01.06 | leifmadsen | Asterisk 10 |
| 19:01.08 | leifmadsen | just drop the 1. |
| 19:01.09 | russellb | and 3.0 > 2.0 |
| 19:01.17 | russellb | Asterisk KittyKat |
| 19:01.25 | leifmadsen | Asterisk Penguin |
| 19:01.46 | Qwell | Asterisk Beefy Miracle. |
| 19:01.48 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:01.48 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 19:01.53 | russellb | Qwell: lol |
| 19:02.04 | russellb | Qwell: there are many in Fedora land that would be so proud |
| 19:07.04 | jsmith | Qwell: Did you invoke the name of the Almighty Miracle? |
| 19:07.25 | Qwell | jsmith: I blame you, BTW. |
| 19:07.33 | Qwell | G+ wants me to add a bunch of RH people. |
| 19:07.40 | jsmith | Qwell: The all-beef deliverer from lesser foods? |
| 19:07.51 | jsmith | Qwell: That should be a hint of some kind ... |
| 19:08.00 | Qwell | O.o |
| 19:10.22 | russellb | o.O |
| 19:10.42 | russellb | speaking of Google+, we have a hangout goin' |
| 19:18.04 | jsmith | Oh? |
| 19:18.35 | kpfleming | it's a trap |
| 19:18.51 | russellb | and by we, i mean leifmadsen and I, and video-less putnopvut |
| 19:19.52 | jsmith | Does sound like a trap |
| 19:20.02 | jsmith | Unfortunately, I've got more important work to do right now :-) |
| 19:20.30 | russellb | it's a virtual shared office is all |
| 19:36.56 | Juggie | lol |
| 19:37.21 | Juggie | g+ hangout buddies |
| 19:39.29 | Juggie | lol... gotta love how my google+ feed shows me Russel; Bryant - Live! |
| 19:39.37 | Juggie | -; +l |
| 19:50.23 | russellb | silly google |
| 20:04.21 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 20:04.21 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:10.05 | *** join/#asterisk-dev rgagnon__ (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 20:10.05 | rgagnon__ | s it |
| 20:10.09 | rgagnon__ | oops |
| 20:10.11 | *** part/#asterisk-dev rgagnon__ (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 20:11.07 | irroot | bugger having channels left orphaned in asterisk and not been able to be shut down |
| 21:15.18 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:15.18 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:34.34 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 21:34.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:35.06 | Corydon76-home | Is there a reason why Bamboo does not seem to be reacting to commits? |
| 21:36.30 | Corydon76-home | Oh, poaceae appears to be offline |
| 21:46.44 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 21:46.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:22.11 | *** join/#asterisk-dev jkroon (~jkroon@dsl-241-252-52.telkomadsl.co.za) |
| 22:23.38 | jkroon | hi guys, russellb suggested i ask here rather. ast 1.8.5, using manager with webenabled=yes, if I send in a http request to the manager it crashes in http.c on ast_free(out), which is allocated in manager.c using ast_str_create - is this correct? |
| 22:24.15 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 22:24.15 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:24.39 | jkroon | http://pastebin.com/HJZFvXsT - sample backtrace (reproducable) |
| 22:26.37 | kpfleming | yes, it appears that ast_free() is the proper way to free a dynamically allocated ast_str object |
| 22:26.50 | russellb | yup, probably getting freed twice or something |
| 22:26.54 | russellb | try running under valgrind |
| 22:27.42 | jkroon | is there a way to ignore all the invalid reads under valgrind - startup gets me quite a few ? |
| 22:28.16 | russellb | yeah, it supports a suppression file. I think we have one in Asterisk somewhere |
| 22:28.32 | russellb | you can ignore all the dlopen() ones on startup |
| 22:29.56 | jkroon | a quick perusal of the code shows that it is impossible for a double-free |
| 22:30.52 | kpfleming | yeah, that's what i see too |
| 22:30.56 | russellb | where if another pointer in a different code path gets corrupted and ends up pointing to the same thing as that ast_str and _that_ gets freed? |
| 22:31.01 | russellb | :-p |
| 22:31.53 | jkroon | extremely unlikely. the caller of ast_http_send (which does the ast_free) is generic_http_callback (manager.c) is the one that does the ast_str_create |
| 22:32.16 | jkroon | it does a few ast_str_appends though which might extend the string object if I'm reading the documentation correctly in strings.h |
| 22:32.24 | kpfleming | they will |
| 22:33.04 | jkroon | capget pointing to unaddressable bytes? |
| 22:33.20 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 22:34.00 | jkroon | chan_sip has a few potential nasties ito uninitialized memory access. |
| 22:35.27 | jkroon | also getting accessess into freed memory on startup ... |
| 22:35.49 | kpfleming | russellb: here's an ugly for you: in http.c there is a call to "strlen(ast_str_buffer(out))" which should just be ast_str_strlen() instead. has nothing to do with this problem though :-) |
| 22:36.11 | jkroon | wondered about that. |
| 22:36.26 | russellb | neat |
| 22:36.29 | jkroon | is an ast_str guaranteed to be null terminated? |
| 22:36.39 | russellb | even better, ast_str_size(foo) ... |
| 22:36.42 | kpfleming | yes, it's still a C string |
| 22:36.45 | russellb | or ast_str_len() whatever it is |
| 22:36.52 | kpfleming | no, size != length |
| 22:37.01 | russellb | right, i think it has both |
| 22:37.09 | kpfleming | yes, and in this case it wants length |
| 22:37.09 | russellb | size isn't really useful outside the internals |
| 22:37.32 | kpfleming | so anyway... there's nothing obvious in the code that would cause this, jkroon :-( |
| 22:38.22 | jkroon | kpfleming, yea, i'm seeing that :( |
| 22:38.53 | jkroon | http://pastebin.com/DYNpy8yp <-- is this the kind of thing to worry about? |
| 22:39.07 | jkroon | because i'm seeing quite a bit of that during startup. |
| 22:39.40 | kpfleming | bang! found it. |
| 22:39.48 | jkroon | ?? |
| 22:39.56 | jkroon | do tell please |
| 22:40.02 | kpfleming | in process_output, an "ast_str *" is passed, and it calls ast_str_append() |
| 22:40.13 | kpfleming | this is bad... it needs to receive an "ast_str **" |
| 22:40.34 | kpfleming | otherwise if that append grows the string, bad things will result |
| 22:40.43 | kpfleming | this is manager.c |
| 22:40.51 | jkroon | hmm, no why? |
| 22:40.58 | kpfleming | what? |
| 22:41.18 | russellb | kpfleming: you win |
| 22:41.23 | kpfleming | russellb: thanks |
| 22:41.26 | jkroon | we have a pointer TO an ast_str struct. |
| 22:41.46 | kpfleming | right, which we can't replace if we need to grow the string |
| 22:41.53 | jkroon | once passed to ast_http_send the manager.c callback sets it's copy to NULL. |
| 22:42.00 | kpfleming | jkroon: slow down and let me answer |
| 22:42.09 | kpfleming | you have a *COPY* of a pointer to an ast_str |
| 22:42.28 | jkroon | so even if ast_http_send changes it's copy of the pointer on the stack all should still be sane? |
| 22:42.37 | kpfleming | if you call ast_str_append() and it decides to reallocate the ast_str so it can grow, your COPY will point to the new string, but the original copy will not |
| 22:42.44 | jkroon | ok ... ? |
| 22:42.53 | kpfleming | no, that new value is never carried back to process_output's caller |
| 22:43.06 | kpfleming | it still has the address of the original ast_str, which has now been freed |
| 22:43.24 | jkroon | in this case we don't care as the caller sets out=NULL directly after making the call. |
| 22:43.25 | kpfleming | this is the reason why xml_translate takes an "ast_str **" |
| 22:43.37 | kpfleming | after calling process_output? no it does not. |
| 22:43.52 | jkroon | goes looking for the process_output call. |
| 22:44.08 | kpfleming | russellb: shall i fix? |
| 22:44.15 | jkroon | bows down to the master. |
| 22:44.28 | russellb | kpfleming: that'd be great if you don't mind |
| 22:44.31 | jkroon | well spotted. |
| 22:44.32 | kpfleming | will do |
| 22:44.37 | kpfleming | it will only take a few minutes |
| 22:44.57 | jkroon | pastebin to confirm? |
| 22:45.10 | jkroon | of the valgrind output ? |
| 22:45.32 | kpfleming | no, this is obviously what is happening, it's the only place in the code path where the ast_str can be freed before calling http_send |
| 22:45.52 | jkroon | well, valgrind concurs :) |
| 22:46.06 | jkroon | http://pastebin.com/r1rACjEf <- first block. |
| 22:46.07 | kpfleming | jkroon: can you go look in the issue tracker to see if there are any open issues about this problem? |
| 22:46.18 | jkroon | kpfleming, i can't get into jira. |
| 22:46.27 | kpfleming | why not? |
| 22:46.29 | jkroon | i've tried about three times now without any success. |
| 22:46.39 | kpfleming | you don't need to log in to search for issues |
| 22:46.40 | jkroon | can't get my password reset after the migration from mantis. |
| 22:46.57 | kpfleming | well, we should get that fixed :-) |
| 22:46.59 | jkroon | can someone help me get that reset anyway please? |
| 22:47.14 | jkroon | email addy is jaco@uls.co.za |
| 22:47.17 | kpfleming | i can do that while this compiles... what is your username? |
| 22:47.47 | jkroon | should be jkroon |
| 22:47.53 | kpfleming | ahh... jkroon, how obvious :_) |
| 22:49.33 | russellb | almost TOO obvious ... |
| 22:50.08 | jkroon | figured out why I don't get the reset link. |
| 22:50.17 | jkroon | 2011-07-13 00:49:31 H=mail.digium.com [216.207.245.2] F=<noreply@issues.asterisk.org> temporarily rejected RCPT <jaco@uls.co.za>: Could not complete sender verify callout |
| 22:50.21 | kpfleming | i just messaged you your new password |
| 22:50.32 | jkroon | got it thanks. |
| 22:50.53 | jkroon | email should be fixed too. |
| 22:53.10 | jkroon | take it this same issue could be coming from 1.6.2 as well? |
| 22:53.26 | kpfleming | certainly possible, did not check |
| 22:53.50 | jkroon | (had some very weird memory corruption recently on it which I actually suspected could be the string_fields api but after this something like this seems more reasonable) |
| 22:54.24 | jkroon | that's actually what prompted the upgrade to 1.8 ... asterisk segfaulting 10+/day was getting annoying. |
| 22:54.52 | kpfleming | it's now fixed in the 1.8 branch |
| 22:54.58 | Qwell | hooray! |
| 22:55.12 | jkroon | link to a patch perhaps? |
| 22:55.24 | kpfleming | in the asterisk-commits list archive, sure |
| 22:55.39 | kpfleming | i'm sort of surprised there aren't any tests in the testsuite that would have triggered this |
| 22:56.22 | jkroon | https://issues.asterisk.org/jira/browse/ASTERISK-11714 |
| 22:56.29 | jkroon | https://issues.asterisk.org/jira/browse/ASTERISK-17441 |
| 22:56.40 | russellb | kpfleming: it's AMI over HTTP using XML right? or what |
| 22:56.49 | kpfleming | no, it was non XML |
| 22:56.59 | kpfleming | well, XML mode would have caused it too |
| 22:57.00 | russellb | but still AMI-HTTP? |
| 22:57.04 | jkroon | AMI in this case. |
| 22:57.05 | kpfleming | yes, HTTP mode AMI |
| 22:57.13 | russellb | we use AMI a lot, but not via HTTP |
| 22:57.27 | russellb | testsuite + unit tests still only have 20 to 25 percent code coverage :-/ |
| 22:57.27 | kpfleming | jkroon: you saw this with regular AMI? |
| 22:57.41 | jkroon | too, but in this case i load info for an http page - so found it simpler to just use CURL to http get. |
| 22:57.52 | jkroon | no, i don't. regular AMI works like a charm. |
| 22:58.02 | russellb | makes sense, that's what it's for |
| 22:58.40 | kpfleming | well, this should have broken asterisk 1.8 for anyone using the asterisk-gui, at least |
| 22:58.53 | jkroon | https://issues.asterisk.org/jira/browse/ASTERISK-14461 |
| 22:59.13 | jkroon | so far all three those links seems to be potentially related. |
| 23:00.07 | Qwell | 323608 |
| 23:00.07 | jkroon | https://issues.asterisk.org/jira/browse/ASTERISK-9098 |
| 23:00.38 | kpfleming | umm... 14461 is closed |
| 23:01.32 | jkroon | should look at Status: :( |
| 23:01.47 | kpfleming | or change your filter to only include unresolved issues and let jira do the work for you |
| 23:01.55 | jkroon | that too |
| 23:02.05 | jkroon | i'll get there - first time using jira. |
| 23:02.12 | kpfleming | oh yeah |
| 23:02.45 | jkroon | guess this will be available as of 1.8.5.1 only? |
| 23:03.48 | russellb | 1.8.6 |
| 23:04.04 | kpfleming | feel free to apply the patch locally though, you have the source |
| 23:04.09 | jkroon | ok, i take it we're back to a three-digit scheme? |
| 23:04.09 | kpfleming | and with that, i'm out |
| 23:04.13 | jkroon | i am going to :) |
| 23:04.19 | jkroon | good night and thanks. |
| 23:04.25 | Qwell | russellb: 1.8.6.0 :) |
| 23:04.30 | russellb | oh, right |
| 23:04.43 | russellb | Qwell: tech support asked me why 1.8.5 was 1.8.5.0 today, heh |
| 23:04.44 | jkroon | ok, the ast numbering scheme confuses me. |
| 23:04.54 | russellb | i kind of stuttered and ended with "just because we felt like it" |
| 23:04.54 | jkroon | russellb, so why is it? |
| 23:04.58 | russellb | ^^^ |
| 23:06.16 | jkroon | ok, dumb question: where can I view the actual patch?!? |
| 23:20.38 | russellb | http://svnview.digium.com/svn/asterisk?view=revision&revision=327950 |
| 23:22.24 | jkroon | thanks. just found it just now ... internet is just horribly slow here. |
| 23:22.48 | leifmadsen | jkroon: because we sometimes use the 4th digit to indicate small changes within a version, and thus the .0 should really have always been there |
| 23:23.04 | russellb | just in case, maybe it should be 1.8.5.0.0.0 |
| 23:23.15 | leifmadsen | russellb: we would never do 1.8.5.1.1 |
| 23:23.22 | russellb | don't test me! |
| 23:23.35 | leifmadsen | russellb: sounds like you want to do releases again then |
| 23:23.40 | jkroon | leifmadsen, makes sense. but the numbering on 1.6.2.x.y really got out of hand imho. |
| 23:23.41 | leifmadsen | don't tempt me! |
| 23:23.50 | russellb | jkroon: agreed |
| 23:23.51 | jkroon | the scheme for 1.8 makes more sense. |
| 23:23.55 | leifmadsen | jkroon: well it's the same thing, we just have a 1.8 vs 1.6.x |
| 23:24.52 | jkroon | no, 1.6.1.x and 1.6.2.17.3. this is one of those things that can be debated until the cows come home by themselves though. |
| 23:25.00 | leifmadsen | well there is no need to debate it |
| 23:25.02 | leifmadsen | it is done |
| 23:25.08 | leifmadsen | we tried something, didn't work, we fixed it |
| 23:25.14 | jkroon | cool :) |
| 23:25.16 | leifmadsen | 1.6.1 vs 1.6.2 is a major version just like 1.4 vs 1.8 |
| 23:25.18 | leifmadsen | same thing |
| 23:25.22 | leifmadsen | just 1 less number now |
| 23:25.23 | russellb | just more confusing |
| 23:25.24 | russellb | yay |
| 23:25.34 | leifmadsen | so the release numbering scheme isnt' really any different |
| 23:25.44 | leifmadsen | 1.4.28.1 vs 1.8.5.0 |
| 23:25.52 | leifmadsen | same number of versions |
| 23:25.57 | leifmadsen | (version number place holders) |
| 23:26.07 | jkroon | yes, 1.4 made sense for me, 1.6 didn't, 1.8 is good again :) |
| 23:26.15 | leifmadsen | ok |
| 23:26.21 | leifmadsen | russellb: lets go eat |
| 23:26.30 | russellb | word |
| 23:26.30 | leifmadsen | my stomach has the hunger |
| 23:26.33 | jkroon | enjoy. |
| 23:26.38 | jkroon | adious. |
| 23:26.44 | *** part/#asterisk-dev jkroon (~jkroon@dsl-241-252-52.telkomadsl.co.za) |