Hi everybody,
something strange is going on:
trying compiling and running my code after an update to 2.072, I get a not very instructive segmentation fault (code -11).

Setted up a debugger in Visual Studio Code, I managed to find out the last accessible code point before the error. And this is inside
.../dmd/2.072.0/include/dlang/dmd/core/atomic.d
line 657,
at the declaration of
private HeadUnshared!(T) atomicFetchAdd(T, V1)

Indeed, this file was changed, compared to the last version (2.071.2)

1. I'm not sure, how the changes can affect the problem at all... However, as I can see, most of the changes were due to removing @trusted and @safe tags.

2. I'm aware, that the info I provided, is insufficient. But I have some difficulties to set a debugger properly on a mac... so just give me a hint how to get more information about the problem...

3. Compiling with LDC
    ldc2 --version
    LDC - the LLVM D compiler (3461e0):
    based on DMD v2.070.2 and LLVM 3.9.0
    built with LDC - the LLVM D compiler (3461e0)
    Default target: x86_64-apple-darwin16.1.0
    Host CPU: haswell
does not give the same behavior, as my code runs without any problem

Thanks for help :)
Alex

On Saturday, 5 November 2016 at 21:45:46 UTC, Alex wrote:
> Hi everybody,
> something strange is going on:
> trying compiling and running my code after an update to 2.072, I get a not very instructive segmentation fault (code -11).
>
> [...]

Could you use DustMite to generate a minimal code sample showing the bug?

https://github.com/CyberShadow/DustMite

On Saturday, 5 November 2016 at 22:38:31 UTC, cym13 wrote:
> Could you use DustMite to generate a minimal code sample showing the bug?
>
> https://github.com/CyberShadow/DustMite

tried
    dub dustmite ../dm
which reduced my code to an empty main... :)

and tried
dub dustmite ../dm2 --program-status=11
which results to a message in the console:
object.Exception@DustMite/dustmite.d(270): Initial test fails (try using --no-redirect for details)
----------------
4   dustmite                            0x000000010b7173e8 _Dmain + 3480
5   dustmite                            0x000000010b7a71df D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39
6   dustmite                            0x000000010b7a710b void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 35
7   dustmite                            0x000000010b7a7184 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 44
8   dustmite                            0x000000010b7a710b void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 35
9   dustmite                            0x000000010b7a7071 _d_run_main + 497
10  dustmite                            0x000000010b717cdf main + 15
11  libdyld.dylib                       0x00007fffb4a1d254 start + 0
12  ???                                 0x0000000000000002 0x0 + 2

How to use --no-redirect option? It said
Unknown command line flags: --no-redirect
when I tried it...

On Sunday, 6 November 2016 at 01:11:34 UTC, Alex wrote:
> dub dustmite ../dm2 --program-status=11

Try --program-status=139

(139 is 128 + 11)

On Sunday, 6 November 2016 at 01:13:51 UTC, Vladimir Panteleev wrote:
> Try --program-status=139
>
> (139 is 128 + 11)

tried
dub dustmite ../dm3 --program-status=139
which yields in
object.Exception@DustMite/dustmite.d(270): Initial test fails (try using --no-redirect for details)
----------------
4   dustmite                            0x00000001086fc3e8 _Dmain + 3480
5   dustmite                            0x000000010878c1df D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39
6   dustmite                            0x000000010878c10b void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 35
7   dustmite                            0x000000010878c184 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 44
8   dustmite                            0x000000010878c10b void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 35
9   dustmite                            0x000000010878c071 _d_run_main + 497
10  dustmite                            0x00000001086fccdf main + 15
11  libdyld.dylib                       0x00007fffb4a1d254 start + 0
12  ???                                 0x0000000000000002 0x0 + 2

I'm not sure how to pass arbitrary dustmite arguments through dub to dustmite. `dub dustmite -h' lists arguments.

When dustmite reduces your project to the empty project, maybe try this from the dustmite website: "You can also surround code that is not to be removed around the magic words DustMiteNoRemoveStart and DustMiteNoRemoveStop. Note that if you place them in comments, you won't be able to use --strip-comments."

On Sunday, 6 November 2016 at 06:28:32 UTC, Alex wrote:
> object.Exception@DustMite/dustmite.d(270): Initial test fails (try using --no-redirect for details)

This means that dustmite doesn't recognize the unreduced source as buggy. As a sanity test, dustmite runs the given test on the unreduced project, and requires this test to succeed.

-- Simon

On Sunday, 6 November 2016 at 08:48:14 UTC, SimonN wrote:
> I'm not sure how to pass arbitrary dustmite arguments through dub to dustmite. `dub dustmite -h' lists arguments.
>
> When dustmite reduces your project to the empty project, maybe try this from the dustmite website: "You can also surround code that is not to be removed around the magic words DustMiteNoRemoveStart and DustMiteNoRemoveStop. Note that if you place them in comments, you won't be able to use --strip-comments."

Ok, cool. But as I'm of the opinion, that my code is not buggy,  I don't know, which code to keep.

>
> On Sunday, 6 November 2016 at 06:28:32 UTC, Alex wrote:
>> object.Exception@DustMite/dustmite.d(270): Initial test fails (try using --no-redirect for details)
>
> This means that dustmite doesn't recognize the unreduced source as buggy. As a sanity test, dustmite runs the given test on the unreduced project, and requires this test to succeed.

I'm not the alone with the opinion of my code. LDC compiles my code and the binary runs without any problem.

Furthermore: If I take the file .../dlang/dmd/core/atomic.d from the sources of version 2.071.2 and replace with this version the file from the current version of 2.072.0;
then recompile my project by dmd and run it - it works. When using the new version, binary stops working after recompilation
This behavior is reproducible.

So my question is: how can I debug atomic.d better to locate the error more precisely.
Do not get me wrong, I still assume, that I have to change my own code. But the only entry point for debugging I can see at the moment is the file atomic.d.

ok... played with the code a little bit.

If I remove the @trusted attribute in line 657 inside atomic.d everything works as expected...
Any ideas, why it is so?

On Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:
> ok... played with the code a little bit.
>
> If I remove the @trusted attribute in line 657 inside atomic.d everything works as expected...
> Any ideas, why it is so?

By the way, replacement with @safe works too...

On 11/06/2016 05:00 PM, Alex wrote:
> On Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:
>> ok... played with the code a little bit.
>>
>> If I remove the @trusted attribute in line 657 inside atomic.d
>> everything works as expected...
>> Any ideas, why it is so?
>
> By the way, replacement with @safe works too...

Very weird. Would be great if you could provide a test case. Doesn't need to be minimal.