Bug 6144 – Unexpected OPTLINK Termination at EIP=00428DA3

Status
RESOLVED
Resolution
FIXED
Severity
blocker
Priority
P2
Component
tools
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2011-06-10T11:35:00Z
Last change time
2017-01-10T01:43:17Z
Keywords
Optlink, pull
Assigned to
nobody
Creator
dsimcha
Blocks
9660

Comments

Comment #0 by dsimcha — 2011-06-10T11:35:14Z
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
(In reply to comment #4) > This is the disassembly of the offending function: > ... No disassembly any more! Now looks like this (with Optlink pulls #4+#5+#6): http://deoma-cmd.ru/files/other/images/Optlink-Issue%207139-in-Visual-Studio.png
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)?
Comment #15 by bugzilla — 2013-04-10T02:46:17Z
Comment #16 by bugzilla — 2013-04-10T02:55:43Z
You can pick up a binary with this fix for the moment at: http://ftp.digitalmars.com/optlink.zip