Thread overview
[phobos] freebsd64 and osx32 + druntime semaphore test == evil
Aug 04, 2011
Brad Roberts
Aug 04, 2011
David Nadlinger
Aug 04, 2011
Brad Roberts
Aug 04, 2011
Sean Kelly
Aug 05, 2011
Martin Nowak
August 03, 2011
I'm not sure why these two systems are so pissed off at the druntime semaphore test, but they both are, in different ways.

OSX has, essentially forever, periodically crashed during the test.

Recently, freebsd64 has started hanging in the test an awful lot, but not every time.  Eventually I notice it's been running way too long and kill it.

I'd be happy to give access to the freebsd64 box for anyone who's willing to dig in.  The osx box isn't mine to give access to, but I imagine sean wouldn't mind adding another account should a volunteer show up to dig in there too.

Anyone?

Thanks,
Brad
August 04, 2011
Just to let you know, I can easily reproduce this on my OS X 10.7 box by simply running testWaitTimeout() function in a loop:

core.exception.AssertError at core.sync.semaphore(530): Assertion failure
----------------
5   semaphore                           0x000ff46d onAssertError + 65
6   semaphore                           0x00108886 _d_assertm + 30
7   semaphore                           0x000f7cb0 void
core.sync.semaphore.__assert(int) + 24
8   semaphore                           0x000f84dd void
core.sync.semaphore.testWaitTimeout() + 317
9   semaphore                           0x000f85c1 void
core.sync.semaphore.__unittest1() + 17
10  semaphore                           0x000f7c93 void
core.sync.semaphore.__modtest() + 11
11  semaphore                           0x000ff8e1 extern (C) bool
core.runtime.runModuleUnitTests().int __foreachbody262(ref
object.ModuleInfo*) + 45
12  semaphore                           0x000fac93 int
object.ModuleInfo.opApply(scope int delegate(ref object.ModuleInfo*)) + 79
13  semaphore                           0x000ff7d2 runModuleUnitTests + 134
14  semaphore                           0x00108fda extern (C) int
rt.dmain2.main(int, char**).void runAll() + 38
15  semaphore                           0x00108b51 extern (C) int
rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 29
16  semaphore                           0x00108aeb main + 179
17  semaphore                           0x000f7c75 start + 53
18  ???                                 0x00000001 0x0 + 1

The assertion fails because alertedOne is not set, and about half of the times this happens, alertedTwo is set instead. The number of test iterations it takes for the first failure to happen varies from several tens to thousands on my machine.

David


On 8/4/11 2:41 AM, Brad Roberts wrote:
> I'm not sure why these two systems are so pissed off at the druntime semaphore test, but they both are, in different ways.
>
> OSX has, essentially forever, periodically crashed during the test.
>
> Recently, freebsd64 has started hanging in the test an awful lot, but not every time.  Eventually I notice it's been running way too long and kill it.
>
> I'd be happy to give access to the freebsd64 box for anyone who's willing to dig in.  The osx box isn't mine to give access to, but I imagine sean wouldn't mind adding another account should a volunteer show up to dig in there too.
>
> Anyone?
>
> Thanks,
> Brad
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

August 04, 2011
I wrote the semaphore test so I should really fix it anyway. The annoying thing is that it really should work.

Sent from my iPhone

On Aug 3, 2011, at 5:41 PM, Brad Roberts <braddr at puremagic.com> wrote:

> I'm not sure why these two systems are so pissed off at the druntime semaphore test, but they both are, in different ways.
> 
> OSX has, essentially forever, periodically crashed during the test.
> 
> Recently, freebsd64 has started hanging in the test an awful lot, but not every time.  Eventually I notice it's been running way too long and kill it.
> 
> I'd be happy to give access to the freebsd64 box for anyone who's willing to dig in.  The osx box isn't mine to give access to, but I imagine sean wouldn't mind adding another account should a volunteer show up to dig in there too.
> 
> Anyone?
> 
> Thanks,
> Brad
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
August 04, 2011
Independently reproducible is good.  It means it's not something specific to the auto-tester environment (not that I thought it was, but good to confirm).

On Thursday, August 04, 2011 4:27:06 AM, David Nadlinger wrote:
> Just to let you know, I can easily reproduce this on my OS X 10.7 box by simply running testWaitTimeout() function in a loop:
> 
> core.exception.AssertError at core.sync.semaphore(530): Assertion failure
> ----------------
> 5   semaphore                           0x000ff46d onAssertError + 65
> 6   semaphore                           0x00108886 _d_assertm + 30
> 7   semaphore                           0x000f7cb0 void core.sync.semaphore.__assert(int) + 24
> 8   semaphore                           0x000f84dd void core.sync.semaphore.testWaitTimeout() + 317
> 9   semaphore                           0x000f85c1 void core.sync.semaphore.__unittest1() + 17
> 10  semaphore                           0x000f7c93 void core.sync.semaphore.__modtest() + 11
> 11  semap
hore                           0x000ff8e1 extern (C) bool core.runtime.runModuleUnitTests().int
> __foreachbody262(ref object.ModuleInfo*) + 45
> 12  semaphore                           0x000fac93 int object.ModuleInfo.opApply(scope int delegate(ref
> object.ModuleInfo*)) + 79
> 13  semaphore                           0x000ff7d2 runModuleUnitTests + 134
> 14  semaphore                           0x00108fda extern (C) int rt.dmain2.main(int, char**).void runAll() + 38
> 15  semaphore                           0x00108b51 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
> delegate()) + 29
> 16  semaphore                           0x00108aeb main + 179
> 17  semaphore                           0x000f7c75 start + 53
> 18  ???                                 0x00000001 0x0 + 1
> 
> The assertion fails because alertedOne is not set, and about half of the times this happens, alertedTwo is set instead. The number of test iterations it takes for the first failure to
happen varies from several tens to thousands on my machine.
> 
> David
> 
> 
> On 8/4/11 2:41 AM, Brad Roberts wrote:
>> I'm not sure why these two systems are so pissed off at the druntime semaphore test, but they both are, in different ways.
>>
>> OSX has, essentially forever, periodically crashed during the test.
>>
>> Recently, freebsd64 has started hanging in the test an awful lot, but not every time.  Eventually I notice it's been running way too long and kill it.
>>
>> I'd be happy to give access to the freebsd64 box for anyone who's willing to dig in.  The osx box isn't mine to give access to, but I imagine sean wouldn't mind adding another account should a volunteer show up to dig in there too.
>>
>> Anyone?
>>
>> Thanks,
>> Brad

August 06, 2011
I can't reproduce the hangs on FreeBSD64 but found a wrong sleep time in the rwmutex test. https://github.com/D-Programming-Language/druntime/pull/50

On Thu, 04 Aug 2011 18:00:38 +0200, Sean Kelly <sean at invisibleduck.org> wrote:

> I wrote the semaphore test so I should really fix it anyway. The annoying thing is that it really should work.
>
> Sent from my iPhone
>
> On Aug 3, 2011, at 5:41 PM, Brad Roberts <braddr at puremagic.com> wrote:
>
>> I'm not sure why these two systems are so pissed off at the druntime semaphore test, but they both are, in different ways.
>>
>> OSX has, essentially forever, periodically crashed during the test.
>>
>> Recently, freebsd64 has started hanging in the test an awful lot, but
>> not
>> every time.  Eventually I notice it's been running way too long and kill
>> it.
>>
>> I'd be happy to give access to the freebsd64 box for anyone who's
>> willing
>> to dig in.  The osx box isn't mine to give access to, but I imagine sean
>> wouldn't mind adding another account should a volunteer show up to dig
>> in
>> there too.
>>
>> Anyone?
>>
>> Thanks,
>> Brad
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos