Seems like the unittests for core.sync.semaphore fails on OS X for me. What could be happening?


Testing obj/core/sync/semaphore
core.exception.AssertError at core.sync.semaphore(516): Assertion failure
----------------
5   semaphore                           0x0000969d onAssertError + 65
6   semaphore                           0x00012176 _d_assertm + 30
7   semaphore                           0x00001ff0 void core.sync.semaphore.__assert(int) + 24
8   semaphore                           0x000027bd void core.sync.semaphore.testWaitTimeout() + 297
9   semaphore                           0x00002838 void core.sync.semaphore.__unittest1() + 16
10  semaphore                           0x00001fd3 void core.sync.semaphore.__modtest() + 11
11  semaphore                           0x00009b19 extern (C) bool core.runtime.runModuleUnitTests().int __foreachbody247(ref object.ModuleInfo*) + 45
12  semaphore                           0x00005267 int object.ModuleInfo.opApply(scope int delegate(ref object.ModuleInfo*)) + 79
13  semaphore                           0x00009a0a runModuleUnitTests + 134
14  semaphore                           0x000124f6 extern (C) int rt.dmain2.main(int, char**).void runAll() + 38
15  semaphore                           0x0001244a extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
16  semaphore                           0x000123db main + 179
17  semaphore                           0x00001fb5 start + 53


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

The testWaitTimeout unittest is a bit of a hack in that it requires a signal to be sent from the main thread to a spawned thread within 100 milliseconds of an event occurring.  I chose this number based on experimentation, as I wanted it short enough not to hang up the unittest run for too long, but long enough that the test worked.  It appears that I left a bit too thin of a margin for your system.  I've increased the number to 200 milliseconds.  Hopefully that will be enough.  I'll check in the fix with the changes for issue 5488.

On Jan 30, 2011, at 1:05 PM, Michel Fortin wrote:

> Seems like the unittests for core.sync.semaphore fails on OS X for me. What could be happening?
> 
> 
> Testing obj/core/sync/semaphore
> core.exception.AssertError at core.sync.semaphore(516): Assertion failure
> ----------------
> 5   semaphore                           0x0000969d onAssertError + 65
> 6   semaphore                           0x00012176 _d_assertm + 30
> 7   semaphore                           0x00001ff0 void core.sync.semaphore.__assert(int) + 24
> 8   semaphore                           0x000027bd void core.sync.semaphore.testWaitTimeout() + 297
> 9   semaphore                           0x00002838 void core.sync.semaphore.__unittest1() + 16
> 10  semaphore                           0x00001fd3 void core.sync.semaphore.__modtest() + 11
> 11  semaphore                           0x00009b19 extern (C) bool core.runtime.runModuleUnitTests().int __foreachbody247(ref object.ModuleInfo*) + 45
> 12  semaphore                           0x00005267 int object.ModuleInfo.opApply(scope int delegate(ref object.ModuleInfo*)) + 79
> 13  semaphore                           0x00009a0a runModuleUnitTests + 134
> 14  semaphore                           0x000124f6 extern (C) int rt.dmain2.main(int, char**).void runAll() + 38
> 15  semaphore                           0x0001244a extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
> 16  semaphore                           0x000123db main + 179
> 17  semaphore                           0x00001fb5 start + 53
> 
> 
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
> 
> 
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Le 2011-01-31 ? 15:13, Sean Kelly a ?crit :

> The testWaitTimeout unittest is a bit of a hack in that it requires a signal to be sent from the main thread to a spawned thread within 100 milliseconds of an event occurring.  I chose this number based on experimentation, as I wanted it short enough not to hang up the unittest run for too long, but long enough that the test worked.  It appears that I left a bit too thin of a margin for your system.  I've increased the number to 200 milliseconds.  Hopefully that will be enough.  I'll check in the fix with the changes for issue 5488.

Changing both timeout values to 200 ms makes the test succeed. Thanks.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/