Home Dashboard Directory Help
Search

Application of custom attribute crashes VS 2008 (VB) still with SP1 applied by Carlos J. Quintero


Status: 

Closed
 as Won't Fix Help for as Won't Fix


1
0
Sign in
to vote
Type: Bug
ID: 368580
Opened: 9/19/2008 12:30:21 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

This is a reopen bug of FeedbackID=322131:

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=322131

The page "List of changes and fixed issues in Visual Studio 2008 Service Pack 1" (http://support.microsoft.com/kb/950263/) states that the bug was fixed in VB.NET 2008 SP1 but the bug is not totally fixed, the crash still happens in some circumstances with custom attributes.
Details
Sign in to post a comment.
Posted by Microsoft on 7/22/2009 at 6:15 PM
Hey Carlos,

Just want to give you an update on this bug. Unfortunately we won't be able to fix this until VB11 at the earliest as it involves an architectural change. Having said that, there's some simple changes you can make to your project that will prevent this from happening.

The issue appears to happen under the following circumstances:

1) There's an enum with a large number of members
2) At least one of the members of the enumeration is given a fixed initializer
3) A member of the enumeration which has a sufficiently large offset from one with a fixed initializer is being passed as an argument to an attribute.


Possible workarounds or ways to avoid the problem:

1) Move the enum to a separate project
2) Remove all the initializers from the enumeration (that is, any entry like "Foo = 0" or "Bar = Foo + 1")
3) Intersperse additional fixed initializers to reduce the amount of recursion. For example:

Public Enum MyEnum

    Value0000 = 0

    '[...]

    Value0200

    Value0201 = 201 ' Add these hardcoded values every ~200 members

    '[...]

    Value0400

End Enum

Hope that helps!

Jonathan
Posted by Microsoft on 7/2/2009 at 10:26 AM
Hey Carlos, where did you upload the file? We don't see it attached to the bug. Could you please email it to me at jonaneja@microsoft.com?

Thanks!

Jonathan
Posted by Carlos J. Quintero on 7/2/2009 at 2:27 AM
I have uploaded a crash.txt file per your instructions.

Let me know if you can trace down the problem now or if you need more information

Carlos
Posted by Microsoft on 7/1/2009 at 12:58 PM
Hey Carlos,

One of our engineers examined the dump file that you provided us, and unfortunately there's a problem in our exception-handling system which means we have insufficient information in the dump file to diagnose this. Visual Studio 2010 Beta1 has the same exception problem (though it'll be fixed for Beta2), so the best thing to do would be to use WinDbg to grab the callstack:

- Attach WinDbg to devenv.exe and attempt a first-chance trap of the exception. Here are the steps involved:

1) Start Visual Studio and load the project that is known to exhibit the problem.
2) Start windbg.exe.
3) From within WinDbg, "File | Attach to a Process" and select devenv.exe. Wait for the debugger to attach.
4) In the debugger, enter the command "sxe c00000fd" to trap the exception that was reported by the crash.
5) Then enter the command "g" to resume execution of Visual Studio.
6) The next time the problem occurs, you should be dumped into WinDbg with a message like the following:
(1a98.166c): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=305ef1aa ebx=00000000 ecx=000331c0 edx=000003f1 esi=00000000 edi=00000000
eip=0040215e esp=00032ef4 ebp=0003316c iopl=0         nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00010206
7) At this point, enter the command "kvf" to show the last twenty frames on the stack along with the frame size and arguments

This should give us the extra information we need to track down the problem.

Please let us know if you'll be able to provide such a callstack (or a repro project). If not unfortunately we'll have to resolve it as "Not Repro".

Thanks,

Jonathan
Posted by Microsoft on 1/30/2009 at 8:09 PM
Carlos

We are re-examining any crashing issues that are still unresolved. We have some tools which we would like for you to run on you machine to assist us in locating the cause of the problem. Please contact me at abowles@Microsoft.Com for further information.

Thanks

Spotty Bowles
SDET, VB Team
Posted by Carlos J. Quintero on 10/8/2008 at 2:00 AM
Hello Jonathan,

I agree that it would be great to have a reproducible case and I realize that you are not going to examine the whole huge code base of the VB compiler line by line, but:

1) You have the crash report in your server (September 19, 2008, 9:00 GMT+1 approx). That is a proof that the crash exists and should be enough to give you information to understand the problem, even without a repro case. Otherwise, what would be purpose of those crash reports?

2) Incidently, the VB 2008 SP1 claims that it fixed this problem while I think it didn't fix it completely. So, rather than examining the whole code of the VB compiler, it should be easy to use the source code control provider that you use to get the checked-in changeset that fixed that problem and examine those few lines of code to guess if there could be some other cases where the VB compiler would crash yet.

I will try to isolate the problem, but it is difficult because the problem seems to be intermitent (due to the nature of backgound compilation, I think) and my solution is huge, but could you start locating and examining the crash report of point #1?
Posted by Microsoft on 10/7/2008 at 2:14 PM
Hey Carlos,

Thanks for taking the time to submit this issue.

"But hopefully with those clues you could examine the code of your VB 2008 compiler before the SP1, how you fixed it in SP1 to avoid the crash using attributes like..."

Unfortunately the code base for the VB compiler is extremely large and complex, and we just don't have enough information here to start going through it line-by-line here. I'm going to resolve this issue as "No Repro" for now, but if you do find a set of steps that produces a consistent repro we'd be happy to look at this again. If you have a repro please email me directly at jonathan DOT aneja AT microsoft DOT com.

Thanks,

Jonathan Aneja
Program Manager, VB Team
Posted by Microsoft on 9/21/2008 at 11:58 PM
Thanks for your feedback. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Sign in to post a workaround.