[bind10-dev] failed unittests master 717d619224d93b6dc6da0cf6267deffc31e130ad

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Wed Jan 30 04:35:09 UTC 2013


At Wed, 30 Jan 2013 13:13:37 +0900 (JST),
Naoki Kambe <kambe at jprs.co.jp> wrote:

> Thank you for adding!
> 
> This time, there is no dead lock. It might be fixed.
> 
> http://git.bind10.isc.org/~tester/builder//BIND10/20130129173301-NetBSD4-i386-GCC/logs/unittests.out
> 
> BTW, we found another issue.
> 
> http://git.bind10.isc.org/~tester/builder//BIND10-cppcheck/20130129171501-FreeBSD8-amd64-GCC/logs/unittests.out
> 
> However this failure is related to #2225, independent from the dead lock failure.
> 
> So I've updated the 'fix_stats_tests' branch to include a fix for this failure.
> 
> Someone, please review the branch. Then I would merge it into master.

From a quick look, this is beyond the trivial level so I guess we need
a ticket to track the issue.  As it's urgent I think it's okay to push
it to the current sprint.

Some initial comments:

- I don't understand how the "deadlock" happened and how this lock
  solves that.  Please make more detailed explanations and/or
  comments.
- Same comments are repeated.  I think these should be unified:
+        # This locking is for dead-lock failures which often occurred
+        # while creating or deleting a socket file in msgq.py. See
+        # http://git.bind10.isc.org/~tester/builder//BIND10/20130129033301-NetBSD4-i386-GCC/logs/unittests.out.

- I don't understand why we need to call
  isc.log.resetUnitTestRootLogger() from multiple places.  Isn't it
  enough to call it from the test main?  If not, please explain.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.


More information about the bind10-dev mailing list