Re: Still cannot make doc :(

[David Kastrup]

Knut Petersen <address@hidden> writes:

> Am 29.05.2016 um 13:52 schrieb David Kastrup:
>> I have to see whether I have a chance to run a 64 bit kernel on my
>> system: I used to for a few years (and consequently was able to look
>> at 64 bit code), but the current laptop has an Nvidia card and
>> Ubuntu's kernel/library setup did not manage to integrate the Nvidia
>> proprietary driver stuff into a 64 bit kernel running on a 32bit
>> userland and the free drivers did not work reasonably. Maybe the
>> situation has improved. 
>
> On my i7-4790K valgrind reports 23179 "Conditional jump or move
> depends on uninitialised value(s)"
> and "Use of uninitialised value of size 8" errors from 121 contexts. I
> suspect that the patch that breaks
> "make doc" only exposes an older problem. But 121 context ... that's a
> lot of code to inspect.

The commit in question _does_ change some engraver/translator memory
layouts/sizes.  It is conceivable that some uninitialized memory
previously was reliably stomped over with somewhat-ok values.  And what
might be at bay here is that garbage collection triggers while the
constructor of the Engraver base class is running, and derived_mark
marks values that have not yet been initialized by the constructor of
the derived class.

I don't think we need to inspect all contexts here: the commit in
question changed the engraver/translator _infrastructure_ so it is not
surprising that if there is a problem, it occurs often.

So the 121 contexts will not likely be of more than a few different
kinds.  Can I get some pointers to the routine where the jump occurs,
together with a bit of disassembly for figuring out the actual
corresponding source code?

Or was that information already in one of your reports?

> To those who see "make doc" fail at orchestra.ly: Please report cpu as
> well as versions of gcc and guile. Please also send the output of

I'll start a make doc.  But I suspect we might also have some
Ghostscript problem responsible for some of our problems.  Conveniently,
my Ghostscript is a 32bit version...

-- 
David Kastrup