Hi,

I've noticed recently, that whenever I unittest, it program hangs either at the very end, or right before they start. When using vanilla unit tests, the program appears to hang after the "All unit tests have been completed successfully." message, and I have to force to program to exit. However, when I use unit-threaded for my unit testing, it gets to the "Running unit tests in dirs ["."]" and then refuses to do anything more. Strangely enough, sometimes commenting out one or two tests seems to fix the issue with unit-threaded, only to resurface when I write a new test. Just what is going on?

On Thursday, 29 December 2016 at 20:27:21 UTC, David  Zhang wrote:
> Hi,
>
> I've noticed recently, that whenever I unittest, it program hangs either at the very end, or right before they start. When using vanilla unit tests, the program appears to hang after the "All unit tests have been completed successfully." message, and I have to force to program to exit. However, when I use unit-threaded for my unit testing, it gets to the "Running unit tests in dirs ["."]" and then refuses to do anything more. Strangely enough, sometimes commenting out one or two tests seems to fix the issue with unit-threaded, only to resurface when I write a new test. Just what is going on?

It would be very helpful if you could provide example code that triggers that behavior.

On Thursday, 29 December 2016 at 20:33:33 UTC, Stefan Koch wrote:
> It would be very helpful if you could provide example code that triggers that behavior.

I'd love to, but I'm not actually sure just what it is that breaks it. I can provide the git repo for one of them though though:

https://gitlab.com/Straivers/Weave
https://gitlab.com/Straivers/Weave.git

On Thursday, 29 December 2016 at 20:50:54 UTC, David  Zhang wrote:
> On Thursday, 29 December 2016 at 20:33:33 UTC, Stefan Koch wrote:
>> It would be very helpful if you could provide example code that triggers that behavior.
>
> I'd love to, but I'm not actually sure just what it is that breaks it. I can provide the git repo for one of them though though:
>
> https://gitlab.com/Straivers/Weave
> https://gitlab.com/Straivers/Weave.git

Ok, so after further fiddling, it seems to originate from here:

[from the list class]

@safe unittest {
    class A {
        int foo;
    }

    auto list = new List!A();
    list ~= [new A, new A, new A];

    assert(list.findElement(null).result == null);
}

However, commenting it out, and replacing it with another block (the test immediately below it, causes it to hang too, or error out and crash without any error message.

On 12/29/16 3:27 PM, David Zhang wrote:
> Hi,
>
> I've noticed recently, that whenever I unittest, it program hangs either
> at the very end, or right before they start. When using vanilla unit
> tests, the program appears to hang after the "All unit tests have been
> completed successfully." message, and I have to force to program to
> exit. However, when I use unit-threaded for my unit testing, it gets to
> the "Running unit tests in dirs ["."]" and then refuses to do anything
> more. Strangely enough, sometimes commenting out one or two tests seems
> to fix the issue with unit-threaded, only to resurface when I write a
> new test. Just what is going on?

Where does the "All unit tests have been completed successfully." message come from? That's not standard D, which prints nothing.

-Steve

On Friday, 30 December 2016 at 00:44:50 UTC, Steven Schveighoffer wrote:
>
> Where does the "All unit tests have been completed successfully." message come from? That's not standard D, which prints nothing.
>
> -Steve

I should have mentioned that I use dub then, shouldn't I? Anyway, this is what I get:

C:\Users\David\Projects\weave>dub test
Generating test runner configuration '__test__library__' for 'library' (library).
Performing "unittest" build using dmd for x86.
weave ~master: building configuration "__test__library__"...
Linking...
Running .\bin\__test__library__.exe
All unit tests have been run successfully.

On 12/29/16 7:49 PM, David Zhang wrote:
> On Friday, 30 December 2016 at 00:44:50 UTC, Steven Schveighoffer wrote:
>>
>> Where does the "All unit tests have been completed successfully."
>> message come from? That's not standard D, which prints nothing.
>>
>
> I should have mentioned that I use dub then, shouldn't I? Anyway, this
> is what I get:
>
> C:\Users\David\Projects\weave>dub test
> Generating test runner configuration '__test__library__' for 'library'
> (library).
> Performing "unittest" build using dmd for x86.
> weave ~master: building configuration "__test__library__"...
> Linking...
> Running .\bin\__test__library__.exe
> All unit tests have been run successfully.

Looks like that comes from here:

https://github.com/dlang/dub/blob/master/source/dub/dub.d#L577

I have serious doubts that this is the correct way to run tests, as share ctors are supposed to have run BEFORE unit tests are allowed to. It's quite possible (and likely) that unit tests are running before critical other shared ctors have completed, which is why something isn't working.

In any case, it looks like the unit tests have run, and run successfully, and then main has run, and then it's the teardown of the runtime that's hanging.

I'm not 100% certain, because I don't know exactly how this code comes into play -- it's a string in this file.

-Steve

On Friday, 30 December 2016 at 01:25:50 UTC, Steven Schveighoffer wrote:
> Looks like that comes from here:
>
> https://github.com/dlang/dub/blob/master/source/dub/dub.d#L577
>
> I have serious doubts that this is the correct way to run tests, as share ctors are supposed to have run BEFORE unit tests are allowed to. It's quite possible (and likely) that unit tests are running before critical other shared ctors have completed, which is why something isn't working.
>
> In any case, it looks like the unit tests have run, and run successfully, and then main has run, and then it's the teardown of the runtime that's hanging.
>
> I'm not 100% certain, because I don't know exactly how this code comes into play -- it's a string in this file.
>
> -Steve

Huh, shouldn't this problem have manifested itself earlier then? Why only now? I don't remember this happening previously. At the very least I'm pretty sure I first encountered it last week. Unless something in DMD was patched? But then there'd be no way I'm the only one encountering this problem, and there don't appear to be any issues on github's tracker.

On 12/29/16 8:33 PM, David Zhang wrote:
> On Friday, 30 December 2016 at 01:25:50 UTC, Steven Schveighoffer wrote:
>> Looks like that comes from here:
>>
>> https://github.com/dlang/dub/blob/master/source/dub/dub.d#L577
>>
>> I have serious doubts that this is the correct way to run tests, as
>> share ctors are supposed to have run BEFORE unit tests are allowed to.
>> It's quite possible (and likely) that unit tests are running before
>> critical other shared ctors have completed, which is why something
>> isn't working.
>>
>> In any case, it looks like the unit tests have run, and run
>> successfully, and then main has run, and then it's the teardown of the
>> runtime that's hanging.
>>
>> I'm not 100% certain, because I don't know exactly how this code comes
>> into play -- it's a string in this file.
>
> Huh, shouldn't this problem have manifested itself earlier then? Why
> only now? I don't remember this happening previously.

This is one of those very fragile and seemingly random types of things. A change in code, a change in linker order, maybe even random chance, can cause it to fail or not.

> At the very least
> I'm pretty sure I first encountered it last week. Unless something in
> DMD was patched? But then there'd be no way I'm the only one
> encountering this problem, and there don't appear to be any issues on
> github's tracker.

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

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.