I'm working on my dumb library and I have run into a case where when I add this line to a module, I get an optlink error attempting to compile it:

    unittest{}

The module compiles fine without it. So do the modules which depend on it.

But with that line? optlink errors everywhere.

A screencap of the error box that pops up:

    http://puu.sh/tfmBK/c5068eb2fb.png

And the contents of stdout:

    checkpoint(256)
    --- errorlevel 1

I encountered a similar error right before this and eventually worked out that I had introduced a cyclic dependency into my project some time ago - strangely not rearing its head as an error until I made a completely unrelated addition to the tests in a module incidentally importing one of the modules involved in that dependency cycle - and addressing that issue seemed to resolve the optlink error. (At least until I tried to add some extra unit tests to one of the modules involved in that cycle.)

I am utterly failing to find a way to make a simple repro case from this, or to understand what could conceivably be causing this error to occur in a module whose dependency graph is small and simple.

On Sunday, 8 January 2017 at 14:15:26 UTC, pineapple wrote:
> I'm working on my dumb library and I have run into a case where when I add this line to a module, I get an optlink error attempting to compile it:
>
>     unittest{}

After deciding to let my inability to add some unit tests to that module I started working on some other code in the same project. At this point it seems completely arbitrary which lines produce optlink errors. Since the `unittest{}` issue I have, in other modules, had optlink errors occur depending on the presence of arbitrary method and function calls, too.

On Sunday, 8 January 2017 at 14:42:57 UTC, pineapple wrote:
> After deciding to let my inability to add some unit tests to that module I started working on some other code in the same project. At this point it seems completely arbitrary which lines produce optlink errors. Since the `unittest{}` issue I have, in other modules, had optlink errors occur depending on the presence of arbitrary method and function calls, too.

Update from IRC: Stefan was able to determine that this is a stack corruption bug with optlink. (How and why I should be the one to stumble upon it is yet to be determined.)

On Sunday, 8 January 2017 at 17:14:13 UTC, pineapple wrote:
> On Sunday, 8 January 2017 at 14:42:57 UTC, pineapple wrote:
>> After deciding to let my inability to add some unit tests to that module I started working on some other code in the same project. At this point it seems completely arbitrary which lines produce optlink errors. Since the `unittest{}` issue I have, in other modules, had optlink errors occur depending on the presence of arbitrary method and function calls, too.
>
> Update from IRC: Stefan was able to determine that this is a stack corruption bug with optlink. (How and why I should be the one to stumble upon it is yet to be determined.)

No I was not.
I think! it could be one.
I'll post it when there is something concrete to post.

On Sunday, 8 January 2017 at 17:14:13 UTC, pineapple wrote:
> On Sunday, 8 January 2017 at 14:42:57 UTC, pineapple wrote:
>> After deciding to let my inability to add some unit tests to that module I started working on some other code in the same project. At this point it seems completely arbitrary which lines produce optlink errors. Since the `unittest{}` issue I have, in other modules, had optlink errors occur depending on the presence of arbitrary method and function calls, too.
>
> Update from IRC: Stefan was able to determine that this is a stack corruption bug with optlink. (How and why I should be the one to stumble upon it is yet to be determined.)

No I was able to determine it not.
I think, it could be one.
I'll post it when there is something concrete to post.

On 1/8/2017 6:15 AM, pineapple wrote:
> I'm working on my dumb library and I have run into a case where when I add this
> line to a module, I get an optlink error attempting to compile it:
>
>     unittest{}
>
> The module compiles fine without it. So do the modules which depend on it.
>
> But with that line? optlink errors everywhere.
>
> A screencap of the error box that pops up:
>
>     http://puu.sh/tfmBK/c5068eb2fb.png
>
> And the contents of stdout:
>
>     checkpoint(256)
>     --- errorlevel 1
>
> I encountered a similar error right before this and eventually worked out that I
> had introduced a cyclic dependency into my project some time ago - strangely not
> rearing its head as an error until I made a completely unrelated addition to the
> tests in a module incidentally importing one of the modules involved in that
> dependency cycle - and addressing that issue seemed to resolve the optlink
> error. (At least until I tried to add some extra unit tests to one of the
> modules involved in that cycle.)
>
> I am utterly failing to find a way to make a simple repro case from this, or to
> understand what could conceivably be causing this error to occur in a module
> whose dependency graph is small and simple.
>

Please post bug reports to bugzilla. I transcribed the error here:

EAX=00000010
EBX=0000001C
ECX=00000000
EDX=004337CF
ESI=0044AAE8
EDI=00000100
EBP=0018FF54
ESP=0018FDEC
EIP=0040347E
First=00402000

Try to include the code that causes the problem.

The way to debug this (for anyone interested) is to get it to fail running under windbg.exe. Then examine the instructions around where it failed. Look in the source code to find where those instructions are, and hence the location in the code where it faulted.

P.S. Isn't it maddening that Windows doesn't allow copying the data from a message window?

On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
> On 1/8/2017 6:15 AM, pineapple wrote:
>> I'm working on my dumb library and I have run into a case where when I add this
>> line to a module, I get an optlink error attempting to compile it:
>>
>>     unittest{}
>>
>> The module compiles fine without it. So do the modules which depend on it.
>>
>> But with that line? optlink errors everywhere.
>>
>> A screencap of the error box that pops up:
>>
>>     http://puu.sh/tfmBK/c5068eb2fb.png
>>
>> And the contents of stdout:
>>
>>     checkpoint(256)
>>     --- errorlevel 1
>>
>> I encountered a similar error right before this and eventually worked out that I
>> had introduced a cyclic dependency into my project some time ago - strangely not
>> rearing its head as an error until I made a completely unrelated addition to the
>> tests in a module incidentally importing one of the modules involved in that
>> dependency cycle - and addressing that issue seemed to resolve the optlink
>> error. (At least until I tried to add some extra unit tests to one of the
>> modules involved in that cycle.)
>>
>> I am utterly failing to find a way to make a simple repro case from this, or to
>> understand what could conceivably be causing this error to occur in a module
>> whose dependency graph is small and simple.
>>
>
> Please post bug reports to bugzilla. I transcribed the error here:
>
> EAX=00000010
> EBX=0000001C
> ECX=00000000
> EDX=004337CF
> ESI=0044AAE8
> EDI=00000100
> EBP=0018FF54
> ESP=0018FDEC
> EIP=0040347E
> First=00402000
>
> Try to include the code that causes the problem.
>
> The way to debug this (for anyone interested) is to get it to fail running under windbg.exe. Then examine the instructions around where it failed. Look in the source code to find where those instructions are, and hence the location in the code where it faulted.
>
> P.S. Isn't it maddening that Windows doesn't allow copying the data from a message window?

Any chance to get a debug build of optlink ?

On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
> P.S. Isn't it maddening that Windows doesn't allow copying the data from a message window?

Not really, because you can, Ctrl+C...

On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
> P.S. Isn't it maddening that Windows doesn't allow copying the data from a message window?

A bit more maddening that D is still trying to support optlink, a linker that hasn't seen a commit in 2 years when it is hardly bug free.

On Sunday, 8 January 2017 at 19:15:49 UTC, Jerry wrote:
> On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
>> P.S. Isn't it maddening that Windows doesn't allow copying the data from a message window?
>
> A bit more maddening that D is still trying to support optlink, a linker that hasn't seen a commit in 2 years when it is hardly bug free.

Your comment is not pertinent. The object format doesn't change so the linker doesn't need to be updated. The problem here seems to be a bug. Until someone finds it, it can't be fixed.