lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixes segfault in beam quanting. (issue4339047)


From: address@hidden
Subject: Re: Fixes segfault in beam quanting. (issue4339047)
Date: Sat, 2 Apr 2011 22:06:43 -0400


On Apr 2, 2011, at 21:49, Han-Wen Nienhuys <address@hidden> wrote:

On Sat, Apr 2, 2011 at 10:37 PM, Han-Wen Nienhuys <address@hidden> wrote:

Quick-n-dirty fix for segfault in issue 1585.

While this fix is prudent (I'd add a programming_error as well), it
does feel like a kludge.   The only way there could be no
configuration at all is when generate_quants() rejects all of them

     if (!quant_range[d].contains (c->y[d]))

I'm pretty sure using #f leads to infinity being used as a dimension somewhere.

I'd suggest not trying #f as stencil callback for noteheads;  If the
head has no dimension, until where should its stem go?


I'm not sure what failure you guys are seeing.  I'm getting warnings
from the stem code, which does

 Real w = hed->extent (hed, X_AXIS)[dir];

and then

lilypond: skyline.cc:111: void Building::precompute(Real, Real, Real,
Real): Assertion `!isinf (slope_) && !isnan (slope_)' failed.
Aborted (core dumped)


Weird...I'm not sure why ours would segfault in one place whereas yours would hit an assertion error in another.

You're right that the solution is to not use ##f as a stencil. My logic in doing so was trying to create up and down headless stems that lined up horizontally (a transparent notehead shifts these stems by the extent of the notehead). I realize now that there are other ways to do this, so I changed my piece. This bug is listed as critical under the assumption that there should be no segfaults in lilypond resulting from 3 lines of code (lily segfaults all the time when I accidentally feed her a PDF file instead of a .ly file, but I don't consider this to be a bug). However, if you feel that it should be downgraded to high, I could do that as well.

In this case, it seems that the ideal behavior would be to have the stems reach down to the asymptotic point to which stems converge as their note heads get smaller and smaller (try overriding the notehead stencil to be progressively smaller boxes and you'll wee what I mean). I have no clue where in the code this would need to be implemented, though. I can do this task if no one else can, but I'm currently slammed w teaching, moving, and composing for a series of gigs, so if someone else has the hour or two it'd take to propose a non-kludgy solution (I agree that mine is a kludge), please do!

Cheers,
MS

reply via email to

[Prev in Thread] Current Thread [Next in Thread]