more disastrous 64 bit bugs fixed

http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip

On 2/13/2011 10:44 PM, Walter Bright wrote:
> more disastrous 64 bit bugs fixed
> 
> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip

Having the change log off in another package is awfully inconvenient.  I renew my suggestion to have change logs per package that the doc building process merges together.  Here's my set of fixed bugs that I haven't added yet:

    bug 5319: add Solaris as a pthread based monitor user
    bug 5483: Add x86-64 version of mcontext_t for FreeBSD
    incorporate patch from bug 5495: Compile Error(FreeBSD): undefined identifier CLOCK_MONOTONIC

On 14 February 2011 08:59, Brad Roberts <braddr at puremagic.com> wrote:
> On 2/13/2011 10:44 PM, Walter Bright wrote:
>> more disastrous 64 bit bugs fixed
>>
>> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
>
> Having the change log off in another package is awfully inconvenient. ?I renew my suggestion to have change logs per package that the doc building process merges together.

Agreed. I even think that most users want to view the fixed compiler
bugs in a different list from the fixed Phobos bugs (note that Phobos
bugs also apply to GDC), so I think the lists should just go in, one
after the other.
The druntime bugs are a bit less straightforward, since many of them
are closely tied to the compiler. But still, I don't think it needs to
be complicated.

Don Clugston wrote:
> On 14 February 2011 08:59, Brad Roberts <braddr at puremagic.com> wrote:
> 
>> On 2/13/2011 10:44 PM, Walter Bright wrote:
>> 
>>> more disastrous 64 bit bugs fixed
>>>
>>> http://ftp.digitalmars.com/dmd1beta.zip
>>> http://ftp.digitalmars.com/dmd2beta.zip
>>> 
>> Having the change log off in another package is awfully inconvenient.  I renew my suggestion to have change logs per
>> package that the doc building process merges together.
>> 
>
> Agreed. I even think that most users want to view the fixed compiler
> bugs in a different list from the fixed Phobos bugs (note that Phobos
> bugs also apply to GDC), so I think the lists should just go in, one
> after the other.
> The druntime bugs are a bit less straightforward, since many of them
> are closely tied to the compiler. But still, I don't think it needs to
> be complicated.
>
> 

Prolly a good idea to have separate sections in the changelog - compiler & library

Unfortunately I found one more segfault bug that was masked by some of the other bugs I filed last night (i.e. I thought it was a manifestation of the same bug).  I'm not 100% sure it's not a bug in my code (it is horribly complicated multithreaded code, after all), though my code works on 32-bit so I'm fairly sure.

I don't have time to reduce it right now (maybe tonight or tomorrow). In case anyone else wants to try, the second unit test block of std.parallelism (http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d) segfaults, but only on 64-bit builds.  This happens sometimes even with -O enabled, but much more often without.  According to GDB the segfaults occur in pthread_condition_wait, called from core.sync.condition.wait().  Apparently bogus arguments are getting passed somewhere.

On 2/14/2011 1:44 AM, Walter Bright wrote:
> more disastrous 64 bit bugs fixed
>
> http://ftp.digitalmars.com/dmd1beta.zip
> http://ftp.digitalmars.com/dmd2beta.zip
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

Actually this bug does not seem to be 64-related at all.  It's just easier to reproduce on 64 for some reason (i.e. my std.parallelism unit tests can reproduce it).  However, I just tried to use the latest beta in 32-bit mode on real-world code that uses std.parallelism, and it segfaults in pthread_cond_wait, too.  This does not happen when I use 2.051, again in 32-bit mode.

On Mon, Feb 14, 2011 at 9:36 AM, David Simcha <dsimcha at gmail.com> wrote:

> Unfortunately I found one more segfault bug that was masked by some of the other bugs I filed last night (i.e. I thought it was a manifestation of the same bug).  I'm not 100% sure it's not a bug in my code (it is horribly complicated multithreaded code, after all), though my code works on 32-bit so I'm fairly sure.
>
> I don't have time to reduce it right now (maybe tonight or tomorrow).  In
> case anyone else wants to try, the second unit test block of std.parallelism
> (
> http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d)
> segfaults, but only on 64-bit builds.  This happens sometimes even with -O
> enabled, but much more often without.  According to GDB the segfaults occur
> in pthread_condition_wait, called from core.sync.condition.wait().
>  Apparently bogus arguments are getting passed somewhere.
>
>
> On 2/14/2011 1:44 AM, Walter Bright wrote:
>
>> more disastrous 64 bit bugs fixed
>>
>> http://ftp.digitalmars.com/dmd1beta.zip
>> http://ftp.digitalmars.com/dmd2beta.zip
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110214/cd0d6348/attachment-0001.html>

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110214/8b776e8b/attachment.html>

Care to do a little bisecting of druntime with git to see which change introduced the problem?  Assuming it doesn't happen in 2.051:

Start with commit fdb3d7096836b533e1426cb4ab18c3fecbd00c0a as that was shortly before the 2.051 release.  Check it out and validate that it works ok for you.  Assuming it does, then run this recipe:

git bisect start HEAD fdb3d7096836b533e1426cb4ab18c3fecbd00c0a

If I'm remembering correctly, that'll checkout a candidate midpoint to build and test with, so:

make clean; make  (filling in the rest of the args as appropriate to
build)
run test

if good:  git bisect good
if bad:   git bisect bad

goto build step.

Assuming accurate detection of good vs bad, this works amazingly well. Also assuming it's in druntime.  It might not be.  It looks like you're not using any of the phobos code, so you can avoid recompiling it each time and tell dmd to just link against libdruntime with:

  dmd -defaultlib=druntime

Depending on your environment, you might also need -L-L<path to druntime>



On Mon, 14 Feb 2011, David Simcha wrote:

> Date: Mon, 14 Feb 2011 20:47:11 -0500
> From: David Simcha <dsimcha at gmail.com>
> Reply-To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Subject: Re: [dmd-beta] Mo' Beta: dmd 1.067 and 2.052 beta
> 
> Jackpot.? I don't know how noone caught a bug this obvious yet.?
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=5579
> 
> On 2/14/2011 11:45 AM, David Simcha wrote:
>       Actually this bug does not seem to be 64-related at all.? It's just easier to reproduce on 64 for some reason (i.e. my std.parallelism unit tests can reproduce it).? However, I just tried to
>       use the latest beta in 32-bit mode on real-world code that uses std.parallelism, and it segfaults in pthread_cond_wait, too.? This does not happen when I use 2.051, again in 32-bit mode.
> 
>       On Mon, Feb 14, 2011 at 9:36 AM, David Simcha <dsimcha at gmail.com> wrote:
>             Unfortunately I found one more segfault bug that was masked by some of the other bugs I filed last night (i.e. I thought it was a manifestation of the same bug). ?I'm not 100%
>             sure it's not a bug in my code (it is horribly complicated multithreaded code, after all), though my code works on 32-bit so I'm fairly sure.
> 
>             I don't have time to reduce it right now (maybe tonight or tomorrow). ?In case anyone else wants to try, the second unit test block of std.parallelism
>             (http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d) segfaults, but only on 64-bit builds. ?This happens sometimes even with -O enabled, but much
>             more often without. ?According to GDB the segfaults occur in pthread_condition_wait, called from core.sync.condition.wait(). ?Apparently bogus arguments are getting passed
>             somewhere.
> 
>             On 2/14/2011 1:44 AM, Walter Bright wrote:
>                   more disastrous 64 bit bugs fixed
> 
>                   http://ftp.digitalmars.com/dmd1beta.zip
>                   http://ftp.digitalmars.com/dmd2beta.zip
>                   _______________________________________________
>                   dmd-beta mailing list
>                   dmd-beta at puremagic.com
>                   http://lists.puremagic.com/mailman/listinfo/dmd-beta
> 
> 
> 
> 
> 
> 
-------------- next part --------------
_______________________________________________
dmd-beta mailing list
dmd-beta at puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Monday, February 14, 2011 18:03:51 Brad Roberts wrote:
> Care to do a little bisecting of druntime with git to see which change introduced the problem?  Assuming it doesn't happen in 2.051:
> 
> Start with commit fdb3d7096836b533e1426cb4ab18c3fecbd00c0a as that was shortly before the 2.051 release.  Check it out and validate that it works ok for you.  Assuming it does, then run this recipe:
> 
> git bisect start HEAD fdb3d7096836b533e1426cb4ab18c3fecbd00c0a
> 
> If I'm remembering correctly, that'll checkout a candidate midpoint to build and test with, so:
> 
> make clean; make  (filling in the rest of the args as appropriate to
> build)
> run test
> 
> if good:  git bisect good
> if bad:   git bisect bad
> 
> goto build step.
> 
> Assuming accurate detection of good vs bad, this works amazingly well. Also assuming it's in druntime.  It might not be.  It looks like you're not using any of the phobos code, so you can avoid recompiling it each time and tell dmd to just link against libdruntime with:
> 
>   dmd -defaultlib=druntime
> 
> Depending on your environment, you might also need -L-L<path to druntime>
> 
> On Mon, 14 Feb 2011, David Simcha wrote:
> > Date: Mon, 14 Feb 2011 20:47:11 -0500
> > From: David Simcha <dsimcha at gmail.com>
> > Reply-To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> > To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> > Subject: Re: [dmd-beta] Mo' Beta: dmd 1.067 and 2.052 beta
> > 
> > Jackpot.  I don't know how noone caught a bug this obvious yet.
> > 
> > http://d.puremagic.com/issues/show_bug.cgi?id=5579

Another major thread-related bug would be http://d.puremagic.com/issues/show_bug.cgi?id=5537

I don't know if there's any relation though. It might be something entirely related to std.concurrency. And it's an invariant failure, not a segfault. But it broke quite recently as well.

- Jonathna M Davis

On Monday 14 February 2011 18:20:16 Jonathan M Davis wrote:
> On Monday, February 14, 2011 18:03:51 Brad Roberts wrote:
> > Care to do a little bisecting of druntime with git to see which change introduced the problem?  Assuming it doesn't happen in 2.051:
> > 
> > Start with commit fdb3d7096836b533e1426cb4ab18c3fecbd00c0a as that was shortly before the 2.051 release.  Check it out and validate that it works ok for you.  Assuming it does, then run this recipe:
> > 
> > git bisect start HEAD fdb3d7096836b533e1426cb4ab18c3fecbd00c0a
> > 
> > If I'm remembering correctly, that'll checkout a candidate midpoint to build and test with, so:
> > 
> > make clean; make  (filling in the rest of the args as appropriate to
> > build)
> > run test
> > 
> > if good:  git bisect good
> > if bad:   git bisect bad
> > 
> > goto build step.
> > 
> > Assuming accurate detection of good vs bad, this works amazingly well. Also assuming it's in druntime.  It might not be.  It looks like you're not using any of the phobos code, so you can avoid recompiling it each
> > 
> > time and tell dmd to just link against libdruntime with:
> >   dmd -defaultlib=druntime
> > 
> > Depending on your environment, you might also need -L-L<path to druntime>
> > 
> > On Mon, 14 Feb 2011, David Simcha wrote:
> > > Date: Mon, 14 Feb 2011 20:47:11 -0500
> > > From: David Simcha <dsimcha at gmail.com>
> > > Reply-To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> > > To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> > > Subject: Re: [dmd-beta] Mo' Beta: dmd 1.067 and 2.052 beta
> > > 
> > > Jackpot.  I don't know how noone caught a bug this obvious yet.
> > > 
> > > http://d.puremagic.com/issues/show_bug.cgi?id=5579
> 
> Another major thread-related bug would be http://d.puremagic.com/issues/show_bug.cgi?id=5537
> 
> I don't know if there's any relation though. It might be something entirely related to std.concurrency. And it's an invariant failure, not a segfault. But it broke quite recently as well.

Definitely unrelated. I used git-bisect to determine that 5537 was broken by this commit to Phobos:

https://github.com/D-Programming- Language/phobos/commit/ecc7390670a122dec11183cbefbef2e7d9477921

And since dsimcha is running into the problem with just druntime, they're defnitely two separate issues. Though 5537 _does_ render spawn utterly useless.

- Jonathan M Davis