unbound-1.19.0 alloc_reg_obtain() core dumps

Yorgos Thessalonikefs yorgos at nlnetlabs.nl
Fri Feb 2 09:05:11 UTC 2024


Hi Sami,

I'll have a look but probably next week.
I am a little confused by your previous wording:
"... have a problem with unbound-1.19.0.  Estimated time in between 
crashes is around 450 days on a single server."
Did these start specifically with 1.19.0?
How often do you see those crashes (per single server)?

Best regards,
-- Yorgos

On 01/02/2024 16:03, Sami Kerola via Unbound-users wrote:
> On Wed, 31 Jan 2024 at 13:59, Sami Kerola <kerolasa at iki.fi> wrote:
>> I am working for Cloudflare where we seem to have a problem with
>> unbound-1.19.0.
> 
> Good day,
> 
> Slightly different looking core today.
> 
> (gdb) bt -full
> #0  process_dnskey_response (origin=0x563b8cf29aa0,
> qinfo=0x563b8cf25c50, msg=<optimized out>, rcode=<optimized out>,
> id=<optimized out>, vq=0x563b8cb0fb48, qstate=0x563b8cf71d80) at
> validator/validator.c:2861
>          old = 0x563b8cb0fd20
>          dnskey = <optimized out>
>          reason = 0x0
>          ve = 0x563b8c6f9c00
>          downprot = <optimized out>
>          reason_bogus = LDNS_EDE_DNSSEC_BOGUS
>          ve = <optimized out>
>          old = <optimized out>
>          dnskey = <optimized out>
>          downprot = <optimized out>
>          reason = <optimized out>
>          reason_bogus = <optimized out>
> #1  val_inform_super (qstate=0x563b8cf25c50, id=<optimized out>,
> super=0x563b8cf71d80) at validator/validator.c:2973
>          vq = 0x563b8cb0fb48
> # and so on
> 
> (gdb) print *(struct query_info*)0x563b8cf25c50
> $4 = {qname = 0x563b8cf25e70 "\003net", qname_len = 5, qtype = 48,
> qclass = 1, local_alias = 0x0}
> 
> (gdb) print *(struct val_qstate*)0x563b8cb0fb48
> $1 = {state = VAL_FINDKEY_STATE, orig_msg = 0x563b8cc851c0,
> restart_count = 0, chain_blacklist = 0x0, qchase = {qname =
> 0x563b8cf71fa0 "\001a\froot-servers\003net", qname_len = 20, qtype =
> 28, qclass = 1, local_alias = 0x0}, chase_reply = 0x563b8cb0fbf0,
> rrset_skip = 0, trust_anchor_name = 0x0, trust_anchor_labs = 0,
> trust_anchor_len = 0, ds_rrset = 0x563b8cb107c0,
>    empty_DS_name = 0x0, empty_DS_len = 0, key_entry = 0x563b8cf71d30,
> subtype = VAL_CLASS_UNTYPED, signer_name = 0x0, signer_len = 0,
> wait_prime_ta = 0}
> 
> (gdb) print *(struct key_entry_key*)0x563b8cf71d30
> $3 = {entry = {lock = {__data = {__readers = 0, __writers = 0,
> __wrphase_futex = 0, __writers_futex = 0, __pad3 = 0, __pad4 = 0,
> __cur_writer = 0, __shared = 0, __rwelision = 0 '\000', __pad1 =
> "\000\000\000\000\000\000", __pad2 = 0, __flags = 0}, __size = '\000'
> <repeats 55 times>, __align = 0}, overflow_next = 0x0, lru_next = 0x0,
> lru_prev = 0x0, hash = 0,
>      key = 0x563b8cf71d30, data = 0x563b8cf71db8}, name =
> 0x563b8cf71db0 "\003net", namelen = 5, key_class = 1}
> 
> (gdb) print *(struct val_env*)0x563b8c6f9c00
> $2 = {kcache = 0x563b8c6f9cb0, neg_cache = 0x563b8c90f350,
> date_override = 0, skew_min = 3600, skew_max = 86400, max_restart = 5,
> bogus_ttl = 60, nsec3_keyiter_count = 3, nsec3_keysize =
> 0x563b8c90f310, nsec3_maxiter = 0x563b8c90f330, bogus_lock = {__data =
> {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0,
> __spins = 0, __elision = 0, __list = {__prev = 0x0,
>          __next = 0x0}}, __size = '\000' <repeats 39 times>, __align =
> 0}, num_rrset_bogus = 0}
> 
> I hope that helps figuring out what is going on.
> 


More information about the Unbound-users mailing list