On 12/30/16 1:03 PM, David Zhang wrote:
> On Friday, 30 December 2016 at 14:12:35 UTC, Steven Schveighoffer wrote:
>> [snip]
>> It depends on what is actually hanging the process. If it's something
>> in your code base only, then nobody else would be seeing it.
>>
>
> So, what should I do with it? I'd submit a bug report, but I don't know
> how to isolate the bug, and thus where to submit it. Really, I'd just be
> happy knowing if it's my code or not.

Can you debug and see where it's hanging?

Note that you can use dub -v I believe to see all the lines being executed by the dub process.

-Steve

On Friday, 30 December 2016 at 18:03:44 UTC, David  Zhang wrote:
> On Friday, 30 December 2016 at 14:12:35 UTC, Steven Schveighoffer wrote:
>> [snip]
>> It depends on what is actually hanging the process. If it's something in your code base only, then nobody else would be seeing it.
>>
>> -Steve
>
> So, what should I do with it? I'd submit a bug report, but I don't know how to isolate the bug, and thus where to submit it. Really, I'd just be happy knowing if it's my code or not.

Dustmite (https://github.com/CyberShadow/DustMite) is your friend!
Specifically with a timeout command (e.g. https://github.com/CyberShadow/DustMite/wiki/Running-commands-with-a-timeout) and checking whether your reduced code is still timing out (exit code of timeout is 124).
If you set it to sth. reasonable (e.g. 10s) and use multiple threads (e.g. -j32) it shouldn't take that long to have a reduced code example.

On Friday, 30 December 2016 at 20:59:30 UTC, Seb wrote:
> On Friday, 30 December 2016 at 18:03:44 UTC, David  Zhang wrote:
>> On Friday, 30 December 2016 at 14:12:35 UTC, Steven Schveighoffer wrote:
>>> [snip]
>>> It depends on what is actually hanging the process. If it's something in your code base only, then nobody else would be seeing it.
>>>
>>> -Steve
>>
>> So, what should I do with it? I'd submit a bug report, but I don't know how to isolate the bug, and thus where to submit it. Really, I'd just be happy knowing if it's my code or not.
>
> Dustmite (https://github.com/CyberShadow/DustMite) is your friend!
> Specifically with a timeout command (e.g. https://github.com/CyberShadow/DustMite/wiki/Running-commands-with-a-timeout) and checking whether your reduced code is still timing out (exit code of timeout is 124).
> If you set it to sth. reasonable (e.g. 10s) and use multiple threads (e.g. -j32) it shouldn't take that long to have a reduced code example.

There wouldn't happen to be an alternative on windows without installing cygwin would there? I don't have access to a linux machine at the moment.

@Steven, the process hangs after the "All unit tests have been successfully", after which the process is supposed to exit immediately.

--
Running .\bin\__test__library__.exe
All unit tests have been run successfully.
^C
--

On 12/30/16 4:31 PM, David Zhang wrote:
> @Steven, the process hangs after the "All unit tests have been
> successfully", after which the process is supposed to exit immediately.

What is actually happening is that the D main function returns. Then the D runtime tears down everything, including joining all threads, running all module static dtors, terminating the GC, etc.

Then it returns to the OS the exit code.

So it's likely somewhere in there that it's hanging.

-Steve

On Friday, 30 December 2016 at 22:42:07 UTC, Steven Schveighoffer wrote:
> What is actually happening is that the D main function returns. Then the D runtime tears down everything, including joining all threads, running all module static dtors, terminating the GC, etc.
>
> Then it returns to the OS the exit code.
>
> So it's likely somewhere in there that it's hanging.
>
> -Steve

I've tried manually reducing the code to find the problem. This is what I've got. I'm not sure how to reduce it further.

class Foo {
    ~this() {
        S* next, current;
        next = current = _foo;
        while (next) {
            next = current.next;
            theAllocator.dispose(current);
        }
    }

    void insert(Range)(Range range) {
        foreach (e; range)
            _foo = theAllocator.make!S(_foo);
    }

    S* _foo;

    struct S { S* next; }
}

unittest {
    auto list = new Foo();

    list.insert([1, 2, 3, 4]);
}

Extracting everything into a main() also causes the application to hang.

ie:

struct S
{
    S* next;
}

S* _foo;
foreach (e; 0 .. 10)
    _foo = theAllocator.make!S(_foo);

S* next, current;
next = current = _foo;
while (next)
{
    next = current.next;
    theAllocator.dispose(current);
}

On 31/12/2016 2:52 PM, David Zhang wrote:
> Extracting everything into a main() also causes the application to hang.
>
> ie:
>
> struct S
> {
>     S* next;
> }
>
> S* _foo;
> foreach (e; 0 .. 10)
>     _foo = theAllocator.make!S(_foo);
>
> S* next, current;
> next = current = _foo;
> while (next)
> {
>     next = current.next;
>     theAllocator.dispose(current);
> }
>
>

As it should, current is never reassigned.
You only need one var, next. Of course I didn't read the entire thread chain so, I'm probably missing something.

import std.experimental.allocator;

void main() {
        struct S { S* next; }
        S* _foo;
        foreach (e; 0 .. 10)
                _foo = theAllocator.make!S(_foo);
        S* next;

        next = _foo;
        while(next !is null) {
                auto nextT = next.next;
                theAllocator.dispose(next);
                next = nextT;
        }
}

On Saturday, 31 December 2016 at 02:03:07 UTC, rikki cattermole wrote:
> As it should, current is never reassigned.
> You only need one var, next. Of course I didn't read the entire thread chain so, I'm probably missing something.
>
> import std.experimental.allocator;
>
> void main() {
>         struct S { S* next; }
>         S* _foo;
>         foreach (e; 0 .. 10)
>                 _foo = theAllocator.make!S(_foo);
>         S* next;
>
>         next = _foo;
>         while(next !is null) {
>                 auto nextT = next.next;
>                 theAllocator.dispose(next);
>                 next = nextT;
>         }
> }

Thanks for your response. So next is never null, and thus there is an infinite loop, correct? If so, why does dub indicate that all tests are complete?

On 31/12/2016 3:32 PM, David Zhang wrote:
> On Saturday, 31 December 2016 at 02:03:07 UTC, rikki cattermole wrote:
>> As it should, current is never reassigned.
>> You only need one var, next. Of course I didn't read the entire thread
>> chain so, I'm probably missing something.
>>
>> import std.experimental.allocator;
>>
>> void main() {
>>         struct S { S* next; }
>>         S* _foo;
>>         foreach (e; 0 .. 10)
>>                 _foo = theAllocator.make!S(_foo);
>>         S* next;
>>
>>         next = _foo;
>>         while(next !is null) {
>>                 auto nextT = next.next;
>>                 theAllocator.dispose(next);
>>                 next = nextT;
>>         }
>> }
>
> Thanks for your response. So next is never null, and thus there is an
> infinite loop, correct? If so, why does dub indicate that all tests are
> complete?

No, my understand is thus:

 next = current.next;
 theAllocator.dispose(current);

When current is deallocated, current is pointing to free'd memory.
After that point it should be segfaulting when you try to access it *I think*.

On Saturday, 31 December 2016 at 02:36:01 UTC, rikki cattermole wrote:
> No, my understand is thus:
>
>  next = current.next;
>  theAllocator.dispose(current);
>
> When current is deallocated, current is pointing to free'd memory.
> After that point it should be segfaulting when you try to access it *I think*.

Huh, alright. I see what you mean. I'll keep this in mind.