Sure, that's precisely what I think the error means. I'm just saying I
have code where I don't see anything like this, but valgrind still
reports the error.
The code is quite complex I'm probably just missing something
somewhere. I mean here is essentially the part which causes the error:
result = 1;
for (unsigned long i = 0; (i < test_mpn_poly->limbs) && (result == 1);
i++)
{
result = (coeff1[i] == coeff2[i]);
}
This is run after setting all the entries in coeff1 to equal those in
coeff2. Essentially that code looks as follows:
FLINT_ASSERT(poly->limbs >= size);
copy_limbs(poly->coeffs+n*(poly->limbs+1)+1, x, size); // size
limbs
poly->coeffs[n*(poly->limbs+1)] = sign; // first limb
if (poly->limbs > size)
clear_limbs(poly->coeffs+n*(poly->limbs+1)+size+1, poly->limbs-
size); // remaining limbs
In short I don't see how there is scope for the error valgrind
reports. Both i and result are initialised and every entry of coeff1
is set to something and test_mpn_poly->limbs is set to something when
the polynomial is initialised. Nevertheless, in context at least, this
code gives the error mentioned.
Bill.
On 20 Aug, 20:07, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> On Aug 20, 8:10 pm, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > Getting rid of memory leaks also speeds up code dramatically as I
> > found out recently. When new memory is allocated by the kernel, it
> > isn't quite ready to be used. As you begin writing to it, pages of
> > roughly 4kb at a time initiate an interrupt which the kernel has to
> > deal with, called a minor page fault. These take quite some time to
> > deal with. So using more and more memory results in more and more
> > minor page faults. So there is definite benefit in killing memory
> > leaks, even less serious ones.
>
> Hey Bill,
>
> > However, there is one "error" which valgrind reports on my own code
> > from time to time which I have been unable to determine the source of.
> > It says something like "conditional jump depends on uninitialised
> > data". I have stared at code for hours trying to determine where these
> > errors come from. I still have code for which I have been unable to
> > eliminate such errors.
>
> That usually happens in the following circumstance:
>
> int i; // this is initialized to zero on any sane system, i.e.
> anywhere but Windows :)
>
> if (i>0)
> do something;
>
> Now valgrind assumes that "conditional jump depends on uninitialised
> data", i.e. "i". Well, but it is zero anyway would one say. And you
> would be correct in 99% of all cases, but I fixed a bug very similar
> to the above in LinBox about 4 weeks ago that caused a crash on Debian
> unstable's gcc but not with the other 10 compilers I tried. Lesson
> lerned. The assigment to zero puts i into another segment, so many
> people avoid it.
>
> > I understand the meaning of the error as such, but couldn't determine
> > why valgrind thought that part of my code contained such an error.
> > Perhaps valgrind is not infallible, or perhaps I've been missing
> > something.
>
> > Bill.
>
> Cheers,
>
> Michael
>
> <SNIP>
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
