This documents serious bugs 

********

[Linux ppc, egcs-1.0.2]

All compiling with -O2 is suspect, in particular guile-1.3, and
Lily herself will break.


[All platforms] 

When dealing with beaming that is not correct (eg quarter notes in
beams.), you can get the following assert.  This is a serious bug, but
a good solution is quite a lot of work.

	\score{
		\melodic{
			[c2 c]
		}
	}

results in

	lilypond: ../flower/include/varray.hh:141: struct Rhythmic_grouping *& Array<Rhythmic_grouping *>::elem(int) const: Assertion `i >=0&&i<size_' failed.

And this

	\score{
		\melodic{
			[c]
		}
	}

in

	lilypond: ../flower/include/cursor.tcc:104: int Cursor<void *>::operator -(class Cursor<void *>) const: Assertion `c.ok()' failed.
	Aborted (core dumped)


[Linux libg++ 2.7]

LilyPond occasionally crashes while parsing the initialisation files.
This is a very obscure bug, and usually entering the commandline
differently "fixes" it.

	lilypond input.ly 

and

	lilypond -I. ./input.ly 

makes a difference

Typical stacktrace:

	SIGSEGV
	__libc_malloc (bytes=16384)
	?? ()
	yyFlexLexer::yy_create_buffer ()
	Includable_lexer::new_input (this=0x8209a00, s={strh_ = {
		:

This behaviour has been observed with machines that have old libg++
versions (LinuxPPC feb '98, RedHat 4.x).  



[Linux Intel]

A problem resembling the previous: usage of libg++.2.8.x with the
wrong version of libc results in a coredump from the scanner while
reading the init files.  Stacktrace:

	ios::eof (this=0x0)
	
	yyFlexLexer::LexerInput (this=0x8294848, buf=0x82955f0 "", max_size=8192)
	yyFlexLexer::yy_get_next_buffer (this=0x8294848)
	My_lily_lexer::yylex (this=0x8294848) 

Fix: follow the install instructions of libg++: match the right
library versions.