lilypond-devel
[Top][All Lists]
Advanced

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

Re: Check for null pointer


From: Reinhold Kainhofer
Subject: Re: Check for null pointer
Date: Sat, 20 Aug 2011 22:00:23 +0200
User-agent: KMail/1.13.6 (Linux/2.6.38-10-generic; KDE/4.7.0; i686; ; )

Am Saturday, 20. August 2011, 19:29:38 schrieb Dan Eble:
> On 2011-08-18, at 10:11 , Carl Sorensen wrote:
> > On 8/17/11 10:41 PM, "Dan Eble" <address@hidden> wrote:
> >> What I have so far is a backtrace:
> >>  http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00494.html
> >> 
> >> and a large amount of input spread across many files, which is why I
> >> chose to review the lilypond source first.
> >> 
> >> It may also be of interest that I am generating PartCombineMusic with
> >> scheme functions other than the stock part combiner.
> >> --
> > 
> > Two questions:
> > 
> > 1) Is the segfault repeatable?
> 
> After extensive testing, the answer is yes, but it's complicated.  It is
> repeatable, but the result doesn't depend only on the input.
> 
> When I build, I prefer to use a program called "color" that captures
> standard output and standard error and highlights the errors.  Here's what
> happens.  In the following list, X is a makefile target, and Y is the
> lilypond command line that "make X" runs.
> 
> color make X   -> crash
> make X         -> OK
> time make X    -> OK
> 
> color Y        -> OK
> Y              -> OK
> time Y         -> OK
> 
> make X 2>err.txt >out.txt  -> OK

So, basically, you are saying that whenever you run "make X" through color, it 
will crash, but it will not crash in any other cases? 
Are you sure this is not a problem of color together with make (I had some 
strange problems that only occured when something was called by make, because 
the locale settings were messed up)?

> > 2) If so, can you test it on the latest development release?
> 
> I tried Graham's experimental 2.15.9 (from last week) and it worked fine at
> first, but then I tried running it via gdb and it crashed with similar but
> not identical backtrace as 2.14.2.  (The caller of kill_mmrest is
> Part_combine_iterator::process instead of Part_combine_iterator::unisono).

Hmm, do you have any example file where this appears (even if it's not 
minimal, for now it's just important that we can reproduce it somehow).

Cheers,
Reinhold


-- 
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org



reply via email to

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