input/abbrev.ly

********
\score{
	\melodic{
	        [c2 c]
	}
}
lilypond: ../flower/include/varray.hh:141: struct Rhythmic_grouping *& Array<Rhythmic_grouping *>::elem(int) const: Assertion `i >=0&&i<size_' failed.
Aborted (core dumped)
*********
\score{
	\melodic{
	        [c]
	}
}
lilypond: ../flower/include/cursor.tcc:104: int Cursor<void *>::operator -(class Cursor<void *>) const: Assertion `c.ok()' failed.
Aborted (core dumped)



[GNU libc]

The GNU extension memmem() is known to be buggy on linux libc 5.0.9
and before. Glibc upto 2.0.5 also has problems with memmem (), but
these should not affect LilyPond.


[Linux Intel]

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_ = {
		:


I get bitten by this every once in a while, and I am very interested
in hints what might be wrong.  This problem has only been identified
with libc-5.3 and libc-5.4 platforms, so you might try upgrading to
6.0, ie. GNU libc-2.


[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.
