Search

fatal error LNK1000: Internal error during IMAGE::BuildImage-- for large projects with nested exceptions by JJ Cox

Closed
as Fixed Help for as Fixed

1
0
Sign in
to vote
Type: Bug
ID: 101287
Opened: 7/19/2005 5:18:22 PM
Access Restriction: Public
1
Workaround(s)
0
User(s) can reproduce this bug
As part of a large driver, I have some code that was written 5+ years ago that uses nested SEH. This code builds fine in MSVC 6 & 7.1 targeting x86. When using VC 8 targeting AMD64, our debug build is fine (tested/working), but we experience a crash when linking the release driver. The code looks roughly like:
==
__try
{
     //OS Call
}

__except( EXCEPTION_EXECUTE_HANDLER )
{
     __try
     {
         //OS_call(different parameters)
     }

     __except( EXCEPTION_EXECUTE_HANDLER )
     {
         //review parameters, cleanup, unwind
     }
}
==

Workaround: If we move the nested try/except block to another function, the crash goes away.

"
Finished pass 1

Generating code
xxxx.cpp(1109) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\beta2\vctools\compiler\utc\src\P2\main.c[0x10B080F6:0x0000004F]', line 183)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information

LINK : fatal error LNK1000: Internal error during IMAGE::BuildImage

Version 8.00.50215.44

ExceptionCode            = C0000005
ExceptionFlags         = 00000000
ExceptionAddress         = 10B080F6 (10B00000) "d:\msvc80\VC\BIN\x86_amd64\c2.dll"
NumberParameters         = 00000002
ExceptionInformation[ 0] = 00000000
ExceptionInformation[ 1] = 0000004F

CONTEXT:
Eax    = 00000000 Esp    = 0012EDCC
Ebx    = 00000000 Ebp    = 0012EDF8
Ecx    = 00000000 Esi    = 00000000
Edx    = 073E6C00 Edi    = 00000000
Eip    = 10B080F6 EFlags = 00010202
SegCs = 00000023 SegDs = 0000002B
SegSs = 0000002B SegEs = 0000002B
SegFs = 00000053 SegGs = 0000002B
Dr0    = 00000000 Dr3    = 00000000
Dr1    = 00000000 Dr6    = 00000000
Dr2    = 00000000 Dr7    = 00000000
"
Details (expand)
Product Language
English
Version
Visual Studio 2005 Beta 2
Category
Linker
Operating System
Windows XP Professional
Operating System Language
English
Steps to Reproduce
See the attachment, I built it using link /repro:. It has the command-line in there...
Actual Results
Here's the same from the native compiler (depending on your preference):
"
xxxxx.cpp(1109) : fatal error C1001: An internal error has occurred in the
compiler.
(compiler file
'f:\beta2\vctools\compiler\utc\src\P2\main.c[0x0000000010C4B254:0x0000000000000078]', line 183)
To work around this problem, try simplifying or changing the program near
the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information

LINK : fatal error LNK1000: Internal error during IMAGE::BuildImage

Version 8.00.50215.44

ExceptionCode = C0000005
ExceptionFlags = 00000000
ExceptionAddress = 0000000010C4B254 (0000000010C40000)
"D:\msvc80\VC\BIN\amd64\c2.dll"
NumberParameters = 00000002
ExceptionInformation[ 0] = 0000000000000000
ExceptionInformation[ 1] = 0000000000000078

CONTEXT:
Rax = 0000000000000000 R8 = 00000000FFFE94F2
Rbx = 0000000007210000 R9 = 0000000000000000
Rcx = 0000000000000000 R10 = 726464416D654D74
Rdx = 0000000000000000 R11 = 0000000000000D4C
Rsp = 000000000023E1B0 R12 = 0000000007245960
Rbp = 0000000007248106 E13 = 00000000072481C8
Rsi = 0000000006871900 R14 = 0000000000000000
Rdi = 00000000071FBBE8 R15 = FFFFFFFFFFFFFFFF
Rip = 0000000010C4B254 EFlags = 0000000000010202
SegCs = 0000000000000033 SegDs = 000000000000002B
SegSs = 000000000000002B SegEs = 000000000000002B
SegFs = 0000000000000053 SegGs = 000000000000002B
Dr0 = 0000000000000000 Dr3 = 0000000000000000
Dr1 = 0000000000000000 Dr6 = 0000000000000000
Dr2 = 0000000000000000 Dr7 = 0000000000000000
"

Expected Results
Successful linking with no crash?
File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 8/6/2005 at 3:02 PM
A possible workaround for this issue was suggested by the customer: extract the inner __try-__except construct and place it in a separate function. Another option is to disable optimization of the function.
Posted by Microsoft on 8/5/2005 at 3:18 PM
The Microsoft Sub-status is now "Working on solution"
Posted by Microsoft on 8/2/2005 at 4:14 PM
A possible workaround for this issue was suggested by the customer: extract the inner __try-__except construct and place it in a separate function. Another option is to disable optimization of the function.
Posted by Microsoft on 8/2/2005 at 11:18 AM
The Microsoft Sub-status is now "Working on solution"
Posted by Microsoft on 8/2/2005 at 11:10 AM
The Microsoft Sub-status is now "Working on solution"
Posted by Microsoft on 8/1/2005 at 2:23 PM
The Microsoft Sub-status is now "Working on solution"
Posted by JJ Cox on 7/28/2005 at 4:33 PM
Please see fdbk32859.zip below for link repro output (btw, your email gateway has a pretty small limit on email sizes...).
Posted by Microsoft on 7/28/2005 at 1:33 PM
Dear JJ,

What you have attached in linkros.zip is a big .dmp file which is what I used to determine the exact call stack when the AV happened. This is a good start for the investigation, but not enough to isolate and fix the bug. In order to fix the bug, we need some way of building the same project you are building. If you compiled just /Od, /O1 or /O2 you would just throw /P switch to the compiler and then it would generate preprocessed files that we can use to repro the bug. However, since you used link-time-codegen, aka. whole program optimization (/GL switch for compiler and /LTCG for linker), we can do one better than /P. You can specify /linkrepro:<empty_dir> switch to the linker and linker will dump all object and lib files necessery to repro the bug to <empty_dir>. You would then zip this file and send it to us. You can also verify that /linkrepro created the right binaries later by running link @link.rsp from <empty_dir> directory (that should also repro your problem). We wouldn't need your source code at all and we would still be able to fix the problem. Can you please do this and attach it to the bug entry?

Thanks in advance,

Marko Radmilac
VC++ Compiler Developer

P.S. If you'd rather send it to me directly, or if you have any other questions, contact me at mradmila@microsoft.com.
Posted by JJ Cox on 7/28/2005 at 7:38 AM
Scroll down and see linkcros.zip attached below (built using link /repro). I also have user mode memory dumps, but they are too big to attach (50meg or so).
Posted by Microsoft on 7/26/2005 at 2:55 PM
Unfortunately, we are unable to fix the problem until we have a full repro case. Please reactivate this issue once you attached the link repro.
Posted by Microsoft on 7/21/2005 at 10:07 AM
The Microsoft Sub-status is now "Working on solution"
Posted by Microsoft on 7/20/2005 at 4:43 PM
Thank you for reporting this issue; however, while we can determine which function the AV happened, we cannot recreate the exact conditions with memory dump you provided. We need a link repro case, a collection of objects that, when linked, will reproduce the problem. The way to create such repro is by adding /linkrepro:<some_empty_directory> to the link command (usually by setting _link_=/linkrepro:<dir>). With that we will be able to track down the problem and fix it.
Sign in to post a workaround.
Posted by JJ Cox on 7/19/2005 at 5:22 PM
Move the nested exception into another function.

Write a helper function that contains the nested exception handler, call this function from the parent exception handler.
Tested/works.