Document Really Ugly Bugs (coredumps, assert fails, etc)


\score{
	\melodic{
	[a8 a-2] /bla
	}
}
koor.ly: 4: error: parse error, expecting `DIGIT' or `UNSIGNED':
        [a8 a-2] /bla
                     
koor.ly: 5: error: Have to be in Lyric mode for lyrics:
        }
         
lilypond: parser.y:765: int yyparse(void *): Assertion `((My_lily_parser *) my_lily_parser_l)->post_reqs.empty ()' failed.
Aborted (core dumped)


[gcc 2.8.x/libstdc++ 2.8.x/libg++ 2.8.0]

The latest gcc release causes lily to crash just after Interpreting
music:

stacktrace looks something like:

      __DTOR_END__ ()
      __malloc ()

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


[IRIX (5.3?)]

coredump from strstream::strstream () upon the first read of a file

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