Branch: refs/heads/master
Home:   https://github.com/D-Programming-Language/dmd

Commit: 3160a5292941b35a5c96922dd32fc8153202fe3c
    https://github.com/D-Programming-Language/dmd/commit/3160a5292941b35a5c96922dd32fc8153202fe3c
Author: Brad Roberts <braddr at puremagic.com>
Date:   2011-05-13 (Fri, 13 May 2011)

Changed paths:
  M src/backend/os.c
  M test/Makefile
  M test/d_do_test.d

Log Message:
-----------
Add support for freebsd 64 bit os support functions.  Disable 2 failing dmd test and all PIC related tests for now.


Commit: 7d29ebfb92825c1dd103e230830d7cfbb87a4da3
    https://github.com/D-Programming-Language/dmd/commit/7d29ebfb92825c1dd103e230830d7cfbb87a4da3
Author: Walter Bright <walter at walterbright.com>
Date:   2011-05-14 (Sat, 14 May 2011)

Changed paths:
  M src/backend/os.c
  M test/Makefile
  M test/d_do_test.d

Log Message:
-----------
Merge pull request #67 from braddr/freebsd64

Initial freebsd/64 patches


Compare: https://github.com/D-Programming-Language/dmd/compare/95229fe...7d29ebf

Not sure that these changes below actually caused the problem, but several runs of std/parallelism have failed:

freebsd 32
linux 32/64, twice

The first linux 64/64 run with these changes passed, as did the rest.  The second linux 64/64 run was mangled due to the makefiles MODULE changes (fixed so we'll get more data for the next run).

Given that std/parallelism hasn't had a long history of success, I'm more inclined to blame it, but not heavily so.

On 5/14/2011 12:34 PM, noreply at github.com wrote:
> Branch: refs/heads/master
> Home:   https://github.com/D-Programming-Language/dmd
> 
> Commit: 3160a5292941b35a5c96922dd32fc8153202fe3c
>     https://github.com/D-Programming-Language/dmd/commit/3160a5292941b35a5c96922dd32fc8153202fe3c
> Author: Brad Roberts <braddr at puremagic.com>
> Date:   2011-05-13 (Fri, 13 May 2011)
> 
> Changed paths:
>   M src/backend/os.c
>   M test/Makefile
>   M test/d_do_test.d
> 
> Log Message:
> -----------
> Add support for freebsd 64 bit os support functions.  Disable 2 failing dmd test and all PIC related tests for now.
> 
> 
> Commit: 7d29ebfb92825c1dd103e230830d7cfbb87a4da3
>     https://github.com/D-Programming-Language/dmd/commit/7d29ebfb92825c1dd103e230830d7cfbb87a4da3
> Author: Walter Bright <walter at walterbright.com>
> Date:   2011-05-14 (Sat, 14 May 2011)
> 
> Changed paths:
>   M src/backend/os.c
>   M test/Makefile
>   M test/d_do_test.d
> 
> Log Message:
> -----------
> Merge pull request #67 from braddr/freebsd64
> 
> Initial freebsd/64 patches
> 
> 
> Compare: https://github.com/D-Programming-Language/dmd/compare/95229fe...7d29ebf
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110514/1ff7517c/attachment-0001.html>

On 5/14/2011 3:52 PM, David Simcha wrote:
> I've looked into the Linux failures.  They are caused by a deterministic (i.e. I can reproduce it every time) null dereference  the this pointer in defaultWorkUnitSize().  It appears that DMD is somehow expecting TaskPool's this pointer to live in the RDI register.  I think, though I'm not sure, that it should be in RAX.  I *highly* doubt this is a std.parallelism bug.

It should be in RDI.

>
> As far as the FreeBSD failures, I had seen that failure once before (pre-2.053 release) but couldn't reproduce it for the life of me to understand it.  I tried about 1,000 times on your FreeBSD box by executing the unit tests in a loop.  I also stress tested std.parallelism on my Windows box through about 1,000 unittest runs, on Linux in 64 mode through about 10,000 runs and Linux 32 through about 5,000 runs.  All of these passed.  Since I couldn't for the life of me reproduce this issue on any other OS, it was insanely hard to reproduce on FreeBSD, the FreeBSD port wasn't exactly mature, and I had no idea what else to do, I gave up and assumed it was *probably* a bug in some FreeBSD-specific code.  I've added a message to the relevant assert statement so if this assert is tripped again, we'll be able to figure out why.
>
> On 5/14/2011 5:04 PM, Brad Roberts wrote:
>> Not sure that these changes below actually caused the problem, but several runs of std/parallelism have failed:
>>
>> freebsd 32
>> linux 32/64, twice
>>
>> The first linux 64/64 run with these changes passed, as did the rest.  The second linux 64/64 run was mangled due to the makefiles MODULE changes (fixed so we'll get more data for the next run).
>>
>> Given that std/parallelism hasn't had a long history of success, I'm more inclined to blame it, but not heavily so.
>>
>> On 5/14/2011 12:34 PM,noreply at github.com  wrote:of
>>> Branch: refs/heads/master Home:https://github.com/D-Programming-Language/dmd
>>>
>>> Commit: 3160a5292941b35a5c96922dd32fc8153202fe3c
>>>      https://github.com/D-Programming-Language/dmd/commit/3160a5292941b35a5c96922dd32fc8153202fe3c
>>> Author: Brad Roberts<braddr at puremagic.com>
>>> Date:   2011-05-13 (Fri, 13 May 2011)
>>>
>>> Changed paths:
>>>    M src/backend/os.c
>>>    M test/Makefile
>>>    M test/d_do_test.d
>>>
>>> Log Message:
>>> -----------
>>> Add support for freebsd 64 bit os support functions.  Disable 2 failing dmd test and all PIC related tests for now.
>>>
>>>
>>> Commit: 7d29ebfb92825c1dd103e230830d7cfbb87a4da3
>>>      https://github.com/D-Programming-Language/dmd/commit/7d29ebfb92825c1dd103e230830d7cfbb87a4da3
>>> Author: Walter Bright<walter at walterbright.com>
>>> Date:   2011-05-14 (Sat, 14 May 2011)
>>>
>>> Changed paths:
>>>    M src/backend/os.c
>>>    M test/Makefile
>>>    M test/d_do_test.d
>>>
>>> Log Message:
>>> -----------
>>> Merge pull request #67 from braddr/freebsd64
>>>
>>> Initial freebsd/64 patches
>>>
>>>
>>> Compare:https://github.com/D-Programming-Language/dmd/compare/95229fe...7d29ebf
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110514/80737241/attachment.html>

On 5/14/2011 5:04 PM, Brad Roberts wrote:
> Not sure that these changes below actually caused the problem, but several runs of std/parallelism have failed:
>
> freebsd 32
> linux 32/64, twice
>
> The first linux 64/64 run with these changes passed, as did the rest.  The second linux 64/64 run was mangled due to the makefiles MODULE changes (fixed so we'll get more data for the next run).
>
> Given that std/parallelism hasn't had a long history of success, I'm more inclined to blame it, but not heavily so.
>
BTW, on Linux 32/64, some DMD tests are also deterministically failing. I think it's a good idea to fix those first and see if that fixes std.parallelism.

On 5/14/2011 5:32 PM, David Simcha wrote:
> On 5/14/2011 5:04 PM, Brad Roberts wrote:
>> Not sure that these changes below actually caused the problem, but several runs of std/parallelism have failed:
>>
>> freebsd 32
>> linux 32/64, twice
>>
>> The first linux 64/64 run with these changes passed, as did the rest.  The second linux 64/64 run was mangled due to the makefiles MODULE changes (fixed so we'll get more data for the next run).
>>
>> Given that std/parallelism hasn't had a long history of success, I'm more inclined to blame it, but not heavily so.
>>
> BTW, on Linux 32/64, some DMD tests are also deterministically failing.  I think it's a good idea to fix those first and
> see if that fixes std.parallelism.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Yeah.. my fault.  I switch a critical os support routine to use sizeof(pthread_mutex_t) instead of a hardcoded value. This fails in the case of the compiler being built as 32 bit but the libraries built as 64 bit.  Validating my fix now and then I'll send a pull request with it.

Sigh,
Brad

On 5/14/2011 11:35 PM, Brad Roberts wrote:
> Yeah.. my fault. I switch a critical os support routine to use
> sizeof(pthread_mutex_t) instead of a hardcoded value.
> This fails in the case of the compiler being built as 32 bit but the libraries built as 64 bit.  Validating my fix now
> and then I'll send a pull request with it.
>
> Sigh,
> Brad
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
Ok, although only Murphy's Law could explain why this bug has to manifest itself on the newest Phobos module and one that deals with low-level concurrency so that you're never really sure why it's misbehaving when it misbehaves.

On 5/14/2011 8:52 PM, David Simcha wrote:
> On 5/14/2011 11:35 PM, Brad Roberts wrote:
>> Yeah.. my fault. I switch a critical os support routine to use sizeof(pthread_mutex_t) instead of a hardcoded value. This fails in the case of the compiler being built as 32 bit but the libraries built as 64 bit.  Validating my fix now and then I'll send a pull request with it.
>>
>> Sigh,
>> Brad
>
> Ok, although only Murphy's Law could explain why this bug has to manifest itself on the newest Phobos module and one that deals with low-level concurrency so that you're never really sure why it's misbehaving when it misbehaves.

Luckily it was easy to figure out once I stopped to think about it for a few minutes.  Been distracted by a bunch of
things today or it would have occurred to me much earlier, maybe even before I submitted the changes in the first place.
 Oh well.  It's fixed.. or will be once it's pulled into the main tree.