[PATCH] DOC/MINOR: fix typos in the lua-api document
Fixes a few typos in the Lua API document. --- doc/lua-api/index.rst | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/lua-api/index.rst b/doc/lua-api/index.rst index d1dd3397e..515d8853b 100644 --- a/doc/lua-api/index.rst +++ b/doc/lua-api/index.rst @@ -1357,7 +1357,7 @@ Channel class .. warning:: It is not possible to read from the response in request action, and it is -not possible to read for the request channel in response action. +not possible to read from the request channel in response action. .. warning:: It is forbidden to alter the Channels buffer from HTTP contexts. So only @@ -1368,7 +1368,7 @@ Channel class All the functions provided by this class are available in the **sample-fetches**, **actions** and **filters** contexts. For **filters**, incoming data (offset and length) are relative to the filter. Some functions - may yield, by only for **actions**. Yield is not possible for + may yield, but only for **actions**. Yield is not possible for **sample-fetches**, **converters** and **filters**. .. js:function:: Channel.append(channel, string) @@ -1567,7 +1567,7 @@ Channel class **DEPRECATED** This function returns all incoming data found in the channel buffer. The data - are not remove from the buffer and can be reprocessed later. + are not removed from the buffer and can be reprocessed later. If there is no incoming data and the channel can't receive more data, a 'nil' value is returned. @@ -1621,7 +1621,7 @@ Channel class :returns: a string containing the line found or nil. .. warning:: - This function is depdrecated. :js:func:`Channel.line()` must be used to + This function is deprecated. :js:func:`Channel.line()` must be used to retrieve a line followed by a call to :js:func:`Channel:remove()` to remove data. @@ -1634,7 +1634,7 @@ Channel class .. js:function:: Channel.get_in_len(channel) - **DEPDRECATED** + **DEPRECATED** This function returns the length of the input part of the buffer. When called by a filter, this value is relative to the filter. @@ -1648,7 +1648,7 @@ Channel class .. js:function:: Channel.get_out_len(channel) - **DEPDRECATED** + **DEPRECATED** This function returns the length of the output part of the buffer. When called by a filter, this value is relative to the filter. -- 2.35.1
[PATCH] BUG/MEDIUM: lua: fix argument handling in data removal functions
Lua API Channel.remove() and HTTPMessage.remove() expects 1 to 3
arguments (counting the manipulated object), with offset and length
being the 2nd and 3rd argument, respectively.
hlua_{channel,http_msg}_del_data() incorrectly gets the 3rd argument as
offset, and 4th (nonexistent) as length. hlua_http_msg_del_data() also
improperly checks arguments. This patch fixes argument handling in both.
Must be backported to 2.5.
---
src/hlua.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/src/hlua.c b/src/hlua.c
index 05f3a9053..2327553c8 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -3714,8 +3714,8 @@ __LJMP static int hlua_channel_del_data(lua_State *L)
WILL_LJMP(lua_error(L));
offset = output;
- if (lua_gettop(L) > 2) {
- offset = MAY_LJMP(luaL_checkinteger(L, 3));
+ if (lua_gettop(L) > 1) {
+ offset = MAY_LJMP(luaL_checkinteger(L, 2));
if (offset < 0)
offset = MAX(0, (int)input + offset);
offset += output;
@@ -3726,8 +3726,8 @@ __LJMP static int hlua_channel_del_data(lua_State *L)
}
len = output + input - offset;
- if (lua_gettop(L) == 4) {
- len = MAY_LJMP(luaL_checkinteger(L, 4));
+ if (lua_gettop(L) == 3) {
+ len = MAY_LJMP(luaL_checkinteger(L, 3));
if (!len)
goto end;
if (len == -1)
@@ -6704,8 +6704,7 @@ __LJMP static int hlua_http_msg_del_data(lua_State *L)
int offset, len;
if (lua_gettop(L) < 1 || lua_gettop(L) > 3)
- WILL_LJMP(luaL_error(L, "'insert' expects at most 2
arguments"));
- MAY_LJMP(check_args(L, 2, "insert"));
+ WILL_LJMP(luaL_error(L, "'remove' expects at most 2
arguments"));
msg = MAY_LJMP(hlua_checkhttpmsg(L, 1));
if (msg->msg_state < HTTP_MSG_DATA)
@@ -6716,8 +6715,8 @@ __LJMP static int hlua_http_msg_del_data(lua_State *L)
WILL_LJMP(lua_error(L));
offset = input + output;
- if (lua_gettop(L) > 2) {
- offset = MAY_LJMP(luaL_checkinteger(L, 3));
+ if (lua_gettop(L) > 1) {
+ offset = MAY_LJMP(luaL_checkinteger(L, 2));
if (offset < 0)
offset = MAX(0, (int)input + offset);
offset += output;
@@ -6728,8 +6727,8 @@ __LJMP static int hlua_http_msg_del_data(lua_State *L)
}
len = output + input - offset;
- if (lua_gettop(L) == 4) {
- len = MAY_LJMP(luaL_checkinteger(L, 4));
+ if (lua_gettop(L) == 3) {
+ len = MAY_LJMP(luaL_checkinteger(L, 3));
if (!len)
goto end;
if (len == -1)
--
2.35.1
Re: Backporting "MEDIUM: mworker: reexec in waitpid mode after successful loading" to 2.4
On Tue, May 10, 2022 at 12:09:59PM +0200, Christian Ruppert wrote: > > It even just happened when running with gdb, without a reload. > What the patch does is re-executing the master in wait-mode once the worker was started in order to free the master memory of huge data (maps, SSL certificates etc). I thought your crash was unrelated but indeed what is weird is that you experienced a watchdog crash in the master... which is is really surprising since the master does not do much. > Does that help? You mworker commit *seems*, at least at the first > glance, to fix that. Without I have multiple coredumps within 24 hours. > Often I can trigger some by just reloading/restarting. With your commit > I couldn't for almost 24 hours + doing 100 reloads with 10s sleep > between each. > Let me know if you want me to turn on some debug flags or something > else. Or do you want a dump? I'd share it off-list then. That does help indeed, but I will need a full coredump with the binaries to analyze what provoked this watchdog in the master! Is it a problem you have since a while or did it happens with an update? It's not impossible that a fix provoked this. -- William Lallemand
Re: Backporting "MEDIUM: mworker: reexec in waitpid mode after successful loading" to 2.4
On Tue, May 10, 2022 at 11:05:01AM +0200, Christian Ruppert wrote: > Hi guys, William, > > can we please get that "MEDIUM: mworker: reexec in waitpid mode after > successful loading" - fab0fdce981149a4e3172f2b81113f505f415595 > backported to 2.4? > I seem to run into it, at least on one of our 40 LBs. This one is a VM > though. It sometimes crashes after each reload. Running 2.5 with > fab0fdce981149a4e3172f2b81113f505f415595 seems to fix the issue for me. > > https://github.com/haproxy/haproxy/commit/fab0fdce981149a4e3172f2b81113f505f415595 > Hello Christian, Honestly we run into a lot of issues and bugfixes after this patch was pushed, I don't think it's even possible to backport this without breaking the 2.4, there are a lot of corner cases and I don't want to break this branch which is pretty stable now. 2.5 already runs with this architecture for a while in some places which make it more robust but it was not easy to get there. Also the next LTS version which is 2.6 is almost there! What kind of crashes are you experimenting? It's supposed to help with the possible OOM on reload when too much memory was consumed by the master. -- William Lallemand
Backporting "MEDIUM: mworker: reexec in waitpid mode after successful loading" to 2.4
Hi guys, William, can we please get that "MEDIUM: mworker: reexec in waitpid mode after successful loading" - fab0fdce981149a4e3172f2b81113f505f415595 backported to 2.4? I seem to run into it, at least on one of our 40 LBs. This one is a VM though. It sometimes crashes after each reload. Running 2.5 with fab0fdce981149a4e3172f2b81113f505f415595 seems to fix the issue for me. https://github.com/haproxy/haproxy/commit/fab0fdce981149a4e3172f2b81113f505f415595 -- Regards, Christian Ruppert
