I actually haven't experienced this before for the server request
You mentioned in another thread that this may be related to you guys
setting open_write_fail_action to 4 in parent layer ?
If you can consistently reproduce this, you can perhaps add the
protection similar to client response and see if it is solving the
coredump problem.
I believe that it should not be too much of a problem in terms of efficiency.
Thanks.
Kit
On Wed, Jun 17, 2020 at 5:11 PM Chou, Peter <pbc...@labs.att.com> wrote:
>
> Hi All,
>
> We recently experienced a bunch of assertion failures with the Lua plugin on
> ATS 7.1.4. When the transaction is being killed, the Lua plugin calls
> ts_lua_destroy_http_ctx() which calls TSHandleMLocRelease() with
> http_ctx->server_request_bufp as the buffer argument. The assertion failure
> is -
> Fatal: InkAPI.cc:1917: failed assertion `sdk_sanity_check_mbuffer(bufp) ==
> TS_SUCCESS`
>
> Is it possible that the data structure for the server request is changed
> within the life-time of the transaction making the pointer invalid? I noticed
> that this was possible
> for client responses addressed in 7236e excerpt -
>
> + // client response can be changed within a transaction
> + // (e.g. due to the follow redirect feature). So, clearing the pointers
> + // to allow API(s) to fetch the pointers again when it re-enters the hook
> + if (http_ctx->client_response_hdrp != NULL) {
> + TSHandleMLocRelease(http_ctx->client_response_bufp, TS_NULL_MLOC,
> http_ctx->client_response_hdrp);
> + http_ctx->client_response_bufp = NULL;
> + http_ctx->client_response_hdrp = NULL;
> + }
>
> Is something similar possible with the server request which uses the same
> kind of null pointer check around the setting of the bufp and hdrp pointers?
>
> Back-trace -
>
> (gdb) bt
> #0 0x00002b94af14f377 in raise () from /lib64/libc.so.6
> #1 0x00002b94af150ba8 in abort () from /lib64/libc.so.6
> #2 0x00002b94ac7bdeeb in ink_abort
> (message_format=message_format@entry=0x2b94ac7ca767 "%s:%d: failed assertion
> `%s`")
> at ink_error.cc:99
> #3 0x00002b94ac7bbf75 in _ink_assert (expression=<optimized out>,
> file=<optimized out>, line=<optimized out>)
> at ink_assert.cc:37
> #4 0x00000000004c827a in TSHandleMLocRelease ()
> #5 0x00002b94b3c51f08 in ts_lua_destroy_http_ctx (http_ctx=0x2b94e7d85a20)
> at experimental/ts_lua/ts_lua_util.c:464
> #6 0x00002b94b3c5271a in ts_lua_http_cont_handler (contp=<optimized out>,
> ev=TS_EVENT_HTTP_TXN_CLOSE, edata=0x2b94b4d39340)
> at experimental/ts_lua/ts_lua_util.c:791
> #7 0x00000000004c5fde in INKContInternal::handle_event(int, void*) ()
> #8 0x0000000000589ce4 in HttpSM::state_api_callout(int, void*) ()
> #9 0x0000000000590a7d in HttpSM::kill_this() ()
> #10 0x00000000005916d8 in HttpSM::main_handler(int, void*) ()
> #11 0x000000000072f103 in UnixNetVConnection::mainEvent(int, Event*) ()
> #12 0x0000000000726459 in InactivityCop::check_inactivity(int, Event*) ()
> #13 0x0000000000755040 in EThread::process_event(Event*, int) ()
> #14 0x0000000000755da1 in EThread::execute_regular() ()
> #15 0x0000000000754a9a in spawn_thread_internal(void*) ()
> #16 0x00002b94ae4e1ea5 in start_thread () from /lib64/libpthread.so.0
> #17 0x00002b94af2178cd in clone () from /lib64/libc.so.6
>
> Thanks,
> Peter
