On Mon, Apr 16, 2012 at 07:52, Christopher Sean Morrison <[email protected]> wrote: > > On Apr 16, 2012, at 7:24 AM, Tom Browder wrote: ... >> 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? > > That's a possible solution but doesn't sound like the right one. > If a tree pointer was freed, it shouldn' t be referenced any longer. That's > the problem.
[1] Does that mean the tree pointer itself should have been set to zero after the free? >> 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. > > It's still an improvement, so you could go ahead and commit it. > That might make the problem more obvious, but it'll probably require walking > through the state of the tree prior to and during delete. Either way, > delete shouldn't bomb. The generalized fix is probably to not do a bomb check > but only free if magic == known magic. [2] I'lll commit the "fix" if I can't make any headway based on the answer to [1] above. Best regards, -Tom ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
