[
https://issues.apache.org/jira/browse/TS-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158304#comment-15158304
]
Brian Geffon edited comment on TS-4207 at 2/23/16 5:31 AM:
-----------------------------------------------------------
[~msekimura] that's a good catch, but it's unlikely it's the source of the
problem as there are always 3 levels this is hard coded as
MULTI_CACHE_MAX_LEVELS.
[~zwoop], can you give this patch a try? I suppose if for whatever reason you
had a MultiCache with less than MULTI_CACHE_MAX_LEVELS that this hard coded 3
could cause it to touch memory it shouldn't be, but it's unlikely it would
delete the wrong block as anything beyond that point wouldn't be part of the
multicache structure.
was (Author: briang):
[~msekimura] that's a good catch, but it's unlikely it's the source of the
problem as there are always 3 levels this is hard coded as
MULTI_CACHE_MAX_LEVELS.
> 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)
