lilypond-0.1.54
[lilypond.git] / BUGS
blob384fb5ce6bf735f2ac1edbe9e0ccd748a0137aa9
1 \score{
2         \melodic{
3                 [c2 c]
4         }
6 lilypond: ../flower/include/varray.hh:141: struct Rhythmic_grouping *& Array<Rhythmic_grouping *>::elem(int) const: Assertion `i >=0&&i<size_' failed.
7 Aborted (core dumped)
9 \score{
10         \melodic{
11                 [c]
12         }
14 lilypond: ../flower/include/cursor.tcc:104: int Cursor<void *>::operator -(class Cursor<void *>) const: Assertion `c.ok()' failed.
15 Aborted (core dumped)
19 [GNU libc]
21 The GNU extension memmem() is known to be buggy on linux libc 5.0.9
22 and before. Glibc upto 2.0.5 also has problems with memmem (), but
23 these should not affect LilyPond.
26 [Linux Intel]
28 LilyPond occasionally crashes while parsing the initialisation files.
29 This is a very obscure bug, and usually entering the commandline
30 differently "fixes" it.
32         lilypond input.ly 
34 and
36         lilypond -I. ./input.ly 
38 makes a difference
40 Typical stacktrace:
42         SIGSEGV
43         __libc_malloc (bytes=16384)
44         ?? ()
45         yyFlexLexer::yy_create_buffer ()
46         Includable_lexer::new_input (this=0x8209a00, s={strh_ = {
47                 :
50 I get bitten by this every once in a while, and I am very interested
51 in hints what might be wrong.  This problem has only been identified
52 with libc-5.3 and libc-5.4 platforms, so you might try upgrading to
53 6.0, ie. GNU libc-2.
56 [Linux Intel]
58 A problem resembling the previous: usage of libg++.2.8.x with the
59 wrong version of libc results in a coredump from the scanner while
60 reading the init files.  Stacktrace:
62         ios::eof (this=0x0)
63         
64         yyFlexLexer::LexerInput (this=0x8294848, buf=0x82955f0 "", max_size=8192)
65         yyFlexLexer::yy_get_next_buffer (this=0x8294848)
66         My_lily_lexer::yylex (this=0x8294848) 
68 Fix: follow the install instructions of libg++: match the right
69 library versions.