bug-lilypond
[Top][All Lists]
Advanced

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

Re: Lilypond 2.19.80-1 hangs


From: David Kastrup
Subject: Re: Lilypond 2.19.80-1 hangs
Date: Sun, 06 May 2018 11:02:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Aaron Hill <address@hidden> writes:

> On 2018-05-05 17:01, Aaron Hill wrote:
>> How about this repro:
>>
>> %%%
>> \version "2.19.80"
>> \repeat unfold 36 {
>>   << { e'8 f' } \\ { c'4 } >> d'4
>>   << { g'4. f'8 } \\ { e'16 d' e'4 d'8 } >>
>> }
>> %%%
>>
>> On my machine, I cannot compile this as-is without the LilyPond
>> process ending prematurely with an access violation:
>>
>>> Faulting application name: lilypond.exe, version: 2.19.80.1, time
>>> stamp: 0x0000000b
>>> Faulting module name: lilypond.exe, version: 2.19.80.1, time stamp:
>>> 0x0000000b
>>> Exception code: 0xc0000005
>>> Fault offset: 0x000ea392

On Linux 64bit, I cannot get any of the versions I have to complain,
either using 36 or 360 repetitions.

>> If I lower the repeats to 35 or if I alter the expressions to remove a
>> note (e.g. change { e'8 f' } to { e'4 }), it works.
>>
>> Here are some system details:
>>
>>> Operating System: Windows 10 Pro 64-bit (10.0, Build 16299)
>>> (16299.rs3_release.170928-1534)
>>> Processor: Intel(R) Core(TM)2 Duo CPU     T9500  @ 2.60GHz (2 CPUs)
>>> Memory: 6144MB
>>> Page File: 3362MB used, 3804MB available

Oh man, you went whole hog on your computer.  For my own T61 laptop, I
only went for the second-fastest CPU (T9300) and I never bought any 4GB
DDR2 SODIMM: just outside of my financial reach.

Recently I snapped and got a T420 instead since DDR3 was so much more
affordable that this just seemed a saner option with regard wanting to
be able to work creating videos reasonably comfortably.  Also landed me
with a newer SSD: the SMART values of my old one were getting scary.

I digress.

>> I could install WinDbg and dig in further, if it would help.
>> However, I would need symbols for the Windows build.
>
> So this is a bit of a Heisenbug we have here.  When running under a
> debugger, the access violation does not want to occur.

And none at all on Linux.  Not untypical for garbage collection
problems.

> However, after setting up Dr. MinGW
> (https://github.com/jrfonseca/drmingw) as my post-mortem debugger, I
> was able to get the following:
>
>> lilypond.exe caused an Access Violation at location 00000000004EA392
>> in module lilypond.exe Reading from location 000000000714E55C.
>>
>> Registers:
>> eax=0714e550 ebx=0a24c130 ecx=0a24c130 edx=0a289448 esi=0a247f78
>> edi=00000002
>> eip=004ea392 esp=00b0d7ac ebp=07059948 iopl=0         nv up ei pl nz
>> na po nc
>> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b
>> efl=00010206
>>
>> AddrPC   Params
>> 004EA392 07154BB0 05975BB0 07142110  lilypond.exe!Grob_info::context
>> 004343D4 00000000 00000000 00000000
>> lilypond.exe!Beam_collision_engraver::finalize

Some more backtrace might help.  But it also needs to be a tangible
problem we can reproduce.  Given the lack of ability triggering it on
Linux, I could imagine that a GUB update of the compiler chain might
cause it to disappear.

-- 
David Kastrup



reply via email to

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