valgrind: "Conditional jump or move depends on uninitialised value(s)" in charpoly()

327 views

Skip to first unread message

Volker Braun

unread,

Dec 23, 2010, 7:11:19 AM12/23/10

to linbo...@googlegroups.com

First, linbox-1.1.7 definitely does not compile with givaro-3.2.13 in contrast to what ./configure says. It compiles fine with givaro-3.3.0.

Second, and more importantly, I am running the following minimal example program in valgrind:

======= snip on =========

#include <linbox/util/commentator.h>

namespace LinBox {

Commentator commentator(std::cout);

}

#include <linbox/integer.h>

#include <linbox/field/modular.h>

#include <linbox/blackbox/sparse.h>

#include <linbox/ring/givaro-polynomial.h>

#include <linbox/solutions/charpoly.h>

using namespace LinBox;

int main(void)

{

const int nrows = 64;

const int ncols = 64;

for (int i=0; i<99; i++) {

PID_integer ZZ;

DenseMatrix<PID_integer> A(ZZ, nrows, ncols);

for (size_t i = 0; i < nrows; i++) {

for (size_t j = 0; j < ncols; j++) {

A.setEntry(i, j, rand() % 100 - 50);

}

GivPolynomialRing<PID_integer,Dense>::Element m_A;

// charpoly(m_A, A, Method::Blackbox()); // this works fine in valgrind

charpoly(m_A, A); // valgrind complains about this

}

return 0;

}

====== snip off ==========

I am getting the following warning about uninitialized values:

====== snip on ===========

[vbraun@volker-desktop linbox-test]$ valgrind ./linbox-test |& head -50

==11203== Memcheck, a memory error detector

==11203== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info

==11203== Command: ./linbox-test

==11203==

DenseMatrix Integer Charpoly...

Integer Dense Charpoly ...

Integer Minpoly...

Modular vectorized iteration...

Convertion to BLAS Minimal polynomial...

done (0.046992 s)

Modular Dense Minpoly ...

==11203== Conditional jump or move depends on uninitialised value(s)

==11203== at 0x3043A0EDFB: __ieee754_fmod (e_fmod.c:49)

==11203== by 0x3043A24F14: fmod (w_fmod.c:36)

==11203== by 0x405708: LinBox::Modular<double>::init(double&, double) const (modular-double.h:202)

==11203== by 0x407FAF: void LinBox::FFLAS::MatVectProd<LinBox::Modular<double> >(LinBox::Modular<double> const&, LinBox::FFLAS::FFLAS_TRANSPOSE, unsigned long, unsigned long, LinBox::Modular<double>::Element, LinBox::Modular<double>::Element const*, unsigned long, LinBox::Modular<double>::Element const*, unsigned long, LinBox::Modular<double>::Element, LinBox::Modular<double>::Element*, unsigned long) (fflas_fgemv.inl:286)

==11203== by 0x411F2E: void LinBox::FFLAS::fgemv<LinBox::Modular<double> >(LinBox::Modular<double> const&, LinBox::FFLAS::FFLAS_TRANSPOSE, unsigned long, unsigned long, LinBox::Modular<double>::Element, LinBox::Modular<double>::Element const*, unsigned long, LinBox::Modular<double>::Element const*, unsigned long, LinBox::Modular<double>::Element, LinBox::Modular<double>::Element*, unsigned long) (fflas_fgemv.inl:50)

==11203== by 0x4406B3: unsigned long LinBox::FFPACK::LUdivine_construct<LinBox::Modular<double> >(LinBox::Modular<double> const&, LinBox::FFLAS::FFLAS_DIAG, unsigned long, unsigned long, LinBox::Modular<double>::Element const*, unsigned long, LinBox::Modular<double>::Element*, unsigned long, LinBox::Modular<double>::Element*, unsigned long*, bool, LinBox::FFPACK::FFPACK_MINPOLY_TAG, unsigned long, unsigned long, unsigned long) (ffpack_ludivine.inl:639)

==11203== by 0x4405D7: unsigned long LinBox::FFPACK::LUdivine_construct<LinBox::Modular<double> >(LinBox::Modular<double> const&, LinBox::FFLAS::FFLAS_DIAG, unsigned long, unsigned long, LinBox::Modular<double>::Element const*, unsigned long, LinBox::Modular<double>::Element*, unsigned long, LinBox::Modular<double>::Element*, unsigned long*, bool, LinBox::FFPACK::FFPACK_MINPOLY_TAG, unsigned long, unsigned long, unsigned long) (ffpack_ludivine.inl:630)

==11203== by 0x43CEA7: std::vector<double, std::allocator<double> >& LinBox::FFPACK::MinPoly<LinBox::Modular<double>, std::vector<double, std::allocator<double> > >(LinBox::Modular<double> const&, std::vector<double, std::allocator<double> >&, unsigned long, LinBox::Modular<double>::Element const*, unsigned long, LinBox::Modular<double>::Element*, unsigned long, unsigned long*, LinBox::FFPACK::FFPACK_MINPOLY_TAG, unsigned long, unsigned long, unsigned long) (ffpack_minpoly.inl:45)

[...]

======= snip off =====

I checked that this happens with linbox-1.1.6 and linbox-1.1.7. Any advice would be appreciated!

My original problem is that linbox is crashing with atlas-3.9.32. Although this is a development version of atlas, its developer has told the Sage project that he considers it good enough for daily use. While trying to isolate the problem, I ran into "conditional jump or move depends on uninitialized value" warnings in valgrind. This warning actually occurs with the stable version of atlas as well, so its probably not atlas' fault.

Best wishes,

Volker

Brice Boyer

unread,

Dec 23, 2010, 8:55:47 AM12/23/10

to Volker Braun, linbo...@googlegroups.com

Hello !

2010/12/23 Volker Braun <vbraun.name@gmail.com>

First, linbox-1.1.7 definitely does not compile with givaro-3.2.13 in contrast to what ./configure says. It compiles fine with givaro-3.3.0.

That's true (and it's been "fixed" in svn).

Second, and more importantly, I am running the following minimal example program in valgrind:

That seems to be fixed in latest Givaro/Linbox from cvs/svn. (valgrind says :

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

==9414== Memcheck, a memory error detector

==9414== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info

==9414== Command: ./braun

==9414==

==9414== Invalid free() / delete / delete[]

==9414== at 0x4A06A42: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)

==9414== by 0x3F90B14B4A: free_mem (in /lib64/libc-2.12.1.so)

==9414== by 0x3F90B146F1: __libc_freeres (in /lib64/libc-2.12.1.so)

==9414== by 0x480158C: _vgnU_freeres (in /usr/lib64/valgrind/vgpreload_core-amd64-linux.so)

==9414== by 0x3F90A3535C: __run_exit_handlers (in /lib64/libc-2.12.1.so)

==9414== by 0x3F90A35404: exit (in /lib64/libc-2.12.1.so)

==9414== by 0x3F90A1ECE3: (below main) (in /lib64/libc-2.12.1.so)

==9414== Address 0x4e96bd0 is not stack'd, malloc'd or (recently) free'd

==9414==

==9414== HEAP SUMMARY:

==9414== in use at exit: 0 bytes in 0 blocks

==9414== total heap usage: 1,385,419 allocs, 1,385,420 frees, 320,400,505 bytes allocated

==9414==

==9414== All heap blocks were freed -- no leaks are possible

==9414==

==9414== For counts of detected and suppressed errors, rerun with: -v

==9414== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(the error is something weird on my computer)

However, I realised that when linbox is configured with --with-ntl, then there are *many* memory leaks remaining.

emerging it right now to check...

Maybe it's a good idea if we release linbox-1.1.7-rc1 ? (there is already a givaro-3.3.4-rc0) It's been a year since rc0...

Although this is a development version of atlas, its developer has told the Sage project that he considers it good enough for daily use. While trying to isolate the problem, I ran into "conditional jump or move depends on uninitialized value" warnings in valgrind. This warning actually occurs with the stable version of atlas as well, so its probably not atlas' fault.

Best wishes,
Volker

--
You received this message because you are subscribed to the Google Groups "linbox-use" group.
To post to this group, send email to linbo...@googlegroups.com.
To unsubscribe from this group, send email to linbox-use+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/linbox-use?hl=en.

--
Brice Boyer.
____________________________________________________________
brice...@imag.fr Tél. +33(0)4 76 51 45 61
Université Joseph Fourier, Grenoble I.
Laboratoire Jean Kuntzmann, Mathématiques Appliquées et Informatique
LJK - UJF BP53 38041 Grenoble cedex FRANCE
http://ljk.imag.fr/membres/Brice.Boyer
____________________________________________________________

Volker Braun

unread,

Dec 23, 2010, 10:20:45 AM12/23/10

to linbo...@googlegroups.com, Volker Braun

Thanks for the quick reply!

I (and the Sage project) do indeed configure linbox --with-ntl. Is this bad/unsupported? Since Sage already ships with NTL it seemed like a good idea, plus the characteristic polynomial of an integer matrix is found a lot faster.

===== linbox without NTL ===========

Integer Charpoly...

Integer Dense Charpoly : No NTL installation -> chinese remaindering...

Modular vectorized iteration...

Modular Dense Charpoly ...

done (0.380942 s)

[...]

===== linbox --with-ntl =============

DenseMatrix Integer Charpoly...

Integer Dense Charpoly ...

Integer Minpoly...

Modular vectorized iteration...

Convertion to BLAS Minimal polynomial...

Modular Dense Minpoly...

[...]

================================

Running in valgrind, I still get the same "Conditional jump or move depends on uninitialised value(s)" warnings in linbox-svn if I enable NTL. If I disable NTL neither linbox-1.1.7 nor the svn version give the warning, but it computes the characteristic polynomial a lot slower.

For the record, I used givaro-3.3.0 is all cases. Looking at the stack backtrace, it doesn't seem like givaro plays any role in the "conditional jump warning".