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.
_________________
-Phil

[james.billings]

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.
_________________
-Phil

[james.billings]

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.
_________________
-Phil

[james.billings]

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