RE:Windows NT Failing on XRef Generation

RE:Windows NT Failing on XRef Generation

[Darren Syzling]

On 14/02/2001 07:05:01 Mo DeJong wrote:

>I know how hard it is to trim down a test case, but we really need one if we
are to be of any help tracking this down. Finding..

I can make no promises, but I'll see what I can do.  SN is a useful tool and
this problem is stopping us using it for our project(s). So I do have a vested
interest.

>bugs in compilers and parsers is really really hard, it is just about
impossible without a test case.

Your telling me I stepped through that code (well the xref pieces), some of it
looks quite hairy ;-)

Did the rest of the technical description of the problem make any sense ?


Thanks
Darren

RE:Windows NT Failing on XRef Generation

[Mo DeJong]

On Tue, 13 Feb 2001, Darren Syzling wrote:

> We've also seen a crash on xref generation under NT with the 4.5.2 stable
> release.  Unfortunately this occurs within our product code base and is a little
> difficult to extract a repeatable test case.

I know how hard it is to trim down a test case, but we really
need one if we are to be of any help tracking this down. Finding
bugs in compilers and parsers is really really hard, it is
just about impossible without a test case.

Mo DeJong
Red Hat Inc

RE:Windows NT Failing on XRef Generation

[Darren Syzling]

We've also seen a crash on xref generation under NT with the 4.5.2 stable
release.  Unfortunately this occurs within our product code base and is a little
difficult to extract a repeatable test case.

I've had limited time to track this down and this is the first time I've had a
look over the source code so excuse my complete ignorance, but here's some info
on my findings:

The crash occurs in dbimp.exe when building refs to one of our unit test files
which is quite large (> 2000 lines) on a symbol which is used extensively (we're
using a C++ port of JUnit).  It seems sensitive to the size of the file or may
be the number of symbols it's cross referencing.

The crash occurs in db\btree\btsearch.c within the __bt_search function on the
following line:
next:          BT_PUSH(t, h->pgno, index);

I believe it's writing the "proj.by" file, part of the stack trace includes:
db_insert_entry(int type,char *key_buf,char *data_buf)
    __bt_put(dbp, key, data, flags)
      __bt_search

The problem appears to be caused by the bp_sp member of the _btree structure
being corrupted  (the _btree instance is passed to the search function).   What
actually appears to be happening in this case is that we iterate over the tree
looking for a match and each time a parent page is pushed on the bt_stack.  The
bt_sp member is then incremented to point to the next location in the stack
array.  It seems that one of the many sentinel conditions is never triggered and
the function never checks for the array bounds being exceeded.  The bt_stack is
defined to a magic value of 50 in the btree header.  Once this is exceeded we
write the value of the page number over the bp_sp pointer (since it follows the
stack in memory - depending on padding and alignment) which is then
de-referenced by the next statement in the BT_PUSH macro - net result - boom !

Now obviously I could extend the size of the array, but I'm not sure of the
original reason for the magic value in the first place.  May be this situation
should never arise and the error is elsewhere...



Darren





******************************************************************************************************************************************************
This e-mail has been prepared using information  believed  by  the  author
to be reliable and accurate, but CWB makes  no  warranty  as to accuracy or
completeness. In particular CWB does not  accept  responsibility  for
changes  made to this e-mail after it was sent.  Any  opinions expressed in
this document are those of the author and do  not  necessarily reflect the
opinions of the company or its affiliates. They may be subject to change
without notice.
*******************************************************************************************************************************************************