Re: [IMP-dev] [Fwd: Build system failure, 08/28/2008]
Daniel Russel wrote: > Just to check, you need to have the NBL tests and the attribute removal > test, but no others?
Well, the two bipartite NBL tests, and the attribute removal test, yes. (The crash actually seems to occur in set_is_optimized, not in remove_attribute itself.) If I removed either one of the NBL tests, the bug went away. You can have *more* tests, but obviously it takes longer to run the test suite then.
> Now that I think about it, do we have any reasonable way of debugging > with wine? I wouldn't expect gdb to work.
There is winedbg (I just installed it) but I don't know how well that will work. Adding print statements is the time-honored fallback (not sure I'd call that 'reasonable' though).
> Are you using CGAL with wine? If not, then bbox NBL is actually a grid > NBL and I think there were a couple of bugs in that which I fixed but > never made it into IMP svn. If you are using CGAL with wine, how do I > do that?
No, CGAL isn't built for Wine on synth yet, so IMP is a non-CGAL build.
Ben
I haven't managed to figure out what is going on with VC. I did notice that I had removed some checks that would be good to have (I'll fix them later to be more efficient when checks are turned off).
In addition, changing AttributeTable.h::remove_always to the following void remove_always(Key k) { IMP_assert(k != Key(), "Can't remove default key"); if (k.get_index() < map_.size()) { map_[k.get_index()]= Traits::get_invalid(); /*while (!map_.empty() && map_.back()== Traits::get_invalid()) map_.pop_back();*/ } }
(that is, removing the cleanup loop), makes the problem go away. I think the line is OK, so it is all a bit disturbing.
(There probably are some trailing white spaces in the patch, sorry).
BTW, I stumbled upon the msdn page talking about the the /EH flag for visual studio. Do we need to build with /EH to get things cleaned up properly when we throw exceptions?
It also would perhaps be useful to have the debug version of the C++ runtime available for the tests. Visual Studio has some really nice runtime checks for correctness of iterators and usage of the stl types. Just as a warning, I know some of my iterators will fail the tests (since apparently copying an invalid iterator is illegal and I didn't bother to write my own copy constructors in the Optimizer's iterator).
On Aug 28, 2008, at 11:14 AM, Ben Webb wrote:
> Daniel Russel wrote: >> Just to check, you need to have the NBL tests and the attribute >> removal >> test, but no others? > > Well, the two bipartite NBL tests, and the attribute removal test, > yes. > (The crash actually seems to occur in set_is_optimized, not in > remove_attribute itself.) If I removed either one of the NBL tests, > the > bug went away. You can have *more* tests, but obviously it takes > longer > to run the test suite then. > >> Now that I think about it, do we have any reasonable way of debugging >> with wine? I wouldn't expect gdb to work. > > There is winedbg (I just installed it) but I don't know how well that > will work. Adding print statements is the time-honored fallback (not > sure I'd call that 'reasonable' though). > >> Are you using CGAL with wine? If not, then bbox NBL is actually a >> grid >> NBL and I think there were a couple of bugs in that which I fixed but >> never made it into IMP svn. If you are using CGAL with wine, how >> do I >> do that? > > No, CGAL isn't built for Wine on synth yet, so IMP is a non-CGAL > build. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Daniel Russel wrote: > In addition, changing AttributeTable.h::remove_always to the following > void remove_always(Key k) { > IMP_assert(k != Key(), "Can't remove default key"); > if (k.get_index() < map_.size()) { > map_[k.get_index()]= Traits::get_invalid(); > /*while (!map_.empty() > && map_.back()== Traits::get_invalid()) map_.pop_back();*/ > } > } > > (that is, removing the cleanup loop), makes the problem go away. I think > the line is OK, so it is all a bit disturbing.
The code also looks fine to me, but certainly appears to be the culprit. I replaced it with an uglier use of erase(), which seems to work. Perhaps an MSVC bug or some hidden corruption elsewhere in the code. If the latter, I guess we'll find it eventually.
> BTW, I stumbled upon the msdn page talking about the the /EH flag for > visual studio. Do we need to build with /EH to get things cleaned up > properly when we throw exceptions?
We already build with /GX, which is the same as /EHsc, and I think that's sufficient.
> It also would perhaps be useful to have the debug version of the C++ > runtime available for the tests.
True - I'll look into that.
Ben
>> BTW, I stumbled upon the msdn page talking about the the /EH flag for >> visual studio. Do we need to build with /EH to get things cleaned up >> properly when we throw exceptions? >> > > We already build with /GX, which is the same as /EHsc, and I think > that's sufficient. > Looks OK. Apparently that is the older version (pre 2005) of the same flag, but is still supported.
participants (2)
-
Ben Webb -
Daniel Russel