lilypond-devel
[Top][All Lists]
Advanced

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

Re: Still cannot make doc :(


From: David Kastrup
Subject: Re: Still cannot make doc :(
Date: Mon, 30 May 2016 17:59:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

James <address@hidden> writes:

> Hello
>
> On 30/05/16 15:06, David Kastrup wrote:
>> James <address@hidden> writes:
>>
>>> Zipped Valgrind output of both OSes is attached to this email or can
>>> be obtained here:
>>>
>>> https://drive.google.com/file/d/0B9nZ5LHV2Ds6dGU5VTJjOGNlSm8/view?usp=sharing
>> By far most complaints are in the GC marking phase and complain about
>> uninitialized values in stack allocations.  That's perfectly to be
>> expected with a conservative garbage collector, however.  I'm taking a
>> look at the heap-related complaints though since on the heap, GC should
>> not occur conservatively (not in Guile-1 at least).
>>
> In the meantime I have installed 32bit LilyDev at work and am
> currently setting all that up and will run a 'staging merge' now -
> this will bring staging and master up to date hopefully, verify that
> LilyDev works for me (i.e. I have it all configured properly - nice
> job by the way Federico, I haven't used LD for a while).
>
> If it does then I guess I can get some of these new patches tested and
> moved along - but that may be tomorrow, it just depends how much time
> I get today.

Ok,

==15261== 3774 errors in context 100 of 100:
==15261== Conditional jump or move depends on uninitialised value(s)
==15261==    at 0x4E923D3: scm_i_sweep_card (in /usr/lib/libguile.so.17.4.0)
==15261==    by 0x4E91255: scm_i_sweep_some_cards (in 
/usr/lib/libguile.so.17.4.0)
==15261==    by 0x4E916EC: scm_i_sweep_some_segments (in 
/usr/lib/libguile.so.17.4.0)
==15261==    by 0x4E907AE: scm_gc_for_newcell (in /usr/lib/libguile.so.17.4.0)
==15261==    by 0x4EDDF3E: scm_c_make_vector (in /usr/lib/libguile.so.17.4.0)
==15261==    by 0x4E9C62C: ??? (in /usr/lib/libguile.so.17.4.0)
==15261==    by 0x59D525: Scheme_hash_table::make_smob() (scm-hash.cc:29)
==15261==    by 0x643B51: add_acknowledger(scm_unused_struct*, char const*, 
Protected_scm&) (translator.cc:238)
==15261==    by 0x72DEAD: Dots_engraverrhythmic_head_ack_adder() 
(dots-engraver.cc:59)
==15261==    by 0x4DDEF8: ly_init_ly_module() (guile-init.cc:57)
==15261==    by 0x76710E: call_trampoline(void*) (lily-modules.cc:61)
==15261==    by 0x4E8DC01: scm_c_with_fluid (in /usr/lib/libguile.so.17.4.0)
==15261==  Uninitialised value was created by a stack allocation
==15261==    at 0x4EDC7C4: scm_c_catch (in /usr/lib/libguile.so.17.4.0)

looks like a red flag concerning the relation to the patch in question..
It's a bit strange that all reported calls seem to be from the same
Dots_engraverrhythmic_head_ack_adder but then this may not mean more
than garbage collection being triggered inside of
Dots_engraverrhythmic_head_ack_adder coincidentally during startup and
it is just bad/good luck that this happens/not at this location on 64/32
bit.

But when it happens, we may have a problem.  Now on to disassembly
and/or code analysis.

-- 
David Kastrup



reply via email to

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