Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#638 closed defect (fixed)

isc::cache::RRsetEntry assertion

Reported by: jreed Owned by: zhanglikun
Priority: medium Milestone: R-Team-Sprint-20110308
Component: resolver Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: 3.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

[b10-resolver] Got a DNS message
[b10-resolver] received a message:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12121
;; flags: rd ; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;k1.isc.org. IN AAAA

[b10-resolver] Processing normal query
[b10-resolver] Try out cache first (started by incoming event)
b10-resolver: /usr/include/boost/shared_ptr.hpp:375: T* boost::shared_ptr<T>::op
erator->() const [with T = isc::cache::RRsetEntry]: Assertion `px != 0' failed.
[bind10] Process b10-resolver (PID 350) terminated, exit status = 6
[bind10] Resurrecting dead b10-resolver process...

Subtickets

Change History (9)

comment:1 Changed 9 years ago by jreed

Another example on different server:

;; QUESTION SECTION:
;disqus.com. IN AAAA

[b10-resolver] Processing normal query
[b10-resolver] Try out cache first (started by incoming event)
assertion "px != 0" failed: file "/usr/pkg/include/boost/smart_ptr/shared_ptr.hpp", line 418, function "T* boost::shared_ptr< <template-parameter-1-1> >::operator->() const [with T = isc::cache::RRsetEntry]"
[bind10] Process b10-resolver (PID 5992) terminated, exit status = 134

I have six of these assertions on this other system, various labels but all AAAA. Also queries for same label for AAAA also don't fail.

comment:2 Changed 9 years ago by zhanglikun

  • Owner set to jreed
  • Status changed from new to reviewing

Hi jeremy, could you provide some more information about it, I can't reproduce it, since it happended before, but seems jelte has fixed it(are you using the latest code? ).

comment:3 Changed 9 years ago by jreed

#0  0x00007f7ff9ce54aa in _lwp_kill () from /usr/lib/libc.so.12
#1  0x00007f7ff9ce4e1e in abort () from /usr/lib/libc.so.12
#2  0x00007f7ff9c5f2d4 in __assert13 () from /usr/lib/libc.so.12
#3  0x00007f7ffb412be2 in isc::cache::MessageEntry::getRRsetEntries (
    this=0x7f7ff93ca780, rrset_entry_vec=@0x7f7fffffca60, time_now=1299185515)
    at /usr/pkg/include/boost/smart_ptr/shared_ptr.hpp:418
#4  0x00007f7ffb412d50 in isc::cache::MessageEntry::genMessage (this=0x1, 
    time_now=<value optimized out>, msg=@0x7f7ff92f92e0) at message_entry.cc:95
#5  0x00007f7ffb411c6b in isc::cache::MessageCache::lookup (
    this=0x7f7ffdb3d0c0, qname=<value optimized out>, 
    qtype=<value optimized out>, response=@0x7f7ff92f92e0)
    at message_cache.cc:50
#6  0x00007f7ffb40f806 in isc::cache::ResolverClassCache::lookup (
    this=0x7f7ffdb2c140, qname=@0x7f7ff910e100, qtype=@0x7f7ff910e128, 
    response=@0x7f7ff92f92e0) at resolver_cache.cc:78
#7  0x00007f7ffb40fab5 in isc::cache::ResolverCache::lookup (
    this=<value optimized out>, qname=@0x7f7ff910e100, qtype=@0x7f7ff910e128, 
    qclass=<value optimized out>, response=@0x7f7ff92f92e0)
    at resolver_cache.cc:158
#8  0x00007f7ffc841705 in asiolink::RecursiveQuery::resolve (
    this=0x7f7ffdb07340, question=@0x7f7ff910e100, 
    answer_message=@0x7f7fffffcf00, buffer=@0x7f7fffffcef0, 
    server=<value optimized out>) at recursive_query.cc:526
#9  0x000000000040952d in ResolverImpl::processNormalQuery (
    this=0x7f7ffdb0b0f0, question=@0x7f7ff910e100, 
    answer_message=@0x7f7fffffd0e0, buffer=@0x7f7fffffcfe0, 
    server=0x7f7fffffd3e8) at resolver.cc:453
#10 0x000000000040adbd in Resolver::processMessage (this=0x7f7ffdb056e0, 
    io_message=<value optimized out>, query_message=@0x7f7fffffd2d0, 
    answer_message=@0x7f7fffffd2c0, buffer=@0x7f7fffffd2b0, 
    server=0x7f7fffffd3e8) at resolver.cc:430
#11 0x0000000000411ffb in MessageLookup::operator() (
    this=<value optimized out>, io_message=@0x6, 
    query_message=<value optimized out>, answer_message=<value optimized out>, 
    buffer=<value optimized out>, server=0x7f7fffffc146) at resolver.cc:241
#12 0x00007f7ffc851b33 in asiolink::UDPServer::asyncLookup (
    this=0x7f7fffffd3d0) at udp_server.cc:288
#13 0x00007f7ffc854b71 in asio::asio_handler_invoke<asiolink::DNSServer::AsyncLookup<asiolink::UDPServer> > (function=@0x1)
    at ../../../src/lib/asiolink/dns_server.h:135
#14 0x00007f7ffc854bf7 in asio::detail::completion_handler<asiolink::DNSServer::AsyncLookup<asiolink::UDPServer> >::do_complete (owner=<value optimized out>, 
    base=<value optimized out>)
    at ../../../ext/asio/asio/detail/handler_invoke_helpers.hpp:41
#15 0x00007f7ffc8406c7 in asio::detail::task_io_service<asio::detail::select_reactor<false> >::do_one (this=0x7f7ffdb0b080, lock=@0x7f7fffffd990, 
    this_idle_thread=0x7f7fffffd9a0)
    at ../../../ext/asio/asio/detail/task_io_service_operation.hpp:35
#16 0x00007f7ffc83fc02 in asiolink::IOService::run (this=<value optimized out>)
    at ../../../ext/asio/asio/detail/task_io_service.hpp:115
#17 0x0000000000414099 in main (argc=<value optimized out>, 
    argv=<value optimized out>) at main.cc:168

comment:4 Changed 9 years ago by zhanglikun

  • Owner changed from jreed to jelte

Please see the commit in trac638, fa83bb99518bd8c4dede832769fe4f7a6405ea62. I think it will fix this problem.

BTW, I find another problem which may use up the memory, since the rrset entry isn't be touched/removed properly, once it expires, it will never be deleted. (also the touch/remove operation for nsas entry and message entry should be revisited properly.), I have created a new ticket(#661) for it.

comment:5 Changed 9 years ago by jelte

  • Owner changed from jelte to zhanglikun

Ack. looks good, please merge. One question though; is it expected that that value can be null?

comment:6 Changed 9 years ago by zhanglikun

  • Resolution set to fixed
  • Status changed from reviewing to closed

yes, currently it will be empty once the rrset entry doesn't exist or has expired, but I just feel a little uncomfortable about the behavior, it will be revisited together with 661.

comment:7 Changed 9 years ago by zhanglikun

close this ticket, the fix has been committed in git 54e61304131965c4a1d88c9151f8697dcbb3ce12

comment:8 Changed 9 years ago by stephen

  • Milestone changed from R-Team-Task-Backlog to R-Team-Sprint-20110308

comment:9 Changed 9 years ago by zhanglikun

  • Estimated Difficulty changed from 0.0 to 3.0

give a estimated time

Note: See TracTickets for help on using tickets.