Hi Bill,
What you may be seeing is Valgrind not being able to detect the memory
aliasing you're using in that complex loop condition ((i <
test_mpn_poly->limbs) && (result == 1)). If you can re-create this
exact error using a similar snipet of code in a tiny example program,
it would be worth sending to the Valgrind folks.
Or, it could be that Valgrind is detecting when you're
test_mpn_poly->limbs hasn't been set :-)
--jason
On 8/21/07, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> 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/
-~----------~----~----~----~------~----~------~--~---
