Bogus dwNeededSize returned by lineGetDevCaps

[mihaicodrean]

Hi,

I'm having this problem that lineGetDevCaps returns random values in dwNeededSize (e.g. 0, ~2MB, ~4MB etc.). I'm using version "10.5".

Here's what I'm doing:

DWORD size = sizeof(LINEDEVCAPS);

while (true)

{

     if (_deviceCapabilities != 0)

          delete _deviceCapabilities;

     _deviceCapabilities = (LPLINEDEVCAPS) new char[size];

     memset(_deviceCapabilities, 0, size);

     _deviceCapabilities->dwTotalSize = size;

     LONG result;

     result = ::lineGetDevCaps(_tapi, _index, _tapiVersion, _providerSpecificExtensionVersion, _deviceCapabilities);

     if (result == LINEERR_STRUCTURETOOSMALL ||

          result == 0 && _deviceCapabilities->dwNeededSize > size)

     {

          size = _deviceCapabilities->dwNeededSize; // <--------- here, dwNeededSize has random values

          continue;

     }

     if (result == 0)

          break;

     return false;

}

return true;

Any ideas on what I might be doing wrong? Is this perhaps a bug in TSP?

Thanks in advance,

-Mihai

[smupadhy]

Hi,

This appears to be a case where a proper error is not returned to application when buffer size is not big enough - most probably a bug. We are reviewing CiscoTSP behavior in that area (size calculations, error return, TAPI error mapping, etc).

Can you provide us the specific parameter values that were used in the lineGetDevCaps() calls and corresponding TSP logs from your test?

[smupadhy]

We reviewed the TSP code that deals with this and it seems to function as per design - it does not report any fake dwNeededSize. If you are still seeing the odd behavior and require assistance, please attach the sanitized logs from your test.

[mihaicodrean]

Hi Smita,

Yes, the issue is still there. Taking a closer look at it, the problem seems to be that the dwNeededSize is not being filled in by the TSP on the first call, and thus remains zero. Side effect: the code above then tries to allocate for "zero" space, resulting in dwNeededSize pointing to unallocated memory, thus the random values.

But the real question is why is the dwNeededSize not being filled in, remaining zero?

If I code defensively, and handle the case where dwNeededSize is zero, and simply allocate more memory instead, then eventually the call to lineGetDevCaps will succeed:

• dwTotalSize = sizeof(LINEDEVCAPS) + sizeof(Cisco_LineDevCaps_Ext) = 464; lineGetDevCaps returns dwNeededSize = 0, with LINEERR_STRUCTURETOOSMALL
• dwTotalSize = sizeof(LINEDEVCAPS) + sizeof(Cisco_LineDevCaps_Ext) + 100 = 564; lineGetDevCaps returns dwNeededSize = 0, with LINEERR_STRUCTURETOOSMALL
• dwTotalSize = sizeof(LINEDEVCAPS) + sizeof(Cisco_LineDevCaps_Ext) + 200 = 664; lineGetDevCaps returns dwNeededSize = 0, with LINEERR_STRUCTURETOOSMALL
• dwTotalSize = sizeof(LINEDEVCAPS) + sizeof(Cisco_LineDevCaps_Ext) + 300 = 764; lineGetDevCaps returns dwNeededSize = 763, and succeeds.

In my tests, dwAPIVersion = 0x00020001, and dwExtVersion = 0x000d0000, as negotiated.

I can provide sanitized TSP logs, but it should be obvious where to look into now. Please let me know.

Just to make sure we are on the same page on what dwNeededSize is supposed to contain, here's a quote from the TAPI Memory Allocation guidelines: "TAPI fills in the dwNeededSize member. [...] the application should allocate a structure at least the size of dwNeededSize and invoke the function again. Usually, enough space is available this time to return all the information, although it is possible the size could have increased again."

Thanks.

[smupadhy]

Hi Mihai,

We are looking into this. It will be helpful if you can provide us the detailed Cisco TSP logs, for the failure scenario.You can forward it by email.

Please enable detailed level of TSP tracing before the test. Instructions can be found here: TAPI Case Opening Steps

Information on Variably Sized Data Structures in TAPI is given here: Variably Sized Data Structures (Windows)

Thanks,

[mihaicodrean]

Hi Smita,

I'm attaching part of the TSP logs, showing the calls to lineGetDevCaps for one device, until they succeed. Although they show the needed size as being calculated, it's not filled in the dwNeededSize member when the returned value is LINEERR_STRUCTURETOOSMALL. It's actually only filled in when the provided buffer is large enough, but then I don't need it anymore.

Best Regards,

-Mihai

[smupadhy]

Hi Mihai,

The trace statements printed in your logs, shows that lineGetDevCaps is being populated (and is not zero), when GetDevCaps fails with error LINEERR_STRUCTURETOOSMALL.

For e.g:

Instance 1: GetDevCaps fails with error LINEERR_STRUCTURETOOSMALL

01:18:35.428 | CSelsiusTSPLine::GetDevCaps() line id=0x00000000 MX: final sizes: used=0x000000FC needed=0x000002DA devSpecific=0x00000000

01:18:35.428 |<--CSelsiusTSPLine::GetDevCaps() line id=0x00000000

01:18:35.428 |<--SelsiusTSP::TSPI_lineGetDevCaps(5)

01:18:35.428 | TSPI_lineGetDevCaps() TSPI_lineGetDevCaps returns = 0x8000004D

Instance 2: dwTotalSize incrementally increased , GetDevCaps fails with error LINEERR_STRUCTURETOOSMALL and needed size is 0x000002DA.

01:18:35.430 | CSelsiusTSPLine::GetDevCaps() line id=0x00000000 MX: final sizes: used=0x00000150 needed=0x000002DA devSpecific=0x00000000

01:18:35.430 |<--CSelsiusTSPLine::GetDevCaps() line id=0x00000000

01:18:35.430 |<--SelsiusTSP::TSPI_lineGetDevCaps(5)

01:18:35.430 | TSPI_lineGetDevCaps() TSPI_lineGetDevCaps returns = 0x8000004D

...

We are suspecting TAPI internally might be setting the needed size to zero, when buffer size is small, and that is why application is seeing it as zero. Cisco TSP is sending the right calculated value of needed size. We will continue to investigate the issue further, and try to come up with a better solution to the problem. For now, based on the error : LINEERR_STRUCTURETOOSMALL, the application can increase the dwTotalSize to a bigger value and resend the request.

Thanks,

[mihaicodrean]

Hi Smita,

Thanks for the reply.

For now, based on the error : LINEERR_STRUCTURETOOSMALL, the application can increase the dwTotalSize to a bigger value and resend the request.

Yes, that's exactly the workaround I have turned to eventually, as mentioned somewhere above in this thread.

By the way, I apply the exact same initial algorithm for lineGetCallInfo, and there I get non-zero dwNeededSize values, gradually incrementing. So maybe you can compare the TSP code for differences, if any, in that respect.

Best Regards,

-Mihai

[smupadhy]

Hi Mihai,

Thanks for pointing that out. We will look into the TSP code of lineGetCallInfo for comparison.

Regards,

Smita

[mihaicodrean]

Hi Smita,

By the way, how we could get more timely support going forward, including paid support? Especially for the initial contact / very first reply.

Best Regards,

-Mihai

[smupadhy]

Hi Mihai,

We try to monitor the forums actively and respond in a timely manner. For urgent issues, you can opt for Case based support. More information on how to go about that, can be found here - Cisco DevNet Support

Thanks,

Smita