I've recently been chasing a bug that made it impossible to call one built-in stored procedure within SAP Adaptive Server Enterprise (ASE) .NET provider.
The procedure in question is sp_loginconfig which exists only on ASE running on Windows platforms. If you try to invoke it using the standard .NET pattern:
using System;
using Sybase.Data.AseClient;
using System.Data;
class Program
{
static void Main(string[] args)
{
AseConnection connection = new AseConnection("Server=localhost;Port=5000;User ID=...;Password=...;");
connection.Open();
DataTable table = new DataTable();
IDbCommand command = connection.CreateCommand();
command.CommandType = CommandType.Text;
command.CommandText = "sp_loginconfig 'login mode'";
// Will throw NullReferenceException
table.Load(command.ExecuteReader());
connection.Close();
}
}
It throws the "Object reference not set to an instance of an object" exception using SAP ASE .NET provider (16.0.1.1).
Here's the stack trace for this exception:
at Sybase.Data.AseClient.AseDataReader.Perform_RetrieveHasNextRow()
at Sybase.Data.AseClient.AseDataReader.Perform_Skip_Next()
at Sybase.Data.AseClient.AseDataReader.RetrieveNextResult()
at Sybase.Data.AseClient.AseDataReader.GetNextResult(Boolean isNeedProcessOutParams)
at Sybase.Data.AseClient.AseDataReader.NextResult()
at System.Data.ProviderBase.DataReaderContainer.NextResult()
at System.Data.Common.DataAdapter.FillNextResult(DataReaderContainer dataReader)
at System.Data.Common.DataAdapter.Fill(DataTable[] dataTables, IDataReader dataReader, Int32 startRecord, Int32 maxRecords)
at System.Data.Common.LoadAdapter.FillFromReader(DataTable[] dataTables, IDataReader dataReader, Int32 startRecord, Int32 maxRecords)
at System.Data.DataTable.Load(IDataReader reader, LoadOption loadOption, FillErrorEventHandler errorHandler)
at System.Data.DataTable.Load(IDataReader reader)
at Program.Main(String[] args) in c:\Users\martin\Documents\Visual Studio 2013\Projects\NRE\Program.cs:line 19
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Firing up Visual Studio 2013 with the .NET Reflector extension and enabling debugging for the Sybase.AdoNet45.AseClient assembly allows us to land on the specific line of code causing the problem:
private bool Perform_RetrieveHasNextRow()
...
if (this._currentRowManager.GetRowType() == TdsTypesDefines.TDS_ALTFMT)
...
And here we find this._currentRowManager == null which causes the NullReferenceException.
So where is _currentRowManager initialized? Looking through the code generated from the Sybase.AdoNet45.AseClient assembly by Reflector we find this place:
private void SetupMetaData(byte rmtType)
{
if (rmtType == 0x61)
{
this._rowManager = new RowManager(this._inputStream, rmtType, this._command._connection._useAseDecimal);
this._rowManager.Read();
this._numOfRowsFetched = 0;
this._numOfTdsCols = this._rowManager.GetNumOfTdsCols();
this._numOfCols = this._rowManager.GetNumCols();
this._fieldCount = this._numOfCols;
this._readibleColInx = this._rowManager.GetVisibleColInxes();
this._hasNextRow = true;
this._isOnData = false;
this._currentRowManager = this._rowManager;
this.Perform_InitHasNextRow();
}
The _currentRowManager will be initialized only when rmtType is in (0x61, 0xd3, 0xd1). Setting a breakpoint on SetupMetaData reveals the offending rmtType value: 0xee.
So where from does the rmtType come from? Let's examine the response packet received from the server:
13 88 CF EC 25 E1 8B E3 83 DE CC EB 50 18 F6 8D 7E 52 00 00 04 01 00 75 00 00
00 00 FF 41 00 02 00 00 00 00 00 EE 23 00 02 00 04 6E 61 6D 65 00 00 00 00 00
27 14 00 0B 63 6F 6E 66 69 67 5F 69 74 65 6D 00 00 00 00 00 27 14 00 D1 0A 6C
6F 67 69 6E 20 6D 6F 64 65 08 73 74 61 6E 64 61 72 64 FF 41 00 02 00 00 00 00
00 FF 41 00 02 00 00 00 00 00 FF 51 00 02 00 01 00 00 00 79 00 00 00 00 FE 08
00 02 00 01 00 00 00
.?Ii%a?a??IeP.o?~R.....u....yA.......i#....name.....'...config_item.....'..N.login mode.standardyA.......yA.......yQ.......y....?........
Using the Ribo utility we can decode TDS packets.
For the packet, above Ribo produces:
...
ROWFMT Token (0xEE);
Length [2]: 35
Number of Columns [2]: 2
Column 1
Name Length [1]: 4
Name [4]: "name"
Status [1]: <unrecognized> (0x00)
User Type [4]: 0
Data Type [1]: VARCHAR
Length [1]: 20
Locale Length [1]: 0
Column 2
Name Length [1]: 11
Name [11]: "config_item"
Status [1]: <unrecognized> (0x00)
User Type [4]: 0
Data Type [1]: VARCHAR
Length [1]: 20
Locale Length [1]: 0
...
SetupMetaData skips the _currentRowManager variable initialization because there is simply no code path for rmtType == 0xee.
Trustwave reported this to SAP and eventually this issue was acknowledged as a bug in the .NET provider.
