[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 09:53:23 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
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
- Re: Still cannot make doc :(, (continued)
- Re: Still cannot make doc :(, Werner LEMBERG, 2016/05/28
- Re: Still cannot make doc :(, Thomas Morley, 2016/05/28
- Re: Still cannot make doc :(, Thomas Morley, 2016/05/29
- Re: Still cannot make doc :(, Thomas Morley, 2016/05/29
- Re: Still cannot make doc :(, James Lowe, 2016/05/29
- Re: Still cannot make doc :(, David Kastrup, 2016/05/29
- Re: Still cannot make doc :(, David Kastrup, 2016/05/29
- Re: Still cannot make doc :(, Thomas Morley, 2016/05/29
- Re: Still cannot make doc :(, David Kastrup, 2016/05/29
- Re: Still cannot make doc :(, Knut Petersen, 2016/05/30
- Re: Still cannot make doc :(,
David Kastrup <=
- Re: Still cannot make doc :(, Masamichi Hosoda, 2016/05/30
- Re: Still cannot make doc :(, James, 2016/05/30
- Re: Still cannot make doc :(, David Kastrup, 2016/05/30
- Re: Still cannot make doc :(, James, 2016/05/30
- Re: Still cannot make doc :(, David Kastrup, 2016/05/30
- Re: Still cannot make doc :(, James, 2016/05/30
- Re: Still cannot make doc :(, David Kastrup, 2016/05/30
- Re: Still cannot make doc :(, David Kastrup, 2016/05/31
- Re: Still cannot make doc :(, Colin Campbell, 2016/05/30
- Re: Still cannot make doc :(, Thomas Morley, 2016/05/29