|
From: rafael f. <fer...@ya...> - 2011-06-21 23:49:22
|
Hello everyone, Im having some trouble in my program, but I dont know why. It seems to happen before the program execution because before any line of code is executed valgrind prints this. Anyone know why this could be happening? ==2486== Conditional jump or move depends on uninitialised value(s) ==2486== at 0x338C016BD6: index (in /lib64/ld-2.14.so) ==2486== by 0x338C007547: expand_dynamic_string_token (in /lib64/ld-2.14.so) ==2486== by 0x338C007DB9: _dl_map_object (in /lib64/ld-2.14.so) ==2486== by 0x338C00188D: map_doit (in /lib64/ld-2.14.so) ==2486== by 0x338C00E135: _dl_catch_error (in /lib64/ld-2.14.so) ==2486== by 0x338C000F16: do_preload (in /lib64/ld-2.14.so) ==2486== by 0x338C004603: dl_main (in /lib64/ld-2.14.so) ==2486== by 0x338C014143: _dl_sysdep_start (in /lib64/ld-2.14.so) ==2486== by 0x338C004F1D: _dl_start (in /lib64/ld-2.14.so) ==2486== by 0x338C0016B7: ??? (in /lib64/ld-2.14.so) ==2486== ==2486== Conditional jump or move depends on uninitialised value(s) ==2486== at 0x338C016BDB: index (in /lib64/ld-2.14.so) ==2486== by 0x338C007547: expand_dynamic_string_token (in /lib64/ld-2.14.so) ==2486== by 0x338C007DB9: _dl_map_object (in /lib64/ld-2.14.so) ==2486== by 0x338C00188D: map_doit (in /lib64/ld-2.14.so) ==2486== by 0x338C00E135: _dl_catch_error (in /lib64/ld-2.14.so) ==2486== by 0x338C000F16: do_preload (in /lib64/ld-2.14.so) ==2486== by 0x338C004603: dl_main (in /lib64/ld-2.14.so) ==2486== by 0x338C014143: _dl_sysdep_start (in /lib64/ld-2.14.so) ==2486== by 0x338C004F1D: _dl_start (in /lib64/ld-2.14.so) ==2486== by 0x338C0016B7: ??? (in /lib64/ld-2.14.so) Thanks Rafael Louback Ferraz Graduando em Ciência da Computação Universidade Federal de Ouro Preto |
|
From: John R. <jr...@bi...> - 2011-06-22 01:51:04
|
> Im having some trouble in my program, but I dont know why. It seems to happen before the program execution because before any line of code is executed valgrind prints this. Anyone know why this could be happening? > Please state which Linux distribution and release version you are running, along with the version of the C library runtime system (glibc package). Please also state the version of valgrind(memcheck) that you are using. > ==2486== Conditional jump or move depends on uninitialised value(s) > ==2486== at 0x338C016BD6: index (in /lib64/ld-2.14.so) > ==2486== by 0x338C007547: expand_dynamic_string_token (in /lib64/ld-2.14.so) > ==2486== by 0x338C007DB9: _dl_map_object (in /lib64/ld-2.14.so) > ==2486== by 0x338C00188D: map_doit (in /lib64/ld-2.14.so) > ==2486== by 0x338C00E135: _dl_catch_error (in /lib64/ld-2.14.so) > ==2486== by 0x338C000F16: do_preload (in /lib64/ld-2.14.so) > ==2486== by 0x338C004603: dl_main (in /lib64/ld-2.14.so) > ==2486== by 0x338C014143: _dl_sysdep_start (in /lib64/ld-2.14.so) > ==2486== by 0x338C004F1D: _dl_start (in /lib64/ld-2.14.so) > ==2486== by 0x338C0016B7: ??? (in /lib64/ld-2.14.so) Another name for 'index' is 'strrchr'. The code at 0x338C016BD6 is part of a super-optimized sequence which uses speculative 8-byte fetches in order to speed up execution in contrast to byte-by-byte search. The fetch often exceeds the initialized region, but the rest of the code is careful enough to ignore the contents of the uninitialized bytes. Memcheck does not understand this code fully, so usually memcheck intercepts 'index' in advance, and replaces it with simpler code which memcheck does understand. For your Linux distribution and release version and glibc version, then this interception did not work as expected, and so memcheck gets lost temporarily. If desired, you could write a suppression rule so that memcheck will ignore the case of 'index' (or 'strrchr') when called from 'expand_dynamic_string_token' within ld-2.14.so. -- |
|
From: John R. <jr...@bi...> - 2011-06-26 21:01:28
|
On 06/25/2011 11:16 AM, rafael ferraz wrote: > ==2486== Conditional jump or move depends on uninitialised value(s) > ==2486== at 0x338C016BD6: index (in /lib64/ld-2.14.so) > ==2486== by 0x338C007547: expand_dynamic_string_token (in /lib64/ld-2.14.so) > This could be classified as a bug? I need to report it? Yes, it is a bug. Memcheck failed to intercept this call to 'index'. The interception is necessary because the actual code for 'index' is too complicated for memcheck to check easily, which causes many false-positive error reports (such as the one above.) When the interception works, then memcheck re-directs the execution to equivalent code which is easier to check with no false-positive reports of errors. See http://valgrind.org/support/bug_reports.html for reporting the bug. Search first to see if somebody else already has reported this problem. If not, then go ahead and enter a bug report. You'll need to identify which Linux distribution and release, the version of the C library runtime system, and the version of valgrind that you are using. -- |