On 6/3/2011 4:06 PM, Andrew Chernow wrote:
> On 6/3/2011 3:03 PM, Pavel Golub wrote:
>> Hello.
>>
>> Reproduced under Windows XP SP3 using Visual C++ 2008 and Delphi. If
>> PQsetvalue is called with second parameter equals to PQntuples then
>> memory corruption appears. But it should grow internal tuples array
>> and populate the last item with provided data. Please see the code:
>>
>>
>
> At first glance (have not tested this theory), looks like pqAddTuple()
> doesn't zero the newly allocated tuples slots like PQsetvalue() does.
> PQsetvalue is depending on the unassigned tuple table slots to be NULL
> to detect when a tuple must be allocated. Around line 446 on fe-exec.c.
> I never tested this case since libpqtypes never tried to call PQsetvalue
> on a PGresult created by the standard libpq library.
>
> The solution I see would be to zero the new table slots within
> pqAddTuple. Any other ideas?
>
Eeekks. Found an additional bug. PQsetvalue only allocates the actual
tuple if the provided tup_num equals the number of tuples (append) and
that slot is NULL. This is wrong. The original idea behind PQsetvalue
was you can add tuples in any order and overwrite existing ones.
Also, doing res->ntups++ whenever a tuple is allocated is incorrect as
well; since we may first add tuple 3. In that case, if ntups is
currently <= 3 we need to set it to 3+1, otherwise do nothing. In other
words, while adding tuples via PQsetvalue the ntups should always be
equal to (max_supplied_tup_num + 1) with all unset slots being NULL.
PQsetvalue(res, 3, 0, "x", 1); // currently sets res->ntups to 1
PQsetvalue(res, 2, 0, "x", 1); // as code is now, this returns FALSE due
to bounds checking
--
Andrew Chernow
eSilo, LLC
global backup
http://www.esilo.com/
