Re: Lilypond 2.19.80-1 hangs

[Aaron Hill]

On 2018-05-06 02:02, David Kastrup wrote:
> > > 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.

Yeah.  This is a 9-year-old Dell XPS M1530 laptop that, while rapidly 
approaching its end of life, still works just enough to use on a daily 
basis.

> > 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.

No luck in getting anything else.  Neither mingw-gdb nor WinDbg can read 
the debugging information for the executable.  To be fair, I wouldn't 
have expected WinDbg to work on gcc-built code, but I am actually 
surprised Dr. MinGW was able to provide what it did.  Regardless, all 
debuggers do seem to agree that there are only two entries in the call 
stack.  Perhaps the `-fno-omit-frame-pointer` option needed to be used 
when compiling, or this might point to corruption of the call stack 
itself.

At this point, I concur that it is probably not worth spending any more 
time if it cannot be reproduced reliably and on other platforms.

-- Aaron Hill