When I build my project as

    dub run --compiler=dmd --build=unittest

it crashes as

Performing "unittest" build using dmd for x86_64.
phobos-next ~master: building configuration "library"...
Segmentation fault (core dumped)
dmd failed with exit code 139.

whereas

    dub run --compiler=dmd --build=debug

passes.

How do I most easily track down which unittest in which file that causes the crash?

On Friday, 12 June 2020 at 18:18:25 UTC, Per Nordlöw wrote:
> When I build my project as
>
>     dub run --compiler=dmd --build=unittest
>
> it crashes as
>
> Performing "unittest" build using dmd for x86_64.
> phobos-next ~master: building configuration "library"...
> Segmentation fault (core dumped)
> dmd failed with exit code 139.
>
> whereas
>
>     dub run --compiler=dmd --build=debug
>
> passes.
>
> How do I most easily track down which unittest in which file that causes the crash?

Fails with dub test ?

On Friday, 12 June 2020 at 18:18:25 UTC, Per Nordlöw wrote:
> How do I most easily track down which unittest in which file that causes the crash?

You could try to reduce your code using Dustmite through dub.  This should do the job IIRC:

 dub dustmite --compiler=dmd --build=unittest --compiler-status=139

See `dub dustmite --help` for more details.

On Fri, Jun 12, 2020 at 09:29:06PM +0000, MoonlightSentinel via Digitalmars-d-learn wrote:
> On Friday, 12 June 2020 at 18:18:25 UTC, Per Nordlöw wrote:
> > How do I most easily track down which unittest in which file that causes the crash?
[...]

Compile your program with debugging symbols, and then run it in gdb. When it crashes, the `bt` command should show you the stack trace. Near the bottom of the trace (top of the stack) should be the unittest function with a name that looks like _D4test16__unittest_L5_C1FZv, where L5 means the unittest that started on line 1 of the source, and C1 means the column on that line, and "FZv" is the mangling of the unittest's attributes, and "_D4test" is the mangled name of the module, corresponding to "test".


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and over.

On Friday, 12 June 2020 at 20:12:46 UTC, Luis wrote:

> Fails with dub test ?

Yes. In the same way.

On Friday, 12 June 2020 at 21:54:57 UTC, H. S. Teoh wrote:
> On Fri, Jun 12, 2020 at 09:29:06PM +0000, MoonlightSentinel via Digitalmars-d-learn wrote:
>> On Friday, 12 June 2020 at 18:18:25 UTC, Per Nordlöw wrote:
>> > How do I most easily track down which unittest in which file that causes the crash?
> [...]
>
> Compile your program with debugging symbols, and then run it in gdb. When it crashes, the `bt` command should show you the stack trace. Near the bottom of the trace (top of the stack) should be the unittest function with a name that looks like _D4test16__unittest_L5_C1FZv, where L5 means the unittest that started on line 1 of the source, and C1 means the column on that line, and "FZv" is the mangling of the unittest's attributes, and "_D4test" is the mangled name of the module, corresponding to "test".

The crash happens during compilation not during unittest execution.

On Friday, 12 June 2020 at 21:29:06 UTC, MoonlightSentinel wrote:
> You could try to reduce your code using Dustmite through dub.  This should do the job IIRC:
>
>  dub dustmite --compiler=dmd --build=unittest --compiler-status=139
>
> See `dub dustmite --help` for more details.

The call

    dub dustmite --compiler=dmd --build=unittest --compiler-status=139

inside root (dub) directory of https://github.com/nordlow/phobos-next/

errors as

Expected destination path.
Run "dub dustmite -h" for more information about the "dustmite" command.

According to "dub dustmite -h" I source give destination path as first argument but neither

    dub dustmite . --compiler=dmd --build=unittest --compiler-status=139

nor

    dub dustmite $PWD --compiler=dmd --build=unittest --compiler-status=139

work. The both give the same error as without destination path given.

What have I missed?

On Monday, 15 June 2020 at 10:54:47 UTC, Per Nordlöw wrote:
> What have I missed?

My mistake, dub dustmite expects a path to an temporary directory suitable for dustmite (it copies the entire projet + all dependencies s.t. dustmite sees the entire source code). That path needs to be somewhere outside of the project directory.

But "dub dustmite ..." failed the first tests so I've reduced this manually by determining the correct compiler invocation (dub test -v) and running dustmite against all (remaining) source files. The test condition was a script which ran dmd in gdb and checked whether it segfaulted at the specific line of code.

The segfault happens when compiling CyclicArray with preview=dtorfields, see the bug report below for a reduced example.

TLDR: Found your bug and reported it here:
https://issues.dlang.org/show_bug.cgi?id=20934

On Monday, 15 June 2020 at 16:55:00 UTC, MoonlightSentinel wrote:

And these unittests trigger the segfault:

https://github.com/nordlow/phobos-next/blob/4a18833e226be0d3363fb07f02a7bcf531892e17/src/nxt/cyclic_array.d#L704-L712

https://github.com/nordlow/phobos-next/blob/4a18833e226be0d3363fb07f02a7bcf531892e17/src/nxt/cyclic_array.d#L1020-L1072

Adding version(none) removes the segfaults but yields other error messages.

On Monday, 15 June 2020 at 16:55:00 UTC, MoonlightSentinel wrote:
> My mistake, dub dustmite expects a path to an temporary directory suitable for dustmite (it copies the entire projet + all dependencies s.t. dustmite sees the entire source code). That path needs to be somewhere outside of the project directory.
>
> But "dub dustmite ..." failed the first tests so I've reduced this manually by determining the correct compiler invocation (dub test -v) and running dustmite against all (remaining) source files. The test condition was a script which ran dmd in gdb and checked whether it segfaulted at the specific line of code.
>
> The segfault happens when compiling CyclicArray with preview=dtorfields, see the bug report below for a reduced example.
>
> TLDR: Found your bug and reported it here:
> https://issues.dlang.org/show_bug.cgi?id=20934

Wow. Great job. I commented out the line

    @disable this();

for now.

Thanks a whole lot.