[
https://issues.apache.org/jira/browse/TS-4444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15284191#comment-15284191
]
Oknet Xu commented on TS-4444:
------------------------------
I'm also met this issue on branch 6.0.x.
{code}
traffic_server: Segmentation fault (Address not mapped to object [(nil)])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(crash_logger_invoke(int, siginfo*,
void*)+0xa2)[0x2ad121596e32]
/lib/x86_64-linux-gnu/libc.so.6(+0x321a0)[0x2ad1252711a0]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0xca)[0x2ad1216ab19a]
/usr/bin/traffic_server(HttpTunnel::main_handler(int,
void*)+0x5e)[0x2ad1216ab58e]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0xfd)[0x2ad12166ea9d]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x80)[0x2ad12166cb10]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x4e7)[0x2ad121808687]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0x287)[0x2ad1217fe8d7]
/usr/bin/traffic_server(EThread::process_event(Event*,
int)+0x90)[0x2ad12182a020]
/usr/bin/traffic_server(EThread::execute()+0x69e)[0x2ad12182ac4e]
/usr/bin/traffic_server(+0x39938a)[0x2ad12182938a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x2ad1255d3b50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2ad12531d30d]
{code}
the stack:
{code}
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0xca)[0x2ad1216ab19a]
{code}
hit the code:
{code}
c->buffer_reader->mbuf->dealloc_reader(c->buffer_reader);
{code}
and segment fault at:
{code}
TS_INLINE void
MIOBuffer::dealloc_reader(IOBufferReader *e)
{
if (e->accessor) { <---- here
ink_assert(e->accessor->writer() == this);
ink_assert(e->accessor->reader() == e);
e->accessor->clear();
}
e->clear();
}
{code}
due to {{c->buffer_reader}} is {{NULL}}, {{c->buffer_reader->accessor}} leads
segment fault.
but, looking around the code:
{code}
case VC_EVENT_INACTIVITY_TIMEOUT:
ink_assert(c->alive);
ink_assert(c->buffer_reader); <------ here has a assert for
c->buffer_reader
c->alive = false;
c->bytes_written = c->write_vio ? c->write_vio->ndone : 0;
// Interesting tunnel event, call SM
jump_point = c->vc_handler;
(sm->*jump_point)(event, c); <------ I guess, c->buffer_reader is set
to NULL here.
// Make sure the handler_state is set
// Necessary for post tunnel end processing
if (c->producer && c->producer->handler_state == 0) {
if (event == VC_EVENT_WRITE_COMPLETE)
c->producer->handler_state = HTTP_SM_POST_SUCCESS;
else if (c->vc_type == HT_HTTP_SERVER)
c->producer->handler_state = HTTP_SM_POST_UA_FAIL;
else if (c->vc_type == HT_HTTP_CLIENT)
c->producer->handler_state = HTTP_SM_POST_SERVER_FAIL;
}
sm_callback = true;
// Deallocate the reader after calling back the sm
// because buffer problems are easier to debug
// in the sm when the reader is still valid
if (c->buffer_reader) {
c->buffer_reader->mbuf->dealloc_reader(c->buffer_reader);
c->buffer_reader = NULL;
}
{code}
> Segfault accessing NULL connection buffer reader
> ------------------------------------------------
>
> Key: TS-4444
> URL: https://issues.apache.org/jira/browse/TS-4444
> Project: Traffic Server
> Issue Type: Bug
> Reporter: David Calavera
> Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> A few days ago, we found a segfault trying to use the master branch in
> staging. Using ATS as a proxy to another http server, we managed to segfault
> ATS with simple client requests.
> This problem is hard to reproduce, we've seen it connecting clients from Mac
> OS X and Linux, but it doesn't always happen.
> This is the crash:
> {code}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff2f83700 (LWP 20224)]
> HttpTunnel::consumer_handler (this=this@entry=0x7fffe8fa4d28, event=103,
> c=0x7fffe8fa4dd8) at HttpTunnel.cc:1340
> 1340 c->buffer_reader->mbuf->dealloc_reader(c->buffer_reader);
> (gdb) bt
> #0 HttpTunnel::consumer_handler (this=this@entry=0x7fffe8fa4d28, event=103,
> c=0x7fffe8fa4dd8) at HttpTunnel.cc:1340
> #1 0x00000000005ea395 in HttpTunnel::main_handler (this=0x7fffe8fa4d28,
> event=<optimized out>, data=<optimized out>) at HttpTunnel.cc:1574
> #2 0x000000000068df8f in handleEvent (data=0x7fffe4218e00, event=<optimized
> out>, this=<optimized out>) at ../../iocore/eventsystem/I_Continuation.h:153
> #3 CacheVC::calluser (this=0x7fffe4218bb0, event=<optimized out>) at
> ../../iocore/cache/P_CacheInternal.h:628
> #4 0x0000000000704c95 in CacheVC::openWriteMain (this=0x7fffe4218bb0) at
> CacheWrite.cc:1350
> #5 0x00000000007627d0 in handleEvent (data=0x7fffe41d4f80, event=1,
> this=<optimized out>) at I_Continuation.h:153
> #6 EThread::process_event (this=0x7ffff3085010, e=0x7fffe41d4f80,
> calling_code=1) at UnixEThread.cc:130
> #7 0x000000000076348b in EThread::execute (this=0x7ffff3085010) at
> UnixEThread.cc:184
> #8 0x000000000076224a in spawn_thread_internal (a=0x10affa0) at Thread.cc:86
> #9 0x00007ffff6890182 in start_thread (arg=0x7ffff2f83700) at
> pthread_create.c:312
> #10 0x00007ffff5b9947d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> {code}
> We were able to reproduce the issue with this simple Go program:
> {code:java}
> package main
> import (
> "fmt"
> "html"
> "log"
> "net/http"
> )
> func main() {
> http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
> w.Header().Set("Content-Type", "text/html; charset=UTF-8")
> w.Header().Set("Cache-Control", "public, max-age=0,
> must-revalidate")
> fmt.Fprintf(w, "Hello, %q", html.EscapeString(r.URL.Path))
> })
> log.Fatal(http.ListenAndServe(":9393", nil))
> }
> {code}
> We redirect ATS to this program with a very simple remap rule:
> {code}
> regex_map http://.* http://10.1.10.17:9393
> {code}
> Using `git bisect` we found that the issue was introduced in this commit,
> although we don't really understand why:
> https://github.com/apache/trafficserver/commit/af76977adb9f3c0296a232688bbcb5a1421a6768
> I have a patch ready that seems to fix the problem and that I'll push as a
> pull request to GitHub asap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
