Hi,

Whilst attempting to develop a client application to read a variable data stream from a device ( 512bytes - 10meg+ a second ) I opted to use the Asynchronous CYAPI library calls.

After looking at the streamer example I pretty much lifted the xferloop and built it into my own application for testing purposes. What I've found is that if my application allocs any memory even if it's immediatley deleted it appears to conflict with the memory allocations being performed by the API calls. The pointers to the memory I am allocating are not related to the contexts returned by beingDataXfer or freed by finishDataXfer. 
I have made my applications project settings match that of the streamer app to ensure that I have all the correct C++ settings yet I will still get crashes to do with data freeing in finishDataXfer either to do with heap corruption when writing past a data size or writing into something thats already been freed. The application is single threaded it's a simple loop of waitForXfer ( after inital setup and begin ) finishDataXfer and beginDataXfer again. There is nothing fancy about the application.

For testing purposes I placed 2 lines after the data call to simulated the handling of the results from a successful read 

UCHAR *ptr = new UCHAR[65536];

delete [] ptr;

After around 2-3 minutes or less in some cases the app will crash. The only allocs are the one described above and those done by CYAPI.  

This does not appear to be an issue in the release version and I'm wondering if this problem is because the API is built as a release version only? Have I missed something very simple here. Without the ability to debug it makes it hard to ensure I'm developing my application correctly.

Regards

Steve
 

Hi,

Are you passing the 64k buffer to the API for filling with data?

What endpoint are you using? Have you tried reducing the size of this i.e. split the 64k and passing them  so that entire 64k is not requested at a single point of time?

Please build the streamer using the debug version of CyAPI.lib and try the same exercise and let us know.

64k is huge to passed at a single point of time to the host controller driver plus the debug version of CyAPI.lib is going to be slow just want to make sure that the buffer size is not the issue.

Regards,

Anand

Thanks for the reply,

We are using bulk endpoints , our transfer window size is set to 64k. 

We set up 64 requests ,via beginXferData  all of which have a 64k buffer which we attempt to read into.

Do you suggest we drop this down to say 4096 bytes for testing? What would be an acceptable transfer size for bulk endpoints and beginXferData?

You say use the debug version of the library? The examples release and debug use the same library there is no difference between the two , is this correct?

I have performed some tests by reducing the size of data requested in the call to BeginXferData .

I am using bulk endpoints and I am reading from the target device.

I have an array of 64 buffers all of 4096 bytes , an array of 64 context pointers and an array of 64 overlapped structures.

I perform a beginXferData for each of the 64 requests.

I then enter a loop where I 

 1. waitForXfer

 2. finishDataXfer

 3. beginXferData ( to repeat the request for data ).

this loop runs for 60 seconds.

For the record the setXferSize is still 65536

In between steps 2 and 3 I allocate 1/2 meg and deallocate it straight away , this is for testing purposes to see if there's an issue with memory collision somewhere between the API and the application.  I must stress that this memory is never used it's not passed to anything it's just allocated and then deallocated.

I've still encountered the issue where the debugger reports heap memory corruption

"HEAP[Async.exe]: HEAP: Free Heap block a8ae60 modified at a8ae94 after it was freed

Windows has triggered a breakpoint inAsync.exe."

The rror is usually assosiated with FinishXferData or even the std::stream library but always heap corruption.

The only allocations are the initial 64 buffers , the allocation done by the API and my test allocation. The API allocates and deallocates the contexts the inital 64 buffers exist for the lifetime of the application and my test allocation is alloc'd and dealloc'd quickly during the loop. These allocations shouldn't be causing heap corruption. 

My latest test seem to have only moved the fault further down the time scale so that it happens later rather than sooner. This is with 4096 as the BeginXferData size.

To me it looks like the API is corrupting heap memory and maybe I'm using the wrong CRT or target library to perform debugging ? 

My requirement is to be able to read variable data rates but at the minute I can't even read a very slow data rate without this thing bombing out under debug conditions. I can't trust the release version at this stage as it might be accessing invalid memory segments during runtime causing corruption. 

I'm using the latest version of the API from the site , I've tried it with earlier versions as well , the host controller is an Intel US15W with the device connected to a port that supports USB1.0 and USB 2.0. ( device is connected as USB 2.0 ).

Are there any specific settings I'm missing for the C++ / Linker options for debug? Should I only be working in Release mode ( which would seem odd ). 

Would it help if I supplied the working code for you to test against?

 

Please create a tech support case (MyAccount -> MyCases) and provide your test code which can replicate this. It should help our engineers figure out what exactly is causing this heap corruption and make a proper fix for the same.

Thanks,

Anand