Knut Petersen <knut_peter...@t-online.de> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
