Core dump from GDALDeinitGCPs when multithreading

[searsz]

I am attempting to use the GCP transform code to transform imagery from multiple sources in real time. When I use the API methods with just a single data source I have no problems, however when I try and transform multiple sources the GDALDeinitGCPs method seems to fail every time. The error returned at the time of the core dump is:

Error: free(): invalid next size (fast):

Which generally means the heap is getting corrupted/over-written somewhere, but this appears to be happening somewhere that I have no control over. The general flow of the larger software is:

1) Start a seperate thread for each data source. 2) Within that thread initialize the wrapper class that I have built to do the transformation.

So the different source threads do not share the same transformer object class

3) As a new set of data comes in for each set the GCPs, do the transform and attempt to free the GCP list, this is where the failure occurs.

I won't post the full piece of code, but the pieces of code that have to deal with the GCPs is given below.

GDAL_GCP *gcps = NULL;    // Initialize gcps to NULL

// Realloc the gcps if there were enough points on the earth
gcps = (GDAL_GCP *) CPLRealloc (gcps, numGcpOn * sizeof(GDAL_GCP));
GDALInitGCPs(numGcpOn, gcps);
// Assign the gcps...
// ...

// Assign the gcps to the raster
rawRaster->setGCPs((int) numGcpOn, gcps, rawWkt);

// Do the transformation
// Create the output files
// Handle errors...

// Cleanup time
if (gcps != NULL){
    GDALDeinintGCPs(numGcpOn,gcps);    Consistent core dump
    CPLFree(gcps);
}
gcps = NULL;

Like I said before this all works perfectly fine if I only have a single data source running, however once I turn on any additional sources this will fail every time. It is worth noting that the data from each source will arrive at nearly the same point in time, so multiple threads will be executing at nearly the same time. The only thing I can think of is that the Realloc is not giving a unique memory set, but that doesn't even make a lot of sense to me.

When the transformations do complete, meaning running a single data source, they are definately correct so it doesn't seem to be that the GCPs are messed up and that is somehow causing problems. As a final note for a given set of data there is roughly 4000 or so GCPs, not a huge number but not small since these are fairly large images that I am receiving. Hopefully this is a simple fix as the libraries have been extremely useful up to this point.

[warmerdam]

I don't see any obvious issues with the GCP handling.

Generally speaking GDAL is not thread safe for writing in multiple threads at the same time which I'm guessing you are doing. Usually that thread safety condition would not immediately manifest as heap corruption - more likely corrupt output files - but that could be the source of the problem.

If you can run under valgrind that might help you isolate the issue. Alternatively if you can provide a code segment that demonstrates the problem for us we might be able to investigate. At this time there isn't much for us to go on.

[Even Rouault]

Closing. No feedback from reporter. No direct way of reproducing. The only way of progressing of this would be to have a standalone code snippet that would reproduce the issue.