Carl Sorensen <c_soren...@byu.edu> writes: > On 12/12/09 2:27 PM, "Joe Neeman" <joenee...@gmail.com> wrote: > >> On Sat, 2009-12-12 at 14:15 -0700, Carl Sorensen wrote: >>> So I've finally gotten to a point where I think I know what to do with the >>> autobeaming code to make it work properly in 4/4 time with a 1/16 note in >>> the second beat. >>> >>> I've written code to try to fix it. The code seems to execute properly >>> through my changes, but then it gets into a problem, and I get this error >>> message: >>> >>> terminate called after throwing an instance of 'std::out_of_range' >>> what(): vector::_M_range_check >>> Abort trap >>> >>> >>> So I try running it in gdb, and I get the same error. >> >> At this point, you should be able to type "bt" to get a backtrace. You >> can move up and down through the frames by typing "up" and "down" or you >> can jump to the 23rd frame with "fr 23". Once you are in a frame, you >> can examine all of the local variables. The first few frames will >> probably be non-lilypond code, so you'll want to ignore them. > > > Thanks, Joe. This really helped. > > Now I have another problem. I have something that seems impossible to me.
Without _any_ analysis of the actual problem, I am just regurgitating some keyword-triggered advice from Emacs' DEBUG file. You might have compiled without optimization in which case it does not apply. This particular option might be considered useful generally since otherwise debugging any abort/failed assertion (and what's the use of abort without debugging?) becomes quite useless. Spent days on hunting down an "impossible bug" more than once. ** When you are trying to analyze failed assertions, it will be essential to compile Emacs either completely without optimizations or at least (when using GCC) with the -fno-crossjumping option. Failure to do so may make the compiler recycle the same abort call for all assertions in a given function, rendering the stack backtrace useless for identifying the specific failed assertion. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
