Menu
▾
▴
#1900 Multiple fret-diagram-x markup commands and lilypond safe-mode
Originally created by: *anonymous
Originally created by: PhilEHol...@googlemail.com
Originally owned by: dak@gnu.org
Long email exchange here: http://lists.gnu.org/archive/html/bug-lilypond/2010-11/msg00014.html gives fuller details. Processing 2 files on the command line can be made to cause this error:
s2.ly:5:21: error: GUILE signaled an error for the expression beginning here
\fret-diagram-terse #
"x;x;o;2;3;2;"
Wrong type argument in position 1 (expecting module): #<freed cell 0xb6d06880;
GC missed a reference>
Discussion
Originally posted by: julien.r...@gmail.com
Trying to produce (hopefully useful) debug output for this bug, I came up with this:
lilypond -dbackend=eps guile-debugger.ly s1.ly s2.ly << EOF >& bug-trace
(set-trace-subtree! fret-diagram-terse-markup)
(quit)
EOF
Originally posted by: julien.r...@gmail.com
(No comment was entered for this change.)
Originally posted by: Carl.D.S...@gmail.com
There is a patch on Rietveld for review:
http://codereview.appspot.com/5432081
This patch solves the problem by making explicit property declarations for fret-diagram-terse and fret-diagram, rather than using the curried definition of fret-diagram-verbose.
It may have the disadvantage of separating the property definitions from the different fret diagram markup definitions. But I think avoiding the crash is worth it. This may also solve Issue 1997, but I can't test that because 1997 doesn't show up on my system.
No regression test is included, because it requires a special lilypond-book run. But the .lytex file from the original email string is attached, and the first line of the file shows the command to run to test. If no errors occur, the patch is successful.
Owner: Carl.D.S...@gmail.com
Status: Started
Originally posted by: dak@gnu.org
Very weird. Can somebody experiencing this crash try removing the three occurences of weak-key- in command names from scm/markup-macros.scm and see whether this makes a difference?
This is one garbage-collection related item that I currently get a headache when trying to figure out the exact implications. It might or might not be related.
Originally posted by: dak@gnu.org
Guess I found it. in parse-scm.cc we have
internal_ly_eval_scm (Parse_start *ps)
{
if (ps->safe_)
{
static SCM module = SCM_BOOL_F;
if (module == SCM_BOOL_F)
{
SCM function = ly_lily_module_constant ("make-safe-lilypond-module");
module = scm_call_0 (function);
}
Note that this module is _not_ protected from garbage collection. It will blow up at some random point of time.
The proper fix depends on whether we want to create a _separate_ lilypond module for each source file, or keep one module throughout.
I'll check in a fix shortly that does _not_ create separate modules since this is the obvious _intent_ of the current code. It may be worth rethinking this.
The minimal fix will just add one line; I'll push it directly to staging.
Originally posted by: dak@gnu.org
Pushed as [rc571ae573018d5c14f521b4398649bc6790aaf74]
Unfortunately, apparently not responsible for the crash I get on Ubuntu 11.10 when testing with default compilation options (don't remember the issue number right now).
Originally posted by: julien.r...@gmail.com
Just tested: current master still exhibits the bug while current staging does not, so I take it that the commit [rc571ae573018d5c14f521b4398649bc6790aaf74] fixes the bug. And as the commit message says, it seems to fix other similar bugs that I had experienced when running safe mode. A big thank you!
Originally posted by: Carl.D.S...@gmail.com
Fixed by David Kastrup -- see comment 6.
Verify with successful run of file from comment 3.
Thanks, David!
Labels: fixed_2_15_21
Status: Fixed
Originally posted by: colingh...@gmail.com
I used lilypond-book from 2.15.22 on Linux with the file from Comment 3. Processing that with latex, dvips and ps2pdf produced a single page with two fret diagrams on it. See attached image.
Verified on Ubuntu 10.04.
Status: Verified
Originally posted by: dak@gnu.org
(No comment was entered for this change.)
Owner: dak@gnu.org