Re: Lilypond 2.17.26 coredumps on tuplet with only skips

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Rutger Hofman <address@hidden> writes:
>>
>>> On 09/12/2013 10:54 AM, Thomas Morley wrote:
>>
>>>> programming error: stopped tuplet bracket has neither left nor right bound
>>>> no segfaut, though.
>>>
>>> It reports this error but does not core dump.
>>
>> For what it's worth, I'm bisecting now.  More a matter of curiosity than
>> anything else, though: the backtrace should in all likelihood be
>> sufficient for pinpointing the problem in the current code base.
>
> Well, actually the code calling a member function with a null pointer
> has not been changed in a long time, so the culprit for the change in
> behavior is hidden well enough to warrant looking for the commit.

Looks like just another side effect of

74e4d219b24ec6d6f28d663c0285418e6c8e122e is the first bad commit
commit 74e4d219b24ec6d6f28d663c0285418e6c8e122e
Author: Mike Solomon <address@hidden>
Date:   Tue Mar 5 21:03:55 2013 +0100

    Uses only unpure-pure containers to articulate unpure-pure relationships 
(issue 3199)
    
    Previously, LilyPond used several different lists in define-grobs.scm
    to define relationships between unpure and pure functions.  This patch
    eliminates these lists, using unpure-pure containers to articulate
    these relationships.
    
    The modifications required to implement this change are described below:
    
    -) axis-group-interface.cc
    A Scheme function is no longer needed to determine pure relevant grobs.
    All grobs can have their Y-extents meaningfully pure-evaluated now. The
    worst-case scenario is that they evaluate to false. Dead grobs, on the
    other hand, are never pure relevant. The calls to is_live are the only
    holdovers from the old pure-relevant? scheme function.
    
    -) grob-closure.cc
    We allow unpure-pure containers in simple closures.
    
    -) grob-property.cc
    call_pure_function no longer looks up a Scheme module. Because there are
    no hard-coded lists in Scheme any more, the function is smaller and
    writing it in C++ gets slight efficiency gains.
    
    -) grob.cc
    pure_stencil_height used to be a Scheme function in define-grobs.scm.
    Because it is much simpler (it no longer makes references to lists defined
    in Scheme), it can be implemented in C++.
    
    -) pure-from-neighbor-engraver.cc
    Similar to axis-group-interface.cc, the pure-relevant distinction is
    no longer important.
    
    -) side-position-interface.cc
    In order to avoid issues with alterBroken, we only check pure properties
    before line breaking.
    
    -) simple-closure.cc
    Simple closures were incorrectly evaluated when containing unpure-pure
    containers. This rectifies that.
    
    -) stencil-integral.cc
    Several pure equivalent functions needed to be written for skylines.
    
    -) define-grobs.scm
    Multiple overrides must be changed to unpure-pure containers. Previous
    hard-coded lists are all deleted and several functions moved to C++ (see
    above).
    
    -) output-lib.scm
    Several common unpure-pure containers used in define-grobs.scm are
    defined here. Several functions from define-grobs.scm pertaining to
    grob offsets are moved to this file.

:040000 040000 69f10e267f63d1c3315e91557e9a61658a04c53b 
7f47f318dd89f2e1768860293c1ed86c1fa23114 M      input
:040000 040000 7d0fce689cff49901f19d3ba182f253f6c27338b 
4739327adefbb80fee3aa1e3c5b36a1ade66f595 M      lily
:040000 040000 1c9e860a272a4b38f36526023369319afd97820d 
3ff043eb2e0349161f551d615ddbc2ee13387a2c M      ly
:040000 040000 2cfacbdbf1649347fd715b20a1d3afbdc15deb8e 
dcc4ac6d62edc606de038cac934da023971574d1 M      scm


-- 
David Kastrup