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

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.

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

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

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

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. :)

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.

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

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).

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