From: Chris T. <chr...@ae...> - 2007-01-26 15:34:44
|
Greg Chicares wrote: > You could try libstdc++'s debug mode, by defining things like: > > -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS > -D_GLIBCPP_DEBUG -D_GLIBCPP_DEBUG_PEDANTIC -D_GLIBCPP_CONCEPT_CHECKS > -D_GLIBXX_DEBUG_PEDANTIC > > Whether to use the '_GLIBCXX' or '_GLIBCPP' variants depends on > the version of libstdc++, but I believe it does no harm to define > them all. > Thanks, I tried all this and immediately started getting compiler errors. None were actually significant - mostly things like taking the address of a known existent vector entry, eg &vec[vec.size()], that the debug templates objected too. I also had to add some operator<() for classes where it had only been locally defined. Not quite sure about this but maybe the debug headers were causing template instantiation in places it wasn't before. Once I'd got all this working the program continued to function (and crash) as before. > You might try another debugging tool such as drmingw, but > I wouldn't hold out much hope for that. > Sadly ineffective so far... (it doesn't get invoked) > Maybe the only thing that'll work is stepping through the > code manually to localize the problem. > As it's a multi-threaded program this isn't really feasible. As it stands, in gdb, when the crash occurs it just says "Program exited with code 03" Oddly enough, outside of gdb, when the debug templates were detecting errors, they would report the error and then there would be a line about abnormal termination, as happens after the crash. Could it be a problem with exception handling? The only possibly relevant options I can see are "-mno-cygwin -mthreads" and possibly -DWIN32. Thanks, again Chris |