Turns out others have been having problems here too. Yu Zou has a fix
for something in this area via bug TS-3140.
That fix addresses part of my issues, but I have a couple more resources
to free. I'll take over his bug and add my fixes to his.
On 1/15/2015 8:36 PM, Susan Hinrichs wrote:
Has anyone used redirection_enabled recently (in the last couple
years?). I'm debugging an ink_release_assert reported by someone
running in production. But when I run even the most basic 301 through
it in debug mode, I get ink_asserts in
HttpSM::state_cache_open_read(). It is checking that server_entry ==
NULL before it assigns server_entry.
In production mode, these asserts are ignored, and the server data
structures set up when talking to the original server are overwritten
and presumably leaking memory. There is logic that sets
t_state.api_release_server_session which should later cause
release_server_session() to be called. The flag is set, but
release_server_session() is never called.
I did most of my testing on variants of 5.x. But Alan had 4.2.x and
3.2.x builds laying around, and we see the same asserts on those
builds as well.
I assume the logic leading to the cleanup call got messed up somewhere
along the way. But since it has been that way for so long, perhaps we
are not setting up the redirect_enabled correctly or missing something
else obvious. Please let me know of you are actively using this
feature successfully.
Thanks,
Susan
