Re: Still cannot make doc :(

[James]

On 30/05/16 16:59, David Kastrup wrote:
> 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.

Oh Well, Lilydev complains about the same make doc error  when (I use 
-j5) - I am 99% sure, I haven't time now to look at the full output, but 
the messages generated on the console are so familiar that I am almost 
sure it is the same thing.

I have to leave now for Home.

To all those waiting on their patches I guess you'll have to be patient 
a bit more.

I'll do the countdown as promised tomorrow but I still cannot push - at 
least not reliably.

David if you need anything from any of these outputs on my machines here 
at work, let me know and I'll do whatever tests or output that you think 
might be helpful.

Hope the Nettle-reaping was successful.

James

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