Wrong line numbers in stack traces

philb1212

We just purchased SmartAssembly and it's performing well. However, we noticed an issue where a source line number is wrong in stack traces. An example is below. It reports a line number is 16777215, which is very wrong.

System.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
at XX.XX.XX.DBConnector.#zvc(dbLibrary #DNd, String #YNd, String #ZNd, String #0Nd, String #1Nd) in e:\xx\DBConnector.cs:line 16777215 at XX.XX.XX.DbHelper.GetControlDBConnector(String serverName, SQL_AUTHENTICATION_ORDER authType) in e:\xx\DbHelper.cs:line 937
at XX.XX.XX.LoginControl.#gAe(String #Eb, SQL_AUTHENTICATION_ORDER #hAe) in e:\xx\Login.cs:line 295
at XX.LoginControl.#rAe(sqlServer #ONd) in e:\xx\Login.cs:line 790

Code optimization was turned off for this project (and PDB generation was on) so I'd expect it to be correct. Decoding the stack trace works fine, BTW, except the line number is still wrong. Are there any known cases where this can happen?

Thanks in advance for your help.

James B

Hi Phil.

The most common cause of line numbers being incorrect is if you ticked the "Improve Performance" option under error-reporting. This normally only puts them out by one or two though.
I'm guessing this isn't the case for you, and the number you're getting is actually FFFFFF in hex, suggesting it's hitting some maximum value internally perhaps?
What should the line number in question actually be?

Also, have you tried it without getting Smartassembly to generate a PDB, as I've found an internal bug (ref. SA-1047) where we sometimes end up with a line number the same as you're seeing.

philb1212

The actual line number is 764, which is correctly reported in the stack trace in the original, unobfuscated build. It happens to be an exception that is thrown inside a method called from a constructor, in case that rings any bells. Another matter that may be of interest is that the frame where the c'tor is called isn't included in the stack trace at all except when the debugger is attached.

I'll see what happens with SmartAssembly's PDB generation turned off.

James B

Thanks Phil - if you're able to supply the offending assembly and your project to us for testing, that would be really useful, thanks!

philb1212

I'm unable to provide the project for IP reasons, but I tested with SmartAssembly's PDB generation off, and the stack trace is the same but without line numbers, which makes sense really.

I'm guessing you could repro this by trying to create an instance of a class that throws an exception inside a method called by its constructor. That is, have some code create an instance of ClassA whose c'tor calls some method on ClassA, which throws an exception in that method.

James B

I tried to repro this with the below, but the line numbers seemed correct for me unfortunately; so it looks like it's maybe something more specific to your own code (unless I did it wrong... )

public class Class1
    {
        public Class1()
        {
            DoErrorThings();
        }

        private void DoErrorThings()
        {
            int i = 0;
            int j = 10;
            int k = j/i;
        }
    }

Creating an instance of the above from a separate .exe that creates an instance of Class1 on a buttonclick triggers the SA error box, but the resulting report looks correct.

If you're able to supply something that demonstrates it without any of your "real" code, then I can pass it over to our dev-team for analysis though.

edevis

Hello,

I am currently having the same issue using version 6.8.0.117. Line numbers sometimes seem to be incorrect by one or more lines. I have created a little repo that illustrates the problem:

Download

Use build config 'Release_Obfuscated' which automatically creates the obfuscated assembly using the supplied .saproj file.

What I have found out is that setting 'Control Flow Obfuscated' level changes the returned line numbers. I dont know if all levels should support the decoding, but I found no statement telling me otherwise.

danypd69

Hello edevis
Did you find the cause of the problem? I have the same problem in some cases and I cannot find a way to fix it.

Woreavelesor

Hi
I am having the same error!

manlyboy

Using Version 6.11.4.33
This has become a major headache for me as well.
Can we get some update on this now longstanding issue.