On Sunday, 6 November 2016 at 16:07:54 UTC, ag0aep6g wrote:
> 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.

I would if I would know how... :) the problem is, setting up the debugger itself was not a simple task and then, the only point where it stops - is before my main, at the mentioned line.
Every attempt to make a step just aborts the run and that's it.

What I have just tested is, that on a linux machine I have access to, the error does not appear.

On 11/07/2016 12:21 PM, Alex wrote:
> On Sunday, 6 November 2016 at 16:07:54 UTC, ag0aep6g wrote:
[...]
>> Very weird. Would be great if you could provide a test case. Doesn't
>> need to be minimal.
>
> I would if I would know how... :) the problem is, setting up the
> debugger itself was not a simple task and then, the only point where it
> stops - is before my main, at the mentioned line.
> Every attempt to make a step just aborts the run and that's it.
>
> What I have just tested is, that on a linux machine I have access to,
> the error does not appear.

Don't need a debugger to get a test case.

You have some code that segfaults when run, right? For a test case you can just post that exact code.

Of course, you should remove any confidential information, and if it's closed source you may not be allowed to post it. So you may have to reduce it to a trivial example for legal reasons. But as for a test case, you can just post the code that fails right now. Doesn't matter if that includes a lot of unrelated stuff.

Ok, ok. Here, I pasted the code, minimized as far as I could. There are 434 lines of code, sorry.
http://pastebin.com/UcZUc79g

The main is empty. This is intended. I still have the segmentation fault.

Maybe, I have another hint:
If I comment all the attributes in the
private HeadUnshared!(T) atomicFetchAdd(T, V1)( ref shared T val, V1 mod ) //pure nothrow @nogc @trusted
method in atomic.d, in line 657, away, and add something like
import std.stdio;
writeln("kuku");
at the first lines of the body
I get an error message on compiling:

/usr/local/Cellar/dmd/2.072.0/include/dlang/dmd/core/atomic.d(722,46): Error: pure function 'core.atomic.atomicOp!("+=", ulong, int).atomicOp' cannot call impure function 'core.atomic.atomicFetchAdd!(ulong, int).atomicFetchAdd'
/usr/local/Cellar/dmd/2.072.0/include/dlang/dmd/core/atomic.d(722,46): Error: @nogc function 'core.atomic.atomicOp!("+=", ulong, int).atomicOp' cannot call non-@nogc function 'core.atomic.atomicFetchAdd!(ulong, int).atomicFetchAdd'
/usr/local/Cellar/dmd/2.072.0/include/dlang/dmd/core/atomic.d(722,46): Error: function 'core.atomic.atomicFetchAdd!(ulong, int).atomicFetchAdd' is not nothrow
/usr/local/Cellar/dmd/2.072.0/include/dlang/dmd/core/atomic.d(692,22): Error: nothrow function 'core.atomic.atomicOp!("+=", ulong, int).atomicOp' may throw
/usr/local/Cellar/dmd/2.072.0/include/dlang/dmd/std/parallelism.d-mixin-3786(3812,50): Error: template instance core.atomic.atomicOp!("+=", ulong, int) error instantiating
/usr/local/Cellar/dmd/2.072.0/include/dlang/dmd/std/parallelism.d(3309,1):        instantiated from here: ParallelForeach!(double[][])
source/app.d(143,41):        instantiated from here: parallel!(double[][])
source/app.d(20,34):        instantiated from here: crs2!(crs2Fun02, crs2Params!(OptInit))

Maybe, this doesn't say anything about the segmentation error. But the last two lines are, maybe a hint, which route is taken on compilation.

On Monday, 7 November 2016 at 16:55:29 UTC, Alex wrote:

Ok... Another point is, that I'm using dub and trying compiling my app directly by dmd does not yield the error.
So, I have to attach the compiling commands, which I see, when tried
dub build --force -v

dmd -c -of./app.o -debug -g -gc -O -profile -w ./app.d -vcolumns
dmd -of./app ./app.o -g -gc

On Monday, 7 November 2016 at 17:12:32 UTC, Alex wrote:

> dmd -c -of./app.o -debug -g -gc -O -profile -w ./app.d -vcolumns
> dmd -of./app ./app.o -g -gc

Knowing this, I tried to find the option which does the difference. This was the profile option. So, if I omit it, the segmentation fault is gone...

On 11/07/2016 06:18 PM, Alex wrote:
> On Monday, 7 November 2016 at 17:12:32 UTC, Alex wrote:
>
>> dmd -c -of./app.o -debug -g -gc -O -profile -w ./app.d -vcolumns
>> dmd -of./app ./app.o -g -gc
>
> Knowing this, I tried to find the option which does the difference. This
> was the profile option. So, if I omit it, the segmentation fault is gone...

I've reduced it to this:

----
void main() {}
void f()
{
    import core.atomic: atomicOp;
    shared size_t workUnitIndex;
    atomicOp!"+="(workUnitIndex, 1);
}
----

Which crashes when compiled with -profile. Looks like issue 14511 covers this (comment 5):
https://issues.dlang.org/show_bug.cgi?id=14511#c5

On Monday, 7 November 2016 at 18:38:14 UTC, ag0aep6g wrote:
> I've reduced it to this:
>
> ----
> void main() {}
> void f()
> {
>     import core.atomic: atomicOp;
>     shared size_t workUnitIndex;
>     atomicOp!"+="(workUnitIndex, 1);
> }
> ----
>
> Which crashes when compiled with -profile. Looks like issue 14511 covers this (comment 5):
> https://issues.dlang.org/show_bug.cgi?id=14511#c5

Ok... I'm impressed. Thanks for clarification :)
But something changed nevertheless... I have the problem only since the update from 2.071.2 to 2.072.0.
Is this worth mentioning in a comment of the issue somehow?