IPv6 Crash

I've recently installed unbound onto 3 FreeBSD 8.0 AMD64 servers. All
are running the exact same unbound version and config, except 1 server
that is doing IPv6. Unbound crashes about every 24 hours on the server
that is running IPv6. If i remove the IPv6 address and set do ipv6 to
no, then it runs without any issues. As soon as i set it back to IPv6,
the crashes start. I'm running the latest version of unbound from the
ports system, 1.4.1. The config is very basic, using some of the tweaks
suggested from the unbound website for high-volume servers. Any
suggestions on what i can do to debug this?

Hello Fellow Unbound users,

I've had problems with version 1.4.1 on ipv6 too. After some (within an
hour) time, 2 of the 3 configured threads are eating up 100% cpu, and
the gathering of statistics through the command channel are failing
(i.e. I can connect to the port, but nothing happens).

Our config:
server:
        interface: <v4 management ip>
        interface: <v6 management ip>
        interface: <v4 public anycast ip>
        interface: <v6 public anycast ip>

        access-control: <prefix> allow
  [more access-controls]

        verbosity: 1
        statistics-interval: 30
        statistics-cumulative: yes
        extended-statistics: yes
        num-threads: 3
        outgoing-interface: <v4 management ip>
        outgoing-interface: <v6 management ip>
        outgoing-range: 16384
        num-queries-per-thread: 16384
        rrset-cache-size: 3G
        do-daemonize: no
        chroot: ""

remote-control:
        control-enable: yes
        control-interface: 127.0.0.1
        control-port: 953
        server-key-file: "/etc/unbound/unbound_server.key"
        server-cert-file: "/etc/unbound/unbound_server.pem"
        control-key-file: "/etc/unbound/unbound_control.key"
        control-cert-file: "/etc/unbound/unbound_control.pem"

I'm in need of some suggestions too on how to debug this problem.

Kind regards,

Kai

Chris Gotstein wrote:

You probably need svn commit r1953

   - Fix for parent-child disagreement code which could have trouble
     when (a) ipv6 was disabled and (b) the TTL for parent and child
     were different. There were two bugs, the parent-side information
     is fixed to no longer block lookup of child side information and
     the iterator is fixed to no longer attempt to get ipv6 when it is
     not enabled and then give up in failure.

Paul

But doesn't that deal more with when you aren't running IPv6 on the server? Or am i reading it wrong? I think we both have IPv6 enabled and we are crashing.