www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - druntime unit test failures on FreeBSD

reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
I am consistently seeing this when I try and run druntime's unit tests on
FreeBSD for either 2.067 or master:

0.000s PASS release64 object
0.000s PASS release64 core.atomic
0.008s PASS release64 core.bitop
0.000s PASS release64 core.checkedint
0.000s PASS release64 core.demangle
0.000s PASS release64 core.exception
0.000s PASS release64 core.math
0.000s PASS release64 core.memory
posix.mak:230: recipe for target 'obj/64/core/thread' failed
gmake: *** [obj/64/core/thread] Illegal instruction
gmake: *** Deleting file 'obj/64/core/thread'

2.066 works fine, so I assume that something was introduced since then, but
clearly the autotesters are working for FreeBSD, so I have to wonder whether
I have an environmental problem with my machine or whether I've just done
something differently from the autotesters and am hitting a problem in
either the compiler or in druntime that's a general problem that the
autotester doesn't hit for whatever reason.

I'm running the latest 64-bit PC-BSD. I have no idea what the autotesters
are running.

Is anyone else seeing anything like this?

- Jonathan M Davis
Apr 19 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 19 April 2015 at 07:36:13 UTC, Jonathan M Davis wrote:

 I am consistently seeing this when I try and run druntime's 
 unit tests on
 FreeBSD for either 2.067 or master:

 0.000s PASS release64 object
 0.000s PASS release64 core.atomic
 0.008s PASS release64 core.bitop
 0.000s PASS release64 core.checkedint
 0.000s PASS release64 core.demangle
 0.000s PASS release64 core.exception
 0.000s PASS release64 core.math
 0.000s PASS release64 core.memory
 posix.mak:230: recipe for target 'obj/64/core/thread' failed
 gmake: *** [obj/64/core/thread] Illegal instruction
 gmake: *** Deleting file 'obj/64/core/thread'

 2.066 works fine, so I assume that something was introduced 
 since then, but
 clearly the autotesters are working for FreeBSD, so I have to 
 wonder whether
 I have an environmental problem with my machine or whether I've 
 just done
 something differently from the autotesters and am hitting a 
 problem in
 either the compiler or in druntime that's a general problem 
 that the
 autotester doesn't hit for whatever reason.

 I'm running the latest 64-bit PC-BSD. I have no idea what the 
 autotesters
 are running.

 Is anyone else seeing anything like this?


I dusted off the old FreeBSD VM I had lying around and tried it 
out.  For me, it hangs in core.thread on FreeBSD 9.1 i386 from a 
couple years ago when I try to run the druntime unit tests with 
dmd/druntime HEAD.  At least most of the time, I just tried it 
again and it returned and passed once, out of ten times.
Apr 19 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, April 19, 2015 08:18:55 Joakim via Digitalmars-d wrote:

 I dusted off the old FreeBSD VM I had lying around and tried it
 out.  For me, it hangs in core.thread on FreeBSD 9.1 i386 from a
 couple years ago when I try to run the druntime unit tests with
 dmd/druntime HEAD.  At least most of the time, I just tried it
 again and it returned and passed once, out of ten times.


Lovely. That certainly begs the question as to what the autotester boxes are
doing differently then, since they're not seeing the problem. It wouldn't
surprise me in the least if they're runnig an older version of FreeBSD, but
you're clearly running one that's far from up-to-date. :|

LOL. Well, I just switched to FreeBSD from Linux so that I could take proper
advantage of ZFS, so I may be stuck looking random problems that pop up on
FreeBSD - though this is consistent enough that I'd expect to see it on the
autotester, so I'm quite confused.

- Jonathan M Davis
Apr 19 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 20 April 2015 at 03:21:10 UTC, Jonathan M Davis wrote:

 LOL. Well, I just switched to FreeBSD from Linux so that I 
 could take proper
 advantage of ZFS, so I may be stuck looking random problems 
 that pop up on
 FreeBSD - though this is consistent enough that I'd expect to 
 see it on the
 autotester, so I'm quite confused.


There was a random deadlock issue on FreeBSD a little while back, 
could be related to that:

https://issues.dlang.org/show_bug.cgi?id=13416
Apr 19 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, April 20, 2015 04:36:35 Joakim via Digitalmars-d wrote:

 On Monday, 20 April 2015 at 03:21:10 UTC, Jonathan M Davis wrote:

 LOL. Well, I just switched to FreeBSD from Linux so that I
 could take proper
 advantage of ZFS, so I may be stuck looking random problems
 that pop up on
 FreeBSD - though this is consistent enough that I'd expect to
 see it on the
 autotester, so I'm quite confused.


 There was a random deadlock issue on FreeBSD a little while back,
 could be related to that:

 https://issues.dlang.org/show_bug.cgi?id=13416


Hmmm. Maybe it's core-related. I have 6 cores with hyperthreading on my
machine - so, effectively 12 - which is more than the autotester has
according to that bug report, though if you're running yours in VM, I would
assume that it has fewer cores, and you're still seeing the problem.

- Jonathan M Davis
Apr 19 2015
parent "Joakim" <dlang joakim.fea.st> writes:
On Monday, 20 April 2015 at 05:00:44 UTC, Jonathan M Davis wrote:

 Hmmm. Maybe it's core-related. I have 6 cores with 
 hyperthreading on my
 machine - so, effectively 12 - which is more than the 
 autotester has
 according to that bug report, though if you're running yours in 
 VM, I would
 assume that it has fewer cores, and you're still seeing the 
 problem.


I have my VM setup to use two cores, which works out to two out 
of four virtual cores on my dual-core core i5 CPU.

Damn, that needs to be a tongue-twister. :)
Apr 20 2015
prev sibling next sibling parent reply "Dan Olson" <zans4cans yahoo.com> writes:
On Sunday, 19 April 2015 at 07:36:13 UTC, Jonathan M Davis wrote:

 I am consistently seeing this when I try and run druntime's 
 unit tests on
 FreeBSD for either 2.067 or master:

 0.000s PASS release64 object
 0.000s PASS release64 core.atomic
 0.008s PASS release64 core.bitop
 0.000s PASS release64 core.checkedint
 0.000s PASS release64 core.demangle
 0.000s PASS release64 core.exception
 0.000s PASS release64 core.math
 0.000s PASS release64 core.memory
 posix.mak:230: recipe for target 'obj/64/core/thread' failed
 gmake: *** [obj/64/core/thread] Illegal instruction
 gmake: *** Deleting file 'obj/64/core/thread'


  Do you know what thread.d unittest this happens in?  I am 
betting it is Fiber related.
Apr 20 2015
next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, April 20, 2015 20:44:48 Dan Olson via Digitalmars-d wrote:

 On Sunday, 19 April 2015 at 07:36:13 UTC, Jonathan M Davis wrote:

 I am consistently seeing this when I try and run druntime's
 unit tests on
 FreeBSD for either 2.067 or master:

 0.000s PASS release64 object
 0.000s PASS release64 core.atomic
 0.008s PASS release64 core.bitop
 0.000s PASS release64 core.checkedint
 0.000s PASS release64 core.demangle
 0.000s PASS release64 core.exception
 0.000s PASS release64 core.math
 0.000s PASS release64 core.memory
 posix.mak:230: recipe for target 'obj/64/core/thread' failed
 gmake: *** [obj/64/core/thread] Illegal instruction
 gmake: *** Deleting file 'obj/64/core/thread'


   Do you know what thread.d unittest this happens in?  I am
 betting it is Fiber related.


It looks like it's happening in the last unittest block in core.thread:

unittest
{
    auto thr = new Thread(function{}, 10).start();
    thr.join();
}

And if I remove the ", 10" from the constructor call, then the problem goes
away - though then I get this failure later

Testing link
Testing load
Testing linkD
Testing linkDR
Testing loadDR
Testing host
Testing finalize
Testing link_linkdep
Makefile:28: recipe for target 'obj/freebsd/64/link_linkdep.done' failed
gmake[1]: *** [obj/freebsd/64/link_linkdep.done] Segmentation fault
gmake[1]: Leaving directory
'/usr/home/jmdavis/Programming/github/druntime/test/shared'
posix.mak:242: recipe for target 'test/shared/.run' failed
gmake: *** [test/shared/.run] Error 2

No idea whether that's related or not. But regardless, that does narrow down
the problem some. Still, given how consistent it is on my box (I've _never_
seen it succeed on 2.067 or master), I really have to wonder what the
difference betwen my box and the autotesters are.

- Jonathan M Davis
Apr 20 2015
prev sibling parent Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4/20/2015 10:24 PM, Jonathan M Davis via Digitalmars-d wrote:

 No idea whether that's related or not. But regardless, that does narrow down
 the problem some. Still, given how consistent it is on my box (I've _never_
 seen it succeed on 2.067 or master), I really have to wonder what the
 difference betwen my box and the autotesters are.

 - Jonathan M Davis


The biggest difference is likely that the auto-testers are running 
freebsd 8.x (whatever's most recent (a relative term), either 3 or 4).
Apr 20 2015
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, April 20, 2015 22:33:00 Brad Roberts via Digitalmars-d wrote:

 On 4/20/2015 10:24 PM, Jonathan M Davis via Digitalmars-d wrote:

 No idea whether that's related or not. But regardless, that does narrow down
 the problem some. Still, given how consistent it is on my box (I've _never_
 seen it succeed on 2.067 or master), I really have to wonder what the
 difference betwen my box and the autotesters are.

 - Jonathan M Davis


 The biggest difference is likely that the auto-testers are running
 freebsd 8.x (whatever's most recent (a relative term), either 3 or 4).


Ah. That's quite a bit older, since the latest FreeBSD is 10.1. So, that
probably explains it and likely means that the problem has nothing to do
with my local setup and more to do with changes in FreeBSD since 8 - though
since dmd/druntime 2.066 didn't have the problem, either our code changed in
a way that broke on newer FreeBSD systems, or we got a new test that just
happens to expose an existing bug. I'll probably have to find time to at
least narrow down the problem, and maybe I'll get lucky and actually know
enough about the problem code to fix it, though I question that, given where
it seems like the problem is. :|

- Jonathan M Davis
Apr 20 2015
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
In any case, I just reported the bug:

https://issues.dlang.org/show_bug.cgi?id=14476

I guess that the fact that it wasn't found sooner just goes to show that not
many druntime developers are using FreeBSD (though that's not exactly
surprising).

- Jonahan M Davis
Apr 20 2015