You can check out https://github.com/apache/trafficserver/pull/8607
That should essentially be doing what you want for server request
pointers as well.
Can you try this out?
On Tue, Jun 28, 2022 at 2:16 PM CHOU, PETER <pc6...@att.com> wrote:
>
> Kit,
>
> This problem originally happened to us on 7.1.4 (see below), but it
> seemed to stop after a while. I thought it might be fixed, but now it
> has happened a few times with 9.1.2. It is very rare, happening three
> times on two of our caches in the last month or so.
>
> My question is this. Do you think it is sufficient to clear the saved
> server_request_url and server_request_hdrp pointers in the
> call-back for the TS_EVENT_HTTP_SEND_REQUEST_HDR hook similar to what is
> done for the similar issue for the client response (7236e), or
> would it be better to clear the pointers and do the TSHandleMLocRelease
> within each function in ts_lua_server_request.c ( thus doing the
> release within the same call-back ) ?
>
> Thanks,
> Peter
>
> -----Original Message-----
> From: Shu Kit Chan <chanshu...@gmail.com>
> Sent: Monday, June 22, 2020 10:36 PM
> To: dev <dev@trafficserver.apache.org>
> Subject: Re: Lua plugin assertion failure question.
>
> 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
