Re: Strange error with no traceable cause.

[David Kastrup]

address@hidden writes:

> ​Sent with ProtonMail Secure Email.​
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On 5 June 2018 2:33 PM, David Kastrup <address@hidden> wrote:
>
>> address@hidden writes:
>> 
>> > I'm working on a large score using 2.21.0, parts all separated into
>> > 
>> > different files and such, suddenly, after adding a bar for the 3rd
>> > 
>> > clarinet, this shows up:
>> > 
>> > Parsing...
>> > 
>> > Interpreting music...[8][16]ERROR: In procedure ly:trampoline:
>> > 
>> > ERROR: Wrong type argument in position 3 (expecting Translator):
>> > 
>> > #<freed cell 0x7fe355b5e220; GC missed a reference>
>> > 
>> > I have no idea why this is happening. All the other parts add fine
>> > 
>> > but, as soon as the bar is added for that particular instrument, the
>> > 
>> > error shows up.
>> > 
>> > However, if you engrave with verbose output on Frescobaldi
>> > 
>> > enabled...the error doesn't show up. Disable that and do normal
>> > 
>> > engraving...Same error.
>> > 
>> > Any ideas on what's causing it or it might be a Fescobaldi bug?
>> 
>> This is an error in the internals of the memory organization of
>> 
>> LilyPond. Which platform are you using this on, and which version of
>> 
>> Guile has been compiled into it?
>> 
>> Basically the output of
>> 
>> ldd `which lilypond`
>> 
>> should be sufficient for answering this question if you have no clue
>> 
>> what I am talking about.
>> 
>> 
>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> 
>> David Kastrup
>
> Output of ldd `which lilypond`:
>
> linux-vdso.so.1 (0x00007ffd29e4c000)
>       libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f47a901a000)
>       libguile.so.17 => /usr/lib/libguile.so.17 (0x00007f47a8d1d000)

[...]

64bit Linux, Guile 1.8.  That is a combination that really should work.
Any chance to be running this under gdb and/or create a backtrace from a
core dump?

Basically it would be nice to figure out what kind of code this is
happening in in order to figure out what kind of memory became collected
prematurely.  The actual bug unfortunately is not really connected with
the code executed at this time: it triggers an indeterminate time before
that and the responsible code is code that someone forgot to write.

But at least knowing what kind of data structure might be affected would
be a kind of clue how to narrow done the missing code.

-- 
David Kastrup