17-Jan-2015 06:09:57.614 general: critical: rpz.c:463: REQUIRE(*cnt > 0) failed, back trace 17-Jan-2015 06:09:57.614 general: critical: #0 0x43346d in ?? 17-Jan-2015 06:09:57.614 general: critical: #1 0x7fd7fc58627a in ?? 17-Jan-2015 06:09:57.614 general: critical: #2 0x7fd7fcf2e8b7 in ?? 17-Jan-2015 06:09:57.614 general: critical: #3 0x7fd7fcf2eca6 in ?? 17-Jan-2015 06:09:57.614 general: critical: #4 0x7fd7fcf31985 in ?? 17-Jan-2015 06:09:57.614 general: critical: #5 0x7fd7fceb09de in ?? 17-Jan-2015 06:09:57.614 general: critical: #6 0x7fd7fcebaeb7 in ?? 17-Jan-2015 06:09:57.614 general: critical: #7 0x7fd7fcebf150 in ?? 17-Jan-2015 06:09:57.614 general: critical: #8 0x7fd7fc5a9b13 in ?? 17-Jan-2015 06:09:57.614 general: critical: #9 0x7fd7fc1581da in ?? 17-Jan-2015 06:09:57.614 general: critical: #10 0x7fd7fbe95d7d in ?? 17-Jan-2015 06:09:57.614 general: critical: exiting (due to assertion failure) Reproducible: Always Steps to Reproduce: 1.emerge net-dns/bind with rpz 2.configure rpz 3.reload named 4.wait Actual Results: at first its nosign of errors, but when updates in rpz zone files are comming the above bug can be tricked Expected Results: that args is not just ignored when 0 bug happends here on amd64 with 9.10 version of bind, seems stable on x86 9.10 version of bind, so possible just a 64bit issue ?
Created attachment 394436 [details] emerge --info dont know if more is needed if some could guide me in how to use the core file to backtrace it more, i could do this, currently i just have downgraded to bind 9.9 for now
(In reply to Benny Pedersen from comment #0) > 17-Jan-2015 06:09:57.614 general: critical: rpz.c:463: REQUIRE(*cnt > 0) > failed, back trace > 17-Jan-2015 06:09:57.614 general: critical: #0 0x43346d in ?? > 17-Jan-2015 06:09:57.614 general: critical: #1 0x7fd7fc58627a in ?? > 17-Jan-2015 06:09:57.614 general: critical: #2 0x7fd7fcf2e8b7 in ?? > 17-Jan-2015 06:09:57.614 general: critical: #3 0x7fd7fcf2eca6 in ?? > 17-Jan-2015 06:09:57.614 general: critical: #4 0x7fd7fcf31985 in ?? > 17-Jan-2015 06:09:57.614 general: critical: #5 0x7fd7fceb09de in ?? > 17-Jan-2015 06:09:57.614 general: critical: #6 0x7fd7fcebaeb7 in ?? > 17-Jan-2015 06:09:57.614 general: critical: #7 0x7fd7fcebf150 in ?? > 17-Jan-2015 06:09:57.614 general: critical: #8 0x7fd7fc5a9b13 in ?? > 17-Jan-2015 06:09:57.614 general: critical: #9 0x7fd7fc1581da in ?? > 17-Jan-2015 06:09:57.614 general: critical: #10 0x7fd7fbe95d7d in ?? > 17-Jan-2015 06:09:57.614 general: critical: exiting (due to assertion > failure) Rebuild net-dns/bind with debug symbols and you can fill in those blanks in the backtrace.
its now long time since it happende last time, so solved now ? i will if it happens again make a debug emerge and send reports trace, is it safe to have debug always ?
(In reply to Benny Pedersen from comment #3) > its now long time since it happende last time, so solved now ? > > i will if it happens again make a debug emerge and send reports trace, is it > safe to have debug always ? Thanks! You should disable debug flags/options as long as you don't need it, esp. in production environments.
