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

Commit: 1ea100c1cea34202ccb70609635f3124a5a5555a
    https://github.com/D-Programming-Language/druntime/commit/1ea100c1cea34202ccb70609635f3124a5a5555a
Author: Sean Kelly <sean at invisibleduck.org>
Date:   2011-03-30 (Wed, 30 Mar 2011)

Changed paths:
  M src/rt/deh2.d

Log Message:
-----------
this should fix the remaining test suite breaks

Odd.. seems to have fixed osx but not linux or freebsd.

On Wed, 30 Mar 2011, noreply at github.com wrote:

> Branch: refs/heads/master
> Home:   https://github.com/D-Programming-Language/druntime
> 
> Commit: 1ea100c1cea34202ccb70609635f3124a5a5555a
>     https://github.com/D-Programming-Language/druntime/commit/1ea100c1cea34202ccb70609635f3124a5a5555a
> Author: Sean Kelly <sean at invisibleduck.org>
> Date:   2011-03-30 (Wed, 30 Mar 2011)
> 
> Changed paths:
>   M src/rt/deh2.d
> 
> Log Message:
> -----------
> this should fix the remaining test suite breaks
> 
> 

Even odder, the failure line (eh.d:416) indicates that not all of the finally blocks were run, which is something my changes shouldn't have affected.

On Mar 30, 2011, at 2:13 PM, Brad Roberts wrote:

> Odd.. seems to have fixed osx but not linux or freebsd.
> 
> On Wed, 30 Mar 2011, noreply at github.com wrote:
> 
>> Branch: refs/heads/master
>> Home:   https://github.com/D-Programming-Language/druntime
>> 
>> Commit: 1ea100c1cea34202ccb70609635f3124a5a5555a
>>    https://github.com/D-Programming-Language/druntime/commit/1ea100c1cea34202ccb70609635f3124a5a5555a
>> Author: Sean Kelly <sean at invisibleduck.org>
>> Date:   2011-03-30 (Wed, 30 Mar 2011)
>> 
>> Changed paths:
>>  M src/rt/deh2.d
>> 
>> Log Message:
>> -----------
>> this should fix the remaining test suite breaks
>> 
>> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

I've tried to reproduce this failure in my Linux VM and can't.  Once I updated everything the eh.d tests completed without a hitch.

On Mar 30, 2011, at 10:21 PM, Sean Kelly wrote:

> Even odder, the failure line (eh.d:416) indicates that not all of the finally blocks were run, which is something my changes shouldn't have affected.
> 
> On Mar 30, 2011, at 2:13 PM, Brad Roberts wrote:
> 
>> Odd.. seems to have fixed osx but not linux or freebsd.
>> 
>> On Wed, 30 Mar 2011, noreply at github.com wrote:
>> 
>>> Branch: refs/heads/master
>>> Home:   https://github.com/D-Programming-Language/druntime
>>> 
>>> Commit: 1ea100c1cea34202ccb70609635f3124a5a5555a
>>>   https://github.com/D-Programming-Language/druntime/commit/1ea100c1cea34202ccb70609635f3124a5a5555a
>>> Author: Sean Kelly <sean at invisibleduck.org>
>>> Date:   2011-03-30 (Wed, 30 Mar 2011)
>>> 
>>> Changed paths:
>>> M src/rt/deh2.d
>>> 
>>> Log Message:
>>> -----------
>>> this should fix the remaining test suite breaks
>>> 
>>> 
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Did you notice that it's the test with -O that's failing?  The non -O build worked just fine.

I haven't looked any deeper yet.

On 3/31/2011 2:03 PM, Sean Kelly wrote:
> I've tried to reproduce this failure in my Linux VM and can't.  Once I updated everything the eh.d tests completed without a hitch.
> 
> On Mar 30, 2011, at 10:21 PM, Sean Kelly wrote:
> 
>> Even odder, the failure line (eh.d:416) indicates that not all of the finally blocks were run, which is something my changes shouldn't have affected.
>>
>> On Mar 30, 2011, at 2:13 PM, Brad Roberts wrote:
>>
>>> Odd.. seems to have fixed osx but not linux or freebsd.
>>>
>>> On Wed, 30 Mar 2011, noreply at github.com wrote:
>>>
>>>> Branch: refs/heads/master
>>>> Home:   https://github.com/D-Programming-Language/druntime
>>>>
>>>> Commit: 1ea100c1cea34202ccb70609635f3124a5a5555a
>>>>   https://github.com/D-Programming-Language/druntime/commit/1ea100c1cea34202ccb70609635f3124a5a5555a
>>>> Author: Sean Kelly <sean at invisibleduck.org>
>>>> Date:   2011-03-30 (Wed, 30 Mar 2011)
>>>>
>>>> Changed paths:
>>>> M src/rt/deh2.d
>>>>
>>>> Log Message:
>>>> -----------
>>>> this should fix the remaining test suite breaks
>>>>
>>>>
>>> _______________________________________________
>>> D-runtime mailing list
>>> D-runtime at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>>
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

This is interesting.  It looks like a problem with opt + tls + eh issue.  if I make result1513 __gshared, the bug goes away.  If I build without -O, the bug doesn't show up.

Walter, think you can help with this one?

--- more details ---

Adding some printfs after each change to the result1513 variable and just before the last assert:

../src/dmd -m32 -Irunnable   -odtest_results/runnable -oftest_results/runnable/eh_0 runnable/eh.d
test_results/runnable/eh_0
start
1: result1513 = 1
2: result1513 = 5
3: result1513 = 7
4: result1513 = 7

../src/dmd -m32 -Irunnable  -O -odtest_results/runnable -oftest_results/runnable/eh_1 runnable/eh.d
test_results/runnable/eh_1
start
1: result1513 = 1
2: result1513 = 5
3: result1513 = 7
4: result1513 = -1077277272

../src/dmd -m32 -Irunnable  -fPIC -odtest_results/runnable -oftest_results/runnable/eh_2 runnable/eh.d
test_results/runnable/eh_2
start
1: result1513 = 1
2: result1513 = 5
3: result1513 = 7
4: result1513 = 7

../src/dmd -m32 -Irunnable  -O -fPIC -odtest_results/runnable -oftest_results/runnable/eh_3 runnable/eh.d
test_results/runnable/eh_3
start
1: result1513 = 1
2: result1513 = 5
3: result1513 = 7
4: result1513 = 134593663

void bug1513()
{
    result1513 = 0;
    //printf("0: result1513 = %d\n", result1513);
    try
    {
        bug1513c();
    }
    catch(Exception e)
    {
        printf("4: result1513 = %d\n", result1513);
        assert(result1513 == 7);
        assert(e.msg == "a");
        assert(e.next.msg == "b");
        assert(e.next.next.msg == "c");
    }
}

If I uncomment the printf above, the value at #4 is correct.

On 4/1/2011 11:50 PM, Brad Roberts wrote:
> Did you notice that it's the test with -O that's failing?  The non -O build worked just fine.
> 
> I haven't looked any deeper yet.
> 
> On 3/31/2011 2:03 PM, Sean Kelly wrote:
>> I've tried to reproduce this failure in my Linux VM and can't.  Once I updated everything the eh.d tests completed without a hitch.
>>
>> On Mar 30, 2011, at 10:21 PM, Sean Kelly wrote:
>>
>>> Even odder, the failure line (eh.d:416) indicates that not all of the finally blocks were run, which is something my changes shouldn't have affected.
>>>
>>> On Mar 30, 2011, at 2:13 PM, Brad Roberts wrote:
>>>
>>>> Odd.. seems to have fixed osx but not linux or freebsd.
>>>>
>>>> On Wed, 30 Mar 2011, noreply at github.com wrote:
>>>>
>>>>> Branch: refs/heads/master
>>>>> Home:   https://github.com/D-Programming-Language/druntime
>>>>>
>>>>> Commit: 1ea100c1cea34202ccb70609635f3124a5a5555a
>>>>>   https://github.com/D-Programming-Language/druntime/commit/1ea100c1cea34202ccb70609635f3124a5a5555a
>>>>> Author: Sean Kelly <sean at invisibleduck.org>
>>>>> Date:   2011-03-30 (Wed, 30 Mar 2011)
>>>>>
>>>>> Changed paths:
>>>>> M src/rt/deh2.d
>>>>>
>>>>> Log Message:
>>>>> -----------
>>>>> this should fix the remaining test suite breaks
>>>>>

Walter fixed the eh related optimization bug, and the tests are now passing.  Yay.

On Sat, 2 Apr 2011, Brad Roberts wrote:

> This is interesting.  It looks like a problem with opt + tls + eh issue.  if I make result1513 __gshared, the bug goes away.  If I build without -O, the bug doesn't show up.
> 
> Walter, think you can help with this one?
> 
> --- more details ---
> 
> Adding some printfs after each change to the result1513 variable and just before the last assert:
> 
> ../src/dmd -m32 -Irunnable   -odtest_results/runnable -oftest_results/runnable/eh_0 runnable/eh.d
> test_results/runnable/eh_0
> start
> 1: result1513 = 1
> 2: result1513 = 5
> 3: result1513 = 7
> 4: result1513 = 7
> 
> ../src/dmd -m32 -Irunnable  -O -odtest_results/runnable -oftest_results/runnable/eh_1 runnable/eh.d
> test_results/runnable/eh_1
> start
> 1: result1513 = 1
> 2: result1513 = 5
> 3: result1513 = 7
> 4: result1513 = -1077277272
> 
> ../src/dmd -m32 -Irunnable  -fPIC -odtest_results/runnable -oftest_results/runnable/eh_2 runnable/eh.d
> test_results/runnable/eh_2
> start
> 1: result1513 = 1
> 2: result1513 = 5
> 3: result1513 = 7
> 4: result1513 = 7
> 
> ../src/dmd -m32 -Irunnable  -O -fPIC -odtest_results/runnable -oftest_results/runnable/eh_3 runnable/eh.d
> test_results/runnable/eh_3
> start
> 1: result1513 = 1
> 2: result1513 = 5
> 3: result1513 = 7
> 4: result1513 = 134593663
> 
> void bug1513()
> {
>     result1513 = 0;
>     //printf("0: result1513 = %d\n", result1513);
>     try
>     {
>         bug1513c();
>     }
>     catch(Exception e)
>     {
>         printf("4: result1513 = %d\n", result1513);
>         assert(result1513 == 7);
>         assert(e.msg == "a");
>         assert(e.next.msg == "b");
>         assert(e.next.next.msg == "c");
>     }
> }
> 
> If I uncomment the printf above, the value at #4 is correct.
> 
> On 4/1/2011 11:50 PM, Brad Roberts wrote:
> > Did you notice that it's the test with -O that's failing?  The non -O build worked just fine.
> > 
> > I haven't looked any deeper yet.
> > 
> > On 3/31/2011 2:03 PM, Sean Kelly wrote:
> >> I've tried to reproduce this failure in my Linux VM and can't.  Once I updated everything the eh.d tests completed without a hitch.
> >>
> >> On Mar 30, 2011, at 10:21 PM, Sean Kelly wrote:
> >>
> >>> Even odder, the failure line (eh.d:416) indicates that not all of the finally blocks were run, which is something my changes shouldn't have affected.
> >>>
> >>> On Mar 30, 2011, at 2:13 PM, Brad Roberts wrote:
> >>>
> >>>> Odd.. seems to have fixed osx but not linux or freebsd.
> >>>>
> >>>> On Wed, 30 Mar 2011, noreply at github.com wrote:
> >>>>
> >>>>> Branch: refs/heads/master
> >>>>> Home:   https://github.com/D-Programming-Language/druntime
> >>>>>
> >>>>> Commit: 1ea100c1cea34202ccb70609635f3124a5a5555a
> >>>>>   https://github.com/D-Programming-Language/druntime/commit/1ea100c1cea34202ccb70609635f3124a5a5555a
> >>>>> Author: Sean Kelly <sean at invisibleduck.org>
> >>>>> Date:   2011-03-30 (Wed, 30 Mar 2011)
> >>>>>
> >>>>> Changed paths:
> >>>>> M src/rt/deh2.d
> >>>>>
> >>>>> Log Message:
> >>>>> -----------
> >>>>> this should fix the remaining test suite breaks
> >>>>>
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
> 

I was hoping that's what the optimizer commit was for.  The for loop over the __inflight list can be eliminated (it's a stack, doesn't need to act like a list) so I'll take care of that in the next few days.  Very glad that the tests are all passing now though.

On Apr 6, 2011, at 12:13 PM, Brad Roberts wrote:

> Walter fixed the eh related optimization bug, and the tests are now passing.  Yay.
> 
> On Sat, 2 Apr 2011, Brad Roberts wrote:
> 
>> This is interesting.  It looks like a problem with opt + tls + eh issue.  if I make result1513 __gshared, the bug goes away.  If I build without -O, the bug doesn't show up.
>> 
>> Walter, think you can help with this one?
>> 
>> --- more details ---
>> 
>> Adding some printfs after each change to the result1513 variable and just before the last assert:
>> 
>> ../src/dmd -m32 -Irunnable   -odtest_results/runnable -oftest_results/runnable/eh_0 runnable/eh.d
>> test_results/runnable/eh_0
>> start
>> 1: result1513 = 1
>> 2: result1513 = 5
>> 3: result1513 = 7
>> 4: result1513 = 7
>> 
>> ../src/dmd -m32 -Irunnable  -O -odtest_results/runnable -oftest_results/runnable/eh_1 runnable/eh.d
>> test_results/runnable/eh_1
>> start
>> 1: result1513 = 1
>> 2: result1513 = 5
>> 3: result1513 = 7
>> 4: result1513 = -1077277272
>> 
>> ../src/dmd -m32 -Irunnable  -fPIC -odtest_results/runnable -oftest_results/runnable/eh_2 runnable/eh.d
>> test_results/runnable/eh_2
>> start
>> 1: result1513 = 1
>> 2: result1513 = 5
>> 3: result1513 = 7
>> 4: result1513 = 7
>> 
>> ../src/dmd -m32 -Irunnable  -O -fPIC -odtest_results/runnable -oftest_results/runnable/eh_3 runnable/eh.d
>> test_results/runnable/eh_3
>> start
>> 1: result1513 = 1
>> 2: result1513 = 5
>> 3: result1513 = 7
>> 4: result1513 = 134593663
>> 
>> void bug1513()
>> {
>>    result1513 = 0;
>>    //printf("0: result1513 = %d\n", result1513);
>>    try
>>    {
>>        bug1513c();
>>    }
>>    catch(Exception e)
>>    {
>>        printf("4: result1513 = %d\n", result1513);
>>        assert(result1513 == 7);
>>        assert(e.msg == "a");
>>        assert(e.next.msg == "b");
>>        assert(e.next.next.msg == "c");
>>    }
>> }
>> 
>> If I uncomment the printf above, the value at #4 is correct.
>> 
>> On 4/1/2011 11:50 PM, Brad Roberts wrote:
>>> Did you notice that it's the test with -O that's failing?  The non -O build worked just fine.
>>> 
>>> I haven't looked any deeper yet.
>>> 
>>> On 3/31/2011 2:03 PM, Sean Kelly wrote:
>>>> I've tried to reproduce this failure in my Linux VM and can't.  Once I updated everything the eh.d tests completed without a hitch.
>>>> 
>>>> On Mar 30, 2011, at 10:21 PM, Sean Kelly wrote:
>>>> 
>>>>> Even odder, the failure line (eh.d:416) indicates that not all of the finally blocks were run, which is something my changes shouldn't have affected.
>>>>> 
>>>>> On Mar 30, 2011, at 2:13 PM, Brad Roberts wrote:
>>>>> 
>>>>>> Odd.. seems to have fixed osx but not linux or freebsd.
>>>>>> 
>>>>>> On Wed, 30 Mar 2011, noreply at github.com wrote:
>>>>>> 
>>>>>>> Branch: refs/heads/master
>>>>>>> Home:   https://github.com/D-Programming-Language/druntime
>>>>>>> 
>>>>>>> Commit: 1ea100c1cea34202ccb70609635f3124a5a5555a
>>>>>>>  https://github.com/D-Programming-Language/druntime/commit/1ea100c1cea34202ccb70609635f3124a5a5555a
>>>>>>> Author: Sean Kelly <sean at invisibleduck.org>
>>>>>>> Date:   2011-03-30 (Wed, 30 Mar 2011)
>>>>>>> 
>>>>>>> Changed paths:
>>>>>>> M src/rt/deh2.d
>>>>>>> 
>>>>>>> Log Message:
>>>>>>> -----------
>>>>>>> this should fix the remaining test suite breaks
>>>>>>> 
>> 
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

On 6 April 2011 23:47, Sean Kelly <sean at invisibleduck.org> wrote:
> I was hoping that's what the optimizer commit was for. ?The for loop over the __inflight list can be eliminated (it's a stack, doesn't need to act like a list) so I'll take care of that in the next few days. ?Very glad that the tests are all passing now though.

It's awesome that we have exception chaining on all platforms now. Great work, Sean.

> On 6 April 2011 23:47, Sean Kelly <sean at invisibleduck.org> wrote:
> > I was hoping that's what the optimizer commit was for.  The for loop over the __inflight list can be eliminated (it's a stack, doesn't need to act like a list) so I'll take care of that in the next few days.  Very glad that the tests are all passing now though.
> 
> It's awesome that we have exception chaining on all platforms now. Great work, Sean.

Does the exception chaining include printing out the whole chain of exceptions when they escape main? In the past, when chaining an exception manually by passing an exception to Exception or Error's constructors (or any type derived from them), only the one on the end of the chain was printed. Ideally, they'd all be printed.

- Jonathan M Davis