Wrong line numbers in stack traces

.NET obfuscator and automated error reporting

Moderators: Luke Jefferson, melvyn.harbour, dom.smith

Wrong line numbers in stack traces

Postby philb1212 » Mon Nov 05, 2012 10:06 pm

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.
-Phil
philb1212
 
Posts: 3
Joined: Mon Nov 05, 2012 9:27 pm

Postby james.billings » Wed Nov 07, 2012 1:39 pm

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.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby philb1212 » Wed Nov 07, 2012 8:20 pm

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.
-Phil
philb1212
 
Posts: 3
Joined: Mon Nov 05, 2012 9:27 pm

Postby james.billings » Wed Nov 07, 2012 8:21 pm

Thanks Phil - if you're able to supply the offending assembly and your project to us for testing, that would be really useful, thanks!
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby philb1212 » Wed Nov 07, 2012 9:21 pm

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.
-Phil
philb1212
 
Posts: 3
Joined: Mon Nov 05, 2012 9:27 pm

Postby james.billings » Wed Nov 14, 2012 3:34 pm

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... :) )

Code: Select all
 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.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby edevis » Tue May 21, 2013 3:56 pm

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.
edevis
 
Posts: 1
Joined: Tue May 21, 2013 3:44 pm

Postby danypd69 » Sat Feb 22, 2014 5:42 pm

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.
danypd69
 
Posts: 3
Joined: Sat Feb 22, 2014 5:41 pm

Postby Woreavelesor » Tue Apr 01, 2014 11:18 am

Hi
I am having the same error! :(
Woreavelesor
 
Posts: 1
Joined: Tue Apr 01, 2014 11:11 am


Return to SmartAssembly 6

Who is online

Users browsing this forum: No registered users and 0 guests

cron