SHP provider crashed when reallocing memory in ReadRawDataBlock.

[StevenXu]

The un-reasonble memory size directly results in this crash. For example, sometimes the size of reallocing memory is greater than 1 GB.

Why the SHP provider need to realloc so large size of memory? SHP provider should get the wrong size of the data block in runtime.

In some cases, the user's SHP file violated the SHP file specification so that our SHP provider misunderstand them.

Another possible reason, there is a defect in the function ShpFileSet::MakeSpace, which would corrupt SHP file under some extremed conditions. At last, this corrupted SHP file result in this crash.

[StevenXu]

It is obviously that SHP provider got the wrong size of memory in runtime.

Why it would happen?

In some cases, the user's SHP files violated the SHP file specification so that our SHP provider can't understand them and read an incredible size of the data block from them.

Another possible reason, there is a defect in the function

ShpFileSet::MakeSpace

which could corrupt SHP file in some extreme cases. As a result, this corrupted SHP file leads to this crash.

The attachment "Ticket_564.patch" is the fix against: ​http://svn.osgeo.org/fdo/trunk/Providers/SHP/Src/Provider/ShpFileSet.cpp

It includes two fixes.

1. While reading the shape from the file, if SHP provider run into some unknown

exceptions, eat these exceptions and return a Null Shape.

2. Correct the problem in function

   ShpFileSet::MakeSpace
   

   which would miss the last chunk in some extreme cases.

\Providers\SHP\Src\Provider\ShpFileSet.cpp

ShpFileSet::MakeSpace
{
......
Line 655: while (shp->ReadFile (buffer + plus, size, &read) && (size == read))
Line 665: if (0 != read)
......
}

The if statement isn't right and which would result in the last "excess" bytes of the file were missing , when the "while" statement success in reading the all bytes of the file once.

[waltweltonlair]

Steven's fix has been submitted to trunk - r5024.

Submission to 3.4 branch stream is pending.

[StevenXu]

Made submission to 3.4 branch stream as ​http://trac.osgeo.org/fdo/changeset/5102