"Christophe Limbrée" <[EMAIL PROTECTED]> writes: > Paul Pluzhnikov a écrit : > >> You have a bug, and valgrind will likely show it to you immediately, >> so why don't you stop wasting time hypothesisizing what the problem >> might be, and use proper tools to find it. > > Valgring said: > > ==16807== LEAK SUMMARY: > ==16807== definitely lost: 0 bytes in 0 blocks. > ==16807== possibly lost: 0 bytes in 0 blocks. > ==16807== still reachable: 35182 bytes in 15 blocks. > ==16807== suppressed: 0 bytes in 0 blocks. > Segmentation fault > > Do I have to understand that there is no problem?
There are no leaks, but you obviously *do* have a (different) problem. > And before > > ==16807== Use of uninitialised value of size 4 > ==16807== at 0x8049217: main (in /home/lch/SRC/TCOV/ECXX/ecxx) Rebuild your executable with '-g', and valgrind will tell you file name and line number. As Alan Woodland suggests, uninintialized pointer is most likely cause. > And finally I have no idea where the fault can be. Valgrind told you which instruction the fault is in. If you don't know how to translate that to your own code, build debug version of your executable, and it will tell you which line of code is at fault. > The fact is that if > I use myclass instance(param, ...), I don't have the problem. Yes, you do. It just happens to remain hidden. > Maybe because I link a .o that I have created. Yes, that's likely the *root* cause of all problems. After all, if you don't write any code at all, then there could be no bugs in your code :) Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gplusplus
