Re: [brlcad-devel] Debugging g-nff and Friends

[Tom B. <tom...@gm...>]

On Sun, Apr 15, 2012 at 13:50, Tom Browder <tom...@gm...> wrote:
> On Sun, Apr 15, 2012 at 08:34, Christopher Sean Morrison <br...@ma...> wrote:
> ...
>> There are certainly places and situations where a bomb
>> might not be caught (such as during the 'catch' or outside the try/catch).

I've found one possible cause of the problem.  In
db_tree.s:db_free_tree there is a comment and line:

    /*
     * Before recursion, smash the magic number, so that if another
     * thread tries to free this same tree, they will fail.
     */
    tp->magic = (uint32_t)-3;		/* special bad flag */

and that "special bad flag" looks suspiciously like the
"Unknown_Magic" number I see in the crash message:

  ERROR: bad pointer 0x812390: s/b union tree(x91191191),
  was Unknown_Magic(xfffffffd),
  file /usr/src/tbrowde/brlcad-svn/brlcad/trunk/src/librt/db_tree.c, line 1458

That occurs when trying to free a tree in a catch block.  When I
commented out the delete tree line in g-nff the crash stopped and we
got a graceful end.

A few questions:

1.  Shouldn't the special flag be generalized and get a bu macro?
2.  Shouldn't a test for the "free flag" be built into the
db_free_tree function to return silently if the tree is already freed?
3.  Is there a way to force single-threading for debugging?

I've checked the other culprits in the TODO list I added and the same
kind of situation is happening.  I made a local change to db_tree to
add the test I mentioned in question 2 above and the bomb problems
went away (except for g-iges which now has another problem but with
another bad tree magic number [maybe other "special" flags floating
around?]).

I also got a successful full regression test afterwards.   Obviously
the test has wide-spread ramifications so it may not be the right
thing to do, but it looks promising.

Best regards,

-Tom