pointer not reset using delete[] for dynamic mem allocation

[isrinc]

Inline Code Example HereI am using a pair of pthreads that call a pair of functions for ping-pong dma data transfer that are used in a loop for data transfer from an acquisition board. For a large # of waveforms, I ultimately run out of PC memory and the program stops. At the end of each function I use the delete[] command to clear memory for reuse, but the pointer appears to advance by the array size used for the transfer until the location exceeds the 2 GB I have for memory. I can see this happening using the Task Manager performance button time plot and window of total memory used continuing to increase to the limit. Orignially, I had an array dimensioned in each procedure, and it used up memory twice as fast. When I transferred the line to an area just prior to main and used a constant 1024 for length, the program ran twice as far before exceeding system memory, so it appears that both lines were forcing new memory assignments and moving the pointers accordingly. In addition to using the delete[] command to free memory unsucessfuly at the end of each function procedure, I ended up closing the memory at the end of each procedure, then reallocating it again with the idea that the pointer would be set back to the original value, but it still seems to icrement along. So, neither approach appears to allow reuse of the memory because the pointer continues to march along. Any ideas how to solve this? Using Visual C++ 6.0 to compile.

[deceptikon]

Please post a sample program that exhibits the problem.

[isrinc]

/*
void* threadFuncCompress2(int* count)
{   
//casting to set the data array to an unsigned short array, changed to CHAR, 1-byte
 unsigned char* dataBuffer2 = (unsigned char *) (pci_buffer2.UserAddr);// offending line, pointer 
//double* RO = new double[length/1];
//double* IO = new double[length/1];  // both now prior to main, 

// <bulk of processing done here, then attempt to close memory and reallocate>

 rc =PlxPciPhysicalMemoryUnmap(hDevice,&pci_buffer2);
  // Release the buffer
  rc =PlxPciPhysicalMemoryFree(hDevice,&pci_buffer2);
 pci_buffer2.Size = mult3 + 256;  //must be 256, not 32!
 rc =PlxPciPhysicalMemoryAllocate(hDevice,&pci_buffer2,TRUE);
  if (rc != ApiSuccess){
   if(rc == ApiInsufficientResources) PlxPrintf("Insuff Resources-\n");
   else PlxPrintf("Error : Unable to allocate Buffers- reason unkown\n");
  }
 rc =PlxPciPhysicalMemoryMap(hDevice,&pci_buffer2);
 if (rc != ApiSuccess)PlxPrintf("####Physical Memory Map Fail ########");
  //else PlxPrintf("\n\n\nPhysical Memory Mapped\n\n\n");

 SetupDmaDescriptors(hDevice,&SglPciAddress2,pci_buffer2,&mult3);pthread_exit(NULL);
    return NULL;
}  */

[NathanOliver]

Well I cant tell anything from this. What line is causing the problem? I am not seeing a call to delete [] anywhere in this function for RO or IO.

[isrinc]

The DELETE[] was not posted as part of the code, since I solved the one problem by moving RO and IO to just before main. I dimensioned it there to a constant max value of 2048, rather than my the dynamic variable shown here in the commented-out line, so that is no longer a problem. It was a problem that was not being solved using the DELETE[] command, but sped up the memory overun by a factor of 3 compared to the code as shown now.

By moving both RO and IO out of the procedure, just the 5th line is causing the problem now. Lines 11-24 are also used in main to allocate pci_fuffer2 memory to begin with for when the program uses pci_buffer2 for the first time on the firt call to this (or an identical procedure, threadFuncCompress1). I tried at the end of this procedure to then deallocate, then reallocate memory to see if that would set the pointer back to it's original location. It did not do so, and the memory is not truly freed and made available for use again, but instead the pointer continues to step through and ultimately overrun the 2 GB on board.

[Ancient Dragon]

new and delete do not change the value of pointers, that's your responsibility. And if you delete a pointer then allocate it again with new there is no guarentee that new will return a pointer to the same memory that was previously deleted. If you wish that to happen you can override the new operator with your own algorithm to make it work however you want it to work. An alternative is to use inplace new where you control the memory addresses returned by new.