Le 11/04/2018 à 16:11, Hessam Mirsadeghi a écrit :
You're right; that segfault happens with the build at the faulty commit
and not later versions such as v1.8.5.
However, version v1.8.5 does segfault with the attached modified Lua
script. As far as I can tell, the problem arises after any call to
In the attached Lua script, if you remove the call to either of
"txn.res:set(txn.res:get())" or "txn.res:forward(txn.res:get_in_len())",
the segfault will disappear.
Also, when I only have a call to "txn.res:set(txn.res:get())" in the
script, haproxy becomes unresponsive to all but the first request on
each persistent connection. That is, something like "curl -sig
localhost:80 localhost:80" will only get the response for the first
request; the second one times out on the existing connection and
succeeds only on a a second connection established by curl.
So, with this script, I have a segfault. But not only with HAProxy 1.8
and higher. It also crashes on HAProxy 1.7. Actually, It will crash on
all versions. This is a Lua problem not a HTTP one.
IMHO, "Channel.set" or "Channel.get" must never be used on HTTP
messages. These functions totally hijack the HTTP parser. There is an
attempt to restore the HTTP parser state. But this is only partially
done (the headers' analysis is done, but not all of the ensuing
analysis). So the result is undefined. It will seem to work for simpler
cases but will fail most of time. Same remarks are true for
"Channel.getline" and "Channel.append".
"Channel.forward" (and "Channel.send") must also never be used on HTTP
messages. When called, the messages analysis is in progress. The HTTP
parser expects to have all the headers at this stage. Mixing message
analysis and data forward is totally unexpected.
I will let Thierry (the Lua maintainer) decide what to do. But, I guess
he will restrict usage of all these functions to TCP streams only.
So now, maybe you can describe what you try to do. There is probably
another way to achieve it. I hope so, because it will never work this way.