www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Finding the file and unittest that triggers an ICE during dub project

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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?
Jun 12 2020
next sibling parent reply Luis <luis.panadero gmail.com> writes:
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 ?
Jun 12 2020
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 12 June 2020 at 20:12:46 UTC, Luis wrote:


 Fails with dub test ?


Yes. In the same way.
Jun 13 2020
prev sibling parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
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.
Jun 12 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jun 12 2020
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Jun 13 2020
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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?
Jun 15 2020
parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
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
Jun 15 2020
next sibling parent MoonlightSentinel <moonlightsentinel disroot.org> writes:
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.
Jun 15 2020
prev sibling next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Jun 15 2020
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 15 June 2020 at 16:55:00 UTC, MoonlightSentinel wrote:

 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.


This doesn't seem like an intuitive interface to me. I would like 
`dub dustmite` to work directly inside the source tree by 
creating a temporary copy of the root directory of a clean git 
repo checkout (excluding the .git* files) where the dustmite 
action happens. I wonder if others share my opinion...
Jun 15 2020
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 15 June 2020 at 18:48:04 UTC, Per Nordlöw wrote:

 This doesn't seem like an intuitive interface to me. I would 
 like `dub dustmite` to work directly inside the source tree by 
 creating a temporary copy of the root directory of a clean git 
 repo checkout (excluding the .git* files) where the dustmite 
 action happens. I wonder if others share my opinion...


What about defaulting `destination-path` to current dub root 
directory name (without path) positioned alongside root of 
current dub project with some suitable suffix and counter value 
similar to `mktemp -d`?

So running dub dustmite inside root of

     path-to-dub-project-root-dir/some-dub-project

will default `destination-dir` to

     
path-to-dub-project-root-dir/some-dub-project.reduced-TIMESTAMP

.
Jun 16 2020