]> git.donarmstrong.com Git - lilypond.git/blobdiff - BUGS
patch::: 1.1.22.jcn5: autobiem
[lilypond.git] / BUGS
diff --git a/BUGS b/BUGS
index 5977e0d3ceca756e41050cda55e910a55a03d791..76d8f8e1a038dd627127ea6a0b3323260dcc279b 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1,20 +1,45 @@
-Document Really Ugly Bugs (coredumps assert fails, etc)
 
-[Solaris]
+This documents serious bugs 
 
-Stack frame overwrite on Solaris 2.x (this will produce a seg
-fault, signal 11).  Stacktrace
+********
 
-       Engraver_group_engraver::Engraver_group_engraver(int)
-       Score_engraver::Score_engraver( )
-       get_group_engraver_p()
+[Linux ppc, egcs-1.0.2]
 
-We don't know a fix or workaround, but compiling without optimisation
-might help (Without -O2 optimisation, my execs run fine on Solaris;
-without -O2, but with purify, it dumps core)
+All compiling with -O2 is suspect, in particular guile-1.3, and
+Lily herself will break.
 
 
-[Linux Intel]
+[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
@@ -37,6 +62,22 @@ Typical stacktrace:
        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) 
 
-I get bitten by this every once in a while, and I am very interested
-in hints what might be wrong.
+Fix: follow the install instructions of libg++: match the right
+library versions.