False failure in capsforid fallback due to additional rrset ordering

[Jacob Hoffman-Andrews]

On 2/4/19 7:24 AM, Wouter Wijngaards via Unbound-users wrote:
>> That's not a problem in itself, but I believe Unbound may be occasionally triggering a false positive failure during capsforid fallback.
> 
> Thanks for the detailed report.  Yes, you are right, it should get
> sorted.  I have made a fix, also in the code repository that sorts the
> rrsets before comparison.

Thanks very much for writing this patch. I've been doing some local 
testing and have found a segfault. To produce the segfault, I used 
https://github.com/letsencrypt/dns-lots-of-lookups, which simply does a 
lot of lookups for a long list of names. I suspect any long list of name 
would do but I can provide an example if it would be helpful.

Stack trace is attached. Binary with debug symbold and core file are at:

https://jacob.hoffman-andrews.com/rrsort-crash/core
https://jacob.hoffman-andrews.com/rrsort-crash/unbound

I've confirmed that reverting this patch fixes the crash.

Thanks,
Jacob
-------------- next part --------------
Core was generated by `./unbound -d -c /home/jsha/gopkg/src/github.com/jsha/unboundtest/unbound.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  dname_count_labels (dname=0x3a6657688 <error: Cannot access memory at address 0x3a6657688>) at util/data/dname.c:394
394             lablen = *dname++;
[Current thread is 1 (Thread 0x7fcdc698b740 (LWP 23115))]
(gdb) bt
#0  dname_count_labels (dname=0x3a6657688 <error: Cannot access memory at address 0x3a6657688>) at util/data/dname.c:394
#1  0x0000558673feba13 in dname_canonical_compare (d1=0x55868e4919a0 "", d2=0x3a6657687 <error: Cannot access memory at address 0x3a6657687>) at util/data/dname.c:798
#2  0x0000558674009e8c in rrset_canonical_sort_cmp (x=0x55868e4918b0, y=0x55868e4918b8) at iterator/iter_utils.c:893
#3  0x00007fcdc6fa56b2 in msort_with_tmp (p=p at entry=0x7fff1c910c40, b=b at entry=0x55868e4918b0, n=n at entry=2) at msort.c:83
#4  0x00007fcdc6fa5402 in msort_with_tmp (n=2, b=0x55868e4918b0, p=0x7fff1c910c40) at msort.c:53
#5  msort_with_tmp (p=p at entry=0x7fff1c910c40, b=b at entry=0x55868e4918b0, n=n at entry=4) at msort.c:53
#6  0x00007fcdc6fa5832 in msort_with_tmp (n=4, b=0x55868e4918b0, p=0x7fff1c910c40) at msort.c:297
#7  __GI___qsort_r (b=0x55868e4918b0, n=4, s=8, cmp=0x558674009e50 <rrset_canonical_sort_cmp>, arg=0x0) at msort.c:297
#8  0x000055867400a078 in reply_equal (p=0x55868e512568, q=0x55868e658278, region=0x55868e491400) at iterator/iter_utils.c:935
#9  0x0000558673fffc40 in process_response (qstate=0x55868e654770, iq=0x55868e6549b8, ie=0x5586749964b0, id=1, outbound=0x55868e512508, event=module_event_reply) at iterator/iterator.c:3735
#10 0x0000558673ffff1b in iter_operate (qstate=0x55868e654770, event=module_event_reply, id=1, outbound=0x55868e512508) at iterator/iterator.c:3792
#11 0x0000558674016669 in mesh_run (mesh=0x55868e4a1420, mstate=0x55868e654720, ev=module_event_reply, e=0x55868e512508) at services/mesh.c:1496
#12 0x0000558674013a79 in mesh_report_reply (mesh=0x55868e4a1420, e=0x55868e512508, reply=0x55868c5f2458, what=0) at services/mesh.c:640
#13 0x0000558673fdd3f7 in worker_handle_service_reply (c=0x55868c5f2420, arg=0x55868e512508, error=0, reply_info=0x55868c5f2458) at daemon/worker.c:295
#14 0x000055867408e6db in serviced_callbacks (sq=0x55868e4d6370, error=0, c=0x55868c5f2420, rep=0x55868c5f2458) at services/outside_network.c:1782
#15 0x000055867408ed1e in serviced_tcp_callback (c=0x55868c5f2420, arg=0x55868e4d6370, error=0, rep=0x55868c5f2458) at services/outside_network.c:1873
#16 0x000055867408a7bb in outnet_tcp_cb (c=0x55868c5f2420, arg=0x55868c5f23f0, error=0, reply_info=0x55868c5f2458) at services/outside_network.c:489
#17 0x00005586740808d6 in tcp_callback_reader (c=0x55868c5f2420) at util/netevent.c:1015
#18 0x0000558674081c7a in comm_point_tcp_handle_read (fd=183, c=0x55868c5f2420, short_ok=0) at util/netevent.c:1461
#19 0x00005586740821bf in comm_point_tcp_handle_callback (fd=183, event=2, arg=0x55868c5f2420) at util/netevent.c:1743
#20 0x00007fcdc6ca08f8 in ?? () from /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6
#21 0x00007fcdc6ca133f in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6
#22 0x0000558674090aa7 in ub_event_base_dispatch (base=0x558674996c10) at util/ub_event.c:280
#23 0x000055867407f036 in comm_base_dispatch (b=0x558674996b60) at util/netevent.c:246
#24 0x0000558673fe27e0 in worker_work (worker=0x558674989fd0) at daemon/worker.c:1893
#25 0x0000558673fce73e in daemon_fork (daemon=0x558674851260) at daemon/daemon.c:666
#26 0x0000558673fdc6b5 in run_daemon (cfgfile=0x7fff1c912d0b "/home/jsha/gopkg/src/github.com/jsha/unboundtest/unbound.conf", cmdline_verbose=0, debug_mode=1, 
    log_default_identity=0x7fff1c912cfd "unbound", need_pidfile=1) at daemon/unbound.c:670
#27 0x0000558673fdc8f6 in main (argc=0, argv=0x7fff1c9113f8) at daemon/unbound.c:767