[Top][All Lists]

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

Re: Lilypond 2.19.80-1 hangs

From: Aaron Hill
Subject: Re: Lilypond 2.19.80-1 hangs
Date: Sun, 06 May 2018 02:33:11 -0700
User-agent: Roundcube Webmail/1.3.6

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

eax=0714e550 ebx=0a24c130 ecx=0a24c130 edx=0a289448 esi=0a247f78
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

AddrPC   Params
004EA392 07154BB0 05975BB0 07142110  lilypond.exe!Grob_info::context
004343D4 00000000 00000000 00000000

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

reply via email to

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