Re: C bug of the day

[Raoul Gough <RaoulGough@yahoo.co.uk>]

Hyman Rosen <hyrosen@mail.com> writes:

 > Warren W. Gay VE3WWG wrote:
 >  > The problem ended up in an INFORMIX-7.31 library
 >  >
 >  > That little buffer overflow problem cost me 3 months of my life,
 >  > and was a very expensive mistake for the company to correct.
 >
 > Oddly enough, the most mysterious bug I had to deal with
 > recently turned out to be a problem in Sybase ODBC drivers.
 > I had been programming database code in Visual Basic in Excel.
 > The company was changing people over from WindowsNT to
 > Windows2000, and certain of my spreadsheets stopped working.
 > Stored procedure calls would fail mysteriously. You can only
 > imagine the number of blind alleys I wandered down trying to
 > figure out what was going on.
 >
 > The ultimate culprit? The ODBC driver when invoked from Excel
 > sent Sybase its host ID in hex. One of the internal stored
 > procedures of the same trading system would get the host ID,
 > which Sybase returns as a string, and try to convert it to
 > decimal. When there happened to be no hex digits in the ID,
 > everything would be fine. When there were, the conversion
 > would cause an error, aborting the procedure. On and off,
 > that bug cost me a couple of months of hair pulling.

I remember a buffer overflow that started crashing some DB access code
of ours when we moved the DB from one machine to another (our code was
written in C++ and C, so this is mildly on topic). The only thing was,
the buffer actually was big enough for the data we were retrieving,
and putting magic markers at either end of the buffer showed no
past-the-end writing taking place. Nevertheless, certain data sets
crashed the program consistently, and only when the database being
accessed was on the local machine.

I was going bananas trying to figure this out, until I realised that
part of our code was dealing with the exact size of the current BLOB,
whereas other parts were using the BLOB *segment* size for the DB in
general. If the given BLOB was actually smaller than a single segment,
we were misreporting the size of our buffer to the DB library. Now,
with the DB on the local machine, the smart old Rdb library was
mapping the file data into memory, rather than reading and copying
it. The buffer was big enough for the BLOB's data, but actually not as
big as we claimed, so the memory map system call was failing
sometimes. I suspect it happened only when the buffer happened to be
near the top of the process's virtual memory.

I fixed our code and reported a bug to the Rdb support anyway, because
it should have been reporting an error instead of crash dumping.

-- 
Raoul Gough
"Let there be one measure for wine throughout our kingdom, and one
measure for ale, and one measure for corn" - Magna Carta

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]