Hi, on and off I've been toying with the pkgsrc-wip v8 package, which is the Google JavaScript engine. They have a largih test suite, and "of course" a number of tests fail on NetBSD/i386 7.0_BETA which I'm currently developing on.
Lately I've been able to look a little closer into what causes the failures, and they fall into a few separate categories: * Calling sem_destroy() on a semaphore where threads are currently blocked on it, causing EBUSY. 13 tests. * An error possibly caused by a race(?), relating to a test directory. 1 test. * Some math corner cases which are expected to e.g. return Infinity but instead return -Infinity. 2 tests. * pthread_key_create() returning EAGAIN because too many keys have been created already in this process (trying to exceed PTHREAD_KEYS_MAX) 2 tests. * pthread_create() returning EAGAIN because too many threads are already running in this process (trying to exceed PTHRAEAD_THREADS_MAX). 13 tests. * Some tests end in "Fatal error in heap setup / Allocation failed - process out of memory". I've not been able to verify that this is indeed the case yet. 2 tests. * 2 tests which crash with exit code -11 (SEGV). I've also not dug into what these ones are about. * Some tests fail to print "en-US-u-va-posix-u-co-search" but instead print "en-US-u-va-posix". This is related to the ICU libs, I beleive. I've not been able to get to the bottom of this one yet. 2 tests. * One test times out; I've also not dug into that one. And ... looking at the summary, it looks like I've overlooked 3 more tests -- I have 39 failing and 2 crashed. A question pops up: are some of the pthread limits overly strict on NetBSD compared to e.g. Linux? Are they or could they be adjustable? Or is this just sloppy programming on the part of Google and its contributors which doesn't take heed of the values of e.g. PTHREAD_KEYS_MAX and PHTREAD_THREADS_MAX? Regards, - Håvard
