Using the version of OPTLINK that comes with DMD 2.053.
This bug is only reproducible in the context of a fairly large program and I don't really understand what triggers it, but here's the register status in case that by some chance helps.
EIP=00428DA3
EAX=000002F8
EBX=00000433
ECX=0043F7B4
EDX=000002F8
ESI=02713D08
EDI=0043FBC1
EBP=0018FF04
ESP=0018FEF8
First=0040200 (Whatever First is, it showed up in the error message.)
Comment #1 by Jesse.K.Phillips+D — 2011-08-29T12:47:41Z
I'll add mine to it. I only get this when compiling with debug symbols enabled (-g -gc). This is with OPTLINK (R) for Win32 Release 8.00.12. I don't even know where to begin reducing my code.
EAX=00000C6C
EBX=00000D74
ECX=0043F7B4
EDX=00000C6C
ESI=01563394
EDI=0044055E
EBP=0012FF3C
ESP=0012FF30
First=00402000
Comment #2 by bugzilla — 2011-08-29T15:20:44Z
What you can do is try running it under windbg.exe. Open up an asm window on where it fails, and submit a copy of the assembler instructions before & after where it faults.
Comment #3 by Jesse.K.Phillips+D — 2011-08-30T09:02:36Z
Maybe I'm doing something wrong, but I just get a bunch of question marks from the source/asm view. I at least now know First refers to the First Chance Exception Windows throws. I'll throw some more data your way.
disassemly example:
0x00000000 ?? ???
Module Load: C:\OPT\DMD\WINDOWS\BIN\LINK.EXE (symbol loading deferred)
Thread Create: Process=0, Thread=0
Module Load: C:\windows\system32\NTDLL.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\KERNEL32.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\USER32.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\GDI32.DLL (symbol loading deferred)
Module Load: C:\windows\system32\NTDLL.DLL (no symbols loaded)
Module Load: C:\WINDOWS\SYSTEM32\IMM32.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\ADVAPI32.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\RPCRT4.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\SECUR32.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\WXVAULT.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\PSAPI.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\MPR.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\VERSION.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\SHLWAPI.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\MSVCRT.DLL (symbol loading deferred)
Module Load: APP01.EXE (symbol loading deferred)
Module Load: C:\WINDOWS\SYSTEM32\SHELL32.DLL (symbol loading deferred)
Module Load: C:\WINDOWS\WINSXS\X86_MICROSOFT.WINDOWS.COMMON-CONTROLS_6595B64144CCF1DF_6.0.2600.6028_X-WW_61E65202\COMCTL32.DLL
(symbol loading deferred)
Module Load: C:\WINDOWS\WINSXS\X86_MICROSOFT.WINDOWS.COMMON-CONTROLS_6595B64144CCF1DF_6.0.2600.6028_X-WW_61E65202\COMCTL32.DLL
(symbol loading deferred)
Module Load: C:\PROGRA~1\SOPHOS\SOPHOS~1\SOPHOS~1.DLL (symbol loading deferred)
Module Load: C:\OPT\DMD\WINDOWS\BIN\LINK.EXE (no symbols loaded)
First chance exception c0000005 (Unknown) occurred
Thread stopped.
> r
EAX=0012f884 EBX=0012f8c0 ECX=0000004c EDX=1001890c ESI=7ffddc00
EDI=00000104
EIP=00000000 ESP=0012f864 EBP=0012f89c EFL=00010212
CS=001b DS=0023 ES=0023 SS=0023 FS=003b GS=0000
> s+
> ln
No symbol found
> k
0012f860 10007967 0x00000000
0012f89c 1000637d 0x10007967
0012fadc 7c8138b7 0x1000637d
0012fd70 00428ed3 0x7c8138b7
0012fd94 00140000 0x00428ed3
7c94bafc 78b7ffff 0x00140000
fce8c5e9 00000000 0x78b7ffff
Module Load: C:\WINDOWS\SYSTEM32\WXVAULT.DLL (no symbols loaded)
Module Load: C:\WINDOWS\SYSTEM32\KERNEL32.DLL (no symbols loaded)
Comment #4 by sludwig — 2012-09-17T08:07:18Z
I'm also hit by this quite often. Changing random things will make it work or break it.
This is the disassembly of the offending function:
0x00428d82 c8040000 enter 0004,00
0x00428d86 53 push ebx
0x00428d87 56 push esi
0x00428d88 c745fc00000000 mov dword ptr [ebp-04],00000000
0x00428d8f 8b45fc mov eax,dword ptr [ebp-04]
0x00428d92 3b4510 cmp eax,dword ptr [ebp+10]
0x00428d95 7314 jae 00428dab
0x00428d97 8b4d0c mov ecx,dword ptr [ebp+0c]
0x00428d9a 8b55fc mov edx,dword ptr [ebp-04]
0x00428d9d 8a1c11 mov bl,byte ptr [edx+ecx]
0x00428da0 8b7508 mov esi,dword ptr [ebp+08]
0x00428da3 881c16 mov byte ptr [edx+esi],bl <<< Access Violation
0x00428da6 ff45fc inc dword ptr [ebp-04]
0x00428da9 ebe4 jmp 00428d8f
0x00428dab 8b4508 mov eax,dword ptr [ebp+08]
0x00428dae 5e pop esi
0x00428daf 5b pop ebx
0x00428db0 c9 leave
0x00428db1 c3 retn
ESI contains 0x028a3cd0 and EDX contains 0x330.
A couple of bytes after [ESI] there comes a very long mangled string:
D921TypeInfo_S4vibe5templ4diet295__T19parseDietFileCompatVAyaa11_73686f775f626f782e6474TC4vibe4http6server17HttpServerRequestVAyaa3_726571TPS5index8show_boxFC4vibe4http6server17HttpServerRequestC4vibe4http6server18HttpServerResponseAyaZv11ShowBoxInfoVAyaa4_696e666fTC8moneybox3api11MoneyBoxApiVAyaa3_617069TAyaVAyaa5_6572726f72Z19parseDietFileCompatFC4vibe6stream6stream12OutputStreamAS3std7variant17__T8VariantNVk20Z8VariantNXv480__T12FilterResultS4284vibe5templ4diet295__T19parseDietFileCompatVAyaa11_73686f775f626f782e6474TC4vibe4http6server17HttpServerRequestVAyaa3_726571TPS5index8show_boxFC4vibe4http6server17HttpServerRequestC4vibe4http6server18HttpServerResponseAyaZv11ShowBoxInfoVAyaa4_696e666fTC8moneybox3api11MoneyBoxApiVAyaa3_617069TAyaVAyaa5_6572726f72Z19parseDietFileCompatFC4vibe6strea
The string is terminated with the end of the memory page, after which there is no more mapped memory. Looks like a simple buffer overrun.
Comment #5 by verylonglogin.reg — 2013-02-06T03:49:36Z
*** Issue 7139 has been marked as a duplicate of this issue. ***
Comment #6 by verylonglogin.reg — 2013-02-06T03:50:49Z
There is a (valid, I just checked) testcase attached to Issue 7139.
Comment #7 by verylonglogin.reg — 2013-02-06T03:53:04Z
*** Issue 8222 has been marked as a duplicate of this issue. ***
Comment #8 by verylonglogin.reg — 2013-02-06T04:03:01Z
Once can also read Issue 8222 discussion.
P.S.
I decided to make one closed source app in D and was really punished by this bug. How one can develop application without debugging? The worst thing is that everything is good until you program grows in size and approximately after a month of development, when you really need step-by-step debugging, you can't enable debug info any more. So you are totally f***ed...
How can D be called "stable" in any way having such an inexcusable issues in its toolchain? I'm a D fan but it is really meanly not to mention about such things on main dlang.org page.
P.P.S.
Walter has no excuse here as there is a tastcase from David Simcha (attached to Issue 7139) for more than a year (from 2011-12-20)...
Comment #9 by verylonglogin.reg — 2013-02-21T23:17:18Z
A possible workaround to enable debug information (which may or may not help) is to separate part of the project into a library.
Note that this may trigger other link failures which may or may not be easy to workaround (see Issue 9567 e.g.).
Comment #10 by verylonglogin.reg — 2013-03-07T04:11:43Z
Filled meta issue 9660 about debugging problem caused by this issue.
Comment #11 by verylonglogin.reg — 2013-03-21T03:21:04Z
Comment #12 by verylonglogin.reg — 2013-04-02T05:02:38Z
I do not understand anything in OPTLINK sources, but:
Addition of `_flush_cvg_temp` in `_output_cv_symbol_align` before failing `memcpy` call does detrigger Access Violation in OPTLINK (just like for Issue 2436, see `_output_cv_symbol_align` source code).
So here we are:
https://github.com/DigitalMars/optlink/pull/8
Note: produced executable from test case from David Simcha's Issue 7139 will link but fail to launch complaining "This is not Win32 executable" as it contains unresolved symbols.
Comment #13 by bugzilla — 2013-04-02T10:54:56Z
Is the seg fault on the read of the source, or the write of the destination? And what is the value of the source/destination (i.e. is it obviously not a valid pointer)?
Comment #14 by verylonglogin.reg — 2013-04-02T23:40:23Z
(In reply to comment #13)
> Is the seg fault on the read of the source, or the write of the destination?
> And what is the value of the source/destination (i.e. is it obviously not a
> valid pointer)?
On the write of the destination of course, just like Issue 2436 or how otherwise flushing CVG temp could solve this?. I also don't understand, why you can't just launch David Simcha's testcase in Visual Studio and see all info with step-by-step debugging yourself (the pull for easy debugging using VS (#6) is here for already two weeks without any attention)?