Wizard_01

Hi everyone,

I am very confused why ISymUnmanagedDocument.FindClosedLine is not working as expected for a nested class. See a sample code below. Calling FindClosedLine with argument of 13 returns 14 (expected value). But calling this function with 8 (a method in the nested class) returns 14 !!! Why Is it correct solution to use this function Or is better to make my own search based on sequence points (We are using .NET 1.1).

Thanks.


Code Block
1 using System;

2

3 class parentClass {

4

5 // nested class

6 class x{
7 void a() {
8 Console.WriteLine("hello");
9 }
10 }
11
12 void xxx () {

13

14 Console.WriteLine("hello");
15 }

16 }



Re: Building Development and Diagnostic Tools for .Net Bug in ISymUnmanagedDocument.FindClosestLine for nested class?

Rick Byers - MSFT

Hi,

I verified I can reproduce this problem using the symbol reader from .NET 1.1. I see that several bugs have been fixed in FindClosestLine in v2.0, and I verified that the problem goes away when using the v2.0 symbol reader (the version of the C# compiler used to compile the target is irrelevant - it also could have been a bug there, but apparently is not).

Can you confirm that v2.0 works properly for you If you're stuck using v1.1, then yes searching through the sequence points yourself is probably the best work-around.

I hope this helps,

Rick





Re: Building Development and Diagnostic Tools for .Net Bug in ISymUnmanagedDocument.FindClosestLine for nested class?

Wizard_01

This is for v1.1 Sad I cannot confirm the same bug in v.2.0. And about the work-around... ISymUnmanagedDocument.GetSource*** are only the 2 function in ISymUnmanagedDocument which look like that they work with sequence points. But how to get it Only the ISymUnmanagedMethod has the method GetSequencePoints().

Thankx, Libor.




Re: Building Development and Diagnostic Tools for .Net Bug in ISymUnmanagedDocument.FindClosestLine for nested class?

Rick Byers - MSFT

Hi Libor,

The best work-around I see at the moment is to use ISymUnmanagedReader.GetMethodFromDocumentPosition instead of ISymUnmanagedDocument.FindClosestLine. GetMethodFromDocumentPosition will return E_FAIL if there is no code on the specified line, but it ignores column information. So you can just loop trying the next larger line until you find one that succeeds (although there is some question about how to decide when you've walked off the end of the file - do you have access to the source file itself so you can see how many lines it has ).

Another larger-impact option would be to enumerate all methods an call ISymUnmanagedMethod.GetSequencePoints storing all the raw data in your own data structures. Then you could search it yourself in whatever way you wanted. Obviously the design of the symbol reader is supposed to prevent this from being necessary, so this is less than ideal.

By the way, if it helps I believe it should be possible to use the v2.0 diasymreader.dll (were this bug is fixed) without moving your entire application to v2.0.

I'm curious to understand a bit more about your scenario - is this for a debugging tool that only targets v1.1 I wonder how VS 2003 copes with this bug. I've e-mailed the owner of this code, perhaps he'll be able to provide some more insights.

Rick





Re: Building Development and Diagnostic Tools for .Net Bug in ISymUnmanagedDocument.FindClosestLine for nested class?

Wizard_01

It looks like as a nice idea to use diasymreader.dll but you cannot unless your are from Microsoft ("You cannot distribute any part of the product alone" - eula).

A little bit about your scenario. The tool for v1.1 is out and for v2.0 too. But many users use v1.1 because of their needs, other tools, components and so on ... Sad And the common answer is: why we should use v2.0 or v3.0 when we do not need it and v1.1 is still working

We will look on what you have written above about iterating all methods and testing SP. The tool do not know the length of the document - it has only pdb file. Another hack would be testing only 50+ lines and if it fails then say - ok, propably the end of the file. I wonder how VS hacks this bug. We have came across this scenario many times - something is working very well in VS but when you are trying to do the same yourself, never works.





Re: Building Development and Diagnostic Tools for .Net Bug in ISymUnmanagedDocument.FindClosestLine for nested class?

Rick Byers - MSFT

I'll see if I can find someone to tell us how VS is avoiding this problem. I wouldn't be surprised to find that they're relying on GetMethodFromDocumentPosition instead of FindClosestLine. I'm fairly sure they aren't doing anything sneaky like using internal interfaces (there are none that I know of) or using the DIA APIs (also publicly documented) to access the raw PDB data directly.

Rick





Re: Building Development and Diagnostic Tools for .Net Bug in ISymUnmanagedDocument.FindClosestLine for nested class?

Rick Byers - MSFT

Hi Libor,

I've spoken to the owner of the diasymreader code, and the VS code that uses it, and they confirm that VS 2003 avoids this problem using precisely the method I suggest - iterating over the lines using GetMethodFromDocumentPosition. This seems like a reasonable work-around, and also gives you more precise control over what you mean by "closest line" (eg. look in one direction, or both ).

Sorry for the trouble this bug has caused you. Let me know if there is anything else I can help you with.

Rick





Re: Building Development and Diagnostic Tools for .Net Bug in ISymUnmanagedDocument.FindClosestLine for nested class?

Wizard_01

Dear Rick,

When I wrote to this thread first time I did not expected I will get so exhausting response from "Microsoft". Thank you very much (I would invite you to the pub and buy you some beer unless I lived in Europe ). Next week we will implement your work-around. The only thing makes me nervous, what is the lastest line / method in a document.

Libor





Re: Building Development and Diagnostic Tools for .Net Bug in ISymUnmanagedDocument.FindClosestLine for nested class?

Rick Byers - MSFT

No problem, I'm glad it was helpful. On this forum we know that many of the APIs of interest are "rocket-science" APIs which aren't always well documented or widely used (unlike, say, the BCL APIs), and can be difficult to use without expert help.

I guess how you address the "last line" issue will come down to your usage scenarios. Eg., for the typical usage of setting a breakpoint in a debugger, if the nearest code is 100 lines away from where the user clicked, you probably don't want to consider that as a "closest" line anyway - better to just say that a breakpoint can't be placed there, then to "conveniently" place a breakpoint 3 pages down from where the user clicked :-)

Rick