[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158299#comment-15158299
]
Masa Sekimura edited comment on TS-4207 at 2/23/16 6:27 PM:
------------------------------------------------------------
I've just noticed that inside of HostDBContinuation::insert, lookup_block is
using hardcoded value "3" for levels. It's unlikely to match that md5 value but
it's possible match a different block due to the hardcoded value? If so,
hostDB.delete_block(old_r) can be deleting a different block.
{code}
diff --git a/iocore/hostdb/HostDB.cc b/iocore/hostdb/HostDB.cc
index eb5b541..0101848 100644
--- a/iocore/hostdb/HostDB.cc
+++ b/iocore/hostdb/HostDB.cc
@@ -743,7 +743,7 @@ HostDBContinuation::insert(unsigned int attl)
ink_assert(this_ethread() == hostDB.lock_for_bucket(bucket)->thread_holding);
// remove the old one to prevent buildup
- HostDBInfo *old_r = hostDB.lookup_block(folded_md5, 3);
+ HostDBInfo *old_r = hostDB.lookup_block(folded_md5, hostDB.levels);
if (old_r)
hostDB.delete_block(old_r);
HostDBInfo *r = hostDB.insert_block(folded_md5, NULL, 0);
{code}
was (Author: msekimura):
I've just noticed that inside of HostDBContinuation::insert, lookup_block is
using hardcoded value "3" for levels. It's unlikely to match that md5 value but
it's possible match a different block due to the hardcoded value? If so,
hostDB.delete_block(old_r) can be deleting a different block.
{code}
diff --git a/iocore/hostdb/HostDB.cc b/iocore/hostdb/HostDB.cc
index eb5b541..0101848 100644
--- a/iocore/hostdb/HostDB.cc
+++ b/iocore/hostdb/HostDB.cc
@@ -743,7 +743,7 @@ HostDBContinuation::insert(unsigned int attl)
ink_assert(this_ethread() == hostDB.lock_for_bucket(bucket)->thread_holding);
// remove the old one to prevent buildup
- HostDBInfo *old_r = hostDB.lookup_block(folded_md5, 3);
+ HostDBInfo *old_r = hostDB.lookup_block(folded_md5, hostdb.levels);
if (old_r)
hostDB.delete_block(old_r);
HostDBInfo *r = hostDB.insert_block(folded_md5, NULL, 0);
{code}
> Crash in HostDB, likely a regression from 5.x
> ---------------------------------------------
>
> Key: TS-4207
> URL: https://issues.apache.org/jira/browse/TS-4207
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
> Reporter: Leif Hedstrom
> Priority: Blocker
> Labels: crash
> Fix For: 6.2.0
>
>
> We're seeing a new crash in HostDB, which did not occur in 5.3.x:
> {code}
> (gdb) bt
> #0 0x00002aaaaac7b2bb in HttpSM::process_hostdb_info(HostDBInfo*) () at
> ../../iocore/hostdb/P_HostDBProcessor.h:295
> #1 0x00002aaaaac88b16 in HttpSM::state_hostdb_lookup(int, void*) () at
> HttpSM.cc:2126
> #2 0x00002aaaaac9713d in HttpSM::main_handler(int, void*) () at
> HttpSM.cc:2561
> #3 0x00002aaaaad7803e in reply_to_cont(Continuation*, HostDBInfo*, bool) ()
> at ../../iocore/eventsystem/I_Continuation.h:153
> #4 0x00002aaaaad7eca5 in HostDBContinuation::dnsEvent(int, HostEnt*) () at
> HostDB.cc:1685
> #5 0x00002aaaaad98faf in DNSEntry::postEvent(int, Event*) () at
> ../../iocore/eventsystem/I_Continuation.h:153
> #6 0x00002aaaaae7e420 in EThread::process_event(Event*, int) () at
> I_Continuation.h:153
> #7 0x00002aaaaae7f2ab in EThread::execute() () at UnixEThread.cc:179
> #8 0x00002aaaaae7de06 in spawn_thread_internal(void*) () at Thread.cc:86
> #9 0x00002aaaad6ac9d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x00002aaaae8b58fd in clone () from /lib64/libc.so.6
> {code}
> I think some inlining here complicates things, what it looks like the "r" is
> NULL, but it somehow still ends up using r->rr ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
