public inbox for sourcenav@sourceware.org
 help / color / mirror / Atom feed
* RE:Windows NT Failing on XRef Generation
@ 2001-02-13  4:55 Darren Syzling
  2001-02-13  9:15 ` SourceNav Symbol Browser Closed Bill Munday
  2001-02-13 23:05 ` RE:Windows NT Failing on XRef Generation Mo DeJong
  0 siblings, 2 replies; 5+ messages in thread
From: Darren Syzling @ 2001-02-13  4:55 UTC (permalink / raw)
  To: sourcenav

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.
*******************************************************************************************************************************************************


^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-02-14  8:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-13  4:55 RE:Windows NT Failing on XRef Generation Darren Syzling
2001-02-13  9:15 ` SourceNav Symbol Browser Closed Bill Munday
2001-02-13 13:29   ` Ian Roxborough
2001-02-13 23:05 ` RE:Windows NT Failing on XRef Generation Mo DeJong
2001-02-14  8:51   ` Grep Editor function Bill Munday

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).