digitalmars.D.learn - Bug after update to 2.072?
- Alex (31/31) Nov 05 2016 Hi everybody,
- cym13 (4/9) Nov 05 2016 Could you use DustMite to generate a minimal code sample showing
- Alex (33/36) Nov 05 2016 tried
- Vladimir Panteleev (3/4) Nov 05 2016 Try --program-status=139
- Alex (28/30) Nov 05 2016 tried
- SimonN (13/15) Nov 06 2016 I'm not sure how to pass arbitrary dustmite arguments through dub
- Alex (16/30) Nov 06 2016 Ok, cool. But as I'm of the opinion, that my code is not buggy,
- Alex (4/4) Nov 06 2016 ok... played with the code a little bit.
- Alex (2/6) Nov 06 2016 By the way, replacement with @safe works too...
- ag0aep6g (3/10) Nov 06 2016 Very weird. Would be great if you could provide a test case. Doesn't
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
Nov 05 2016
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
Nov 05 2016
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/DustMitetried 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...
Nov 05 2016
On Sunday, 6 November 2016 at 01:11:34 UTC, Alex wrote:dub dustmite ../dm2 --program-status=11Try --program-status=139 (139 is 128 + 11)
Nov 05 2016
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
Nov 05 2016
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
Nov 06 2016
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: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.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.
Nov 06 2016
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?
Nov 06 2016
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...
Nov 06 2016
On 11/06/2016 05:00 PM, Alex wrote:On Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:Very weird. Would be great if you could provide a test case. Doesn't need to be minimal.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...
Nov 06 2016
On Sunday, 6 November 2016 at 16:07:54 UTC, ag0aep6g wrote:On 11/06/2016 05:00 PM, Alex wrote: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 Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:Very weird. Would be great if you could provide a test case. Doesn't need to be minimal.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...
Nov 07 2016
On 11/07/2016 12:21 PM, Alex wrote:On Sunday, 6 November 2016 at 16:07:54 UTC, ag0aep6g wrote:[...]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.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.
Nov 07 2016
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-
ixin-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.
Nov 07 2016
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
Nov 07 2016
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 -gcKnowing 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...
Nov 07 2016
On 11/07/2016 06:18 PM, Alex wrote:On Monday, 7 November 2016 at 17:12:32 UTC, Alex 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#c5dmd -c -of./app.o -debug -g -gc -O -profile -w ./app.d -vcolumns dmd -of./app ./app.o -g -gcKnowing 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...
Nov 07 2016
Alex <sascha.orlov gmail.com>
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?
Nov 07 2016