[
https://issues.apache.org/jira/browse/TS-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007584#comment-14007584
]
Alan M. Carroll commented on TS-2820:
-------------------------------------
I'm not completely clear on what is supposed to happen, but I see the root
cause.
What happens is the producer chunked handler detects the end of the chunks and
therefore does a half shut down on the VC, on the write side by the producer
handler calling do_io_shutdown with an argument of IO_SHUTDOWN_WRITE on the
producer continuation. This is a call to INKVConnInternal::do_io_shutdown which
closes up the write VIO but - this is the key part - WITHOUT SETTING m_closed.
I tried setting it there but that crashes immediately because of m_event_count
being zero (contrast with how this is handled in
INKVConnInternal::do_io_close). I presume the difference is do_io_shutdown is a
a half close.
After doing the half close, INKVConnInternal::do_io_shutdown schedules an
immediate EVENT_IMMEDIATE for itself, which then hits the CPP API
handleTransformPluginEvent which goes to handleTransformPluginRead. That,
detecting nothing left to read, attempts to do another shutdown which crashes
because it's the second shutdown.
The fix is to change the condition at TransformationPlugin.cc:174 to be
{code}
if (vio_cont && 0 != TSVIOBufferGet(write_vio))
{code}
This detects the case where the write side has been closed and doesn't do
another shutdown and avoids the crash.
> Crash in transformations
> ------------------------
>
> Key: TS-2820
> URL: https://issues.apache.org/jira/browse/TS-2820
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Brian Geffon
> Assignee: Brian Geffon
> Fix For: 5.0.0
>
>
> I'm seeing an easy to reproduce crash in 4.2.0 and master (5.0.0), so I'm
> assuming it was introduced between 3.2.x and 4.1.0. To reproduce I'm using a
> simple null transformation plugin and just making repeated curl requests.
> HttpTunnel::consumer_handler (this=0x7fffea652db8, event=103,
> c=0x7fffea652e08) at HttpTunnel.cc:1300
> 1300 c->buffer_reader->mbuf->dealloc_reader(c->buffer_reader);
> (gdb) bt
> #0 HttpTunnel::consumer_handler (this=0x7fffea652db8, event=103,
> c=0x7fffea652e08) at HttpTunnel.cc:1300
> #1 0x00000000005e6a2d in HttpTunnel::main_handler (this=0x7fffea652db8,
> event=<optimized out>, data=<optimized out>) at HttpTunnel.cc:1525
> #2 0x00007ffff27e9981 in handleTransformationPluginRead
> (state=0x7fffa00d7db0, contp=0x7fffd4021b70) at TransformationPlugin.cc:175
> #3 (anonymous namespace)::handleTransformationPluginEvents (contp=<optimized
> out>, event=<optimized out>, edata=<optimized out>)
> at TransformationPlugin.cc:217
> #4 0x000000000073792f in handleEvent (data=0x7fffdc18fbf0, event=1,
> this=<optimized out>) at I_Continuation.h:181
> #5 EThread::process_event (this=0x7ffff67d5010, e=0x7fffdc18fbf0,
> calling_code=1) at UnixEThread.cc:145
> #6 0x000000000073845b in EThread::execute (this=0x7ffff67d5010) at
> UnixEThread.cc:196
> #7 0x0000000000736cda in spawn_thread_internal (a=0x10898d0) at Thread.cc:88
> #8 0x00000033a1607851 in start_thread () from /lib64/libpthread.so.0
> #9 0x00000033a12e890d in clone () from /lib64/libc.so.6
> A sample debug output is available: http://apaste.info/aPK
--
This message was sent by Atlassian JIRA
(v6.2#6252)
