Hide Forgot
Description of problem: I'm getting now these reports from glibc when I use strerror(0); Conditional jump or move depends on uninitialised value(s) at 0x5B6075B: __GI___strcasecmp_l (strcmp.S:243) by 0x5AF84C2: __gconv_open (gconv_open.c:70) by 0x5B06629: _nl_find_msg (dcigettext.c:974) by 0x5B06DC4: __dcigettext (dcigettext.c:640) by 0x5B5CA6D: strerror_r (_strerror.c:73) by 0x5B5C96D: strerror (strerror.c:33) by 0x49CA4D: _memlock_maps (memlock.c:258) by 0x49CDF6: _lock_mem (memlock.c:331) by 0x49D18E: _lock_mem_if_needed (memlock.c:382) by 0x49D290: critical_section_inc (memlock.c:407) by 0x443767: _lv_activate (activate.c:1608) by 0x4438EF: lv_activate_with_filter (activate.c:1641) by 0x4BCA4D: _file_lock_resource (file_locking.c:307) by 0x468F3D: _lock_vol (locking.c:387) by 0x469227: lock_vol (locking.c:464) by 0x4871A7: _init_mirror_log (mirror.c:328) by 0x48B9FE: _set_up_mirror_log (mirror.c:1872) by 0x48BE72: add_mirror_log (mirror.c:1963) by 0x47741E: _lv_create_an_lv (lv_manip.c:4274) by 0x478459: lv_create_single (lv_manip.c:4482) by 0x41FA10: lvcreate (lvcreate.c:1089) by 0x4255F1: lvm_run_command (lvmcmdline.c:1184) by 0x426538: lvm2_main (lvmcmdline.c:1550) by 0x43EE2F: main (lvm.c:21) Uninitialised value was created by a stack allocation at 0x5AF83DD: __gconv_open (gconv_open.c:65) Use of uninitialised value of size 8 at 0x5B62894: __GI___strcasecmp_l (strcmp.S:2257) by 0x5AF84C2: __gconv_open (gconv_open.c:70) by 0x5B06629: _nl_find_msg (dcigettext.c:974) by 0x5B06DC4: __dcigettext (dcigettext.c:640) by 0x5B5CA6D: strerror_r (_strerror.c:73) by 0x5B5C96D: strerror (strerror.c:33) by 0x49CA4D: _memlock_maps (memlock.c:258) by 0x49CDF6: _lock_mem (memlock.c:331) by 0x49D18E: _lock_mem_if_needed (memlock.c:382) by 0x49D290: critical_section_inc (memlock.c:407) by 0x443767: _lv_activate (activate.c:1608) by 0x4438EF: lv_activate_with_filter (activate.c:1641) by 0x4BCA4D: _file_lock_resource (file_locking.c:307) by 0x468F3D: _lock_vol (locking.c:387) by 0x469227: lock_vol (locking.c:464) by 0x4871A7: _init_mirror_log (mirror.c:328) by 0x48B9FE: _set_up_mirror_log (mirror.c:1872) by 0x48BE72: add_mirror_log (mirror.c:1963) by 0x47741E: _lv_create_an_lv (lv_manip.c:4274) by 0x478459: lv_create_single (lv_manip.c:4482) by 0x41FA10: lvcreate (lvcreate.c:1089) by 0x4255F1: lvm_run_command (lvmcmdline.c:1184) by 0x426538: lvm2_main (lvmcmdline.c:1550) by 0x43EE2F: main (lvm.c:21) Uninitialised value was created by a stack allocation at 0x5AF83DD: __gconv_open (gconv_open.c:65) Use of uninitialised value of size 8 at 0x5B62898: __GI___strcasecmp_l (strcmp.S:2258) by 0x5AF84C2: __gconv_open (gconv_open.c:70) by 0x5B06629: _nl_find_msg (dcigettext.c:974) by 0x5B06DC4: __dcigettext (dcigettext.c:640) by 0x5B5CA6D: strerror_r (_strerror.c:73) by 0x5B5C96D: strerror (strerror.c:33) by 0x49CA4D: _memlock_maps (memlock.c:258) by 0x49CDF6: _lock_mem (memlock.c:331) by 0x49D18E: _lock_mem_if_needed (memlock.c:382) by 0x49D290: critical_section_inc (memlock.c:407) by 0x443767: _lv_activate (activate.c:1608) by 0x4438EF: lv_activate_with_filter (activate.c:1641) by 0x4BCA4D: _file_lock_resource (file_locking.c:307) by 0x468F3D: _lock_vol (locking.c:387) by 0x469227: lock_vol (locking.c:464) by 0x4871A7: _init_mirror_log (mirror.c:328) by 0x48B9FE: _set_up_mirror_log (mirror.c:1872) by 0x48BE72: add_mirror_log (mirror.c:1963) by 0x47741E: _lv_create_an_lv (lv_manip.c:4274) by 0x478459: lv_create_single (lv_manip.c:4482) by 0x41FA10: lvcreate (lvcreate.c:1089) by 0x4255F1: lvm_run_command (lvmcmdline.c:1184) by 0x426538: lvm2_main (lvmcmdline.c:1550) by 0x43EE2F: main (lvm.c:21) Uninitialised value was created by a stack allocation at 0x5AF83DD: __gconv_open (gconv_open.c:65) Version-Release number of selected component (if applicable): glibc-2.14.90-10.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Still applies for glibc-2.14.90-16.x86_64 i.e.: Conditional jump or move depends on uninitialised value(s) at 0x551162B: __GI___strcasecmp_l (strcmp.S:243) by 0x54BED31: bsearch (bsearch.c:38) by 0x54BA326: _nl_expand_alias (localealias.c:160) by 0x54B83A7: _nl_find_domain (finddomain.c:120) by 0x54B7AD2: __dcigettext (dcigettext.c:628) by 0x550D61D: strerror_r (_strerror.c:73) by 0x550D51D: strerror (strerror.c:33) by 0x4E61C22: _do_dm_ioctl (libdm-iface.c:1664) by 0x4E6225B: dm_task_run (libdm-iface.c:1757) by 0x4E602D7: _create_and_load_v4 (libdm-iface.c:1291) by 0x4E61E4B: dm_task_run (libdm-iface.c:1722) by 0x40422A: _create (dmsetup.c:669) by 0x40AEB7: main (dmsetup.c:3512) Uninitialised value was created by a stack allocation at 0x54B7A5E: __dcigettext (dcigettext.c:575) Use of uninitialised value of size 8 at 0x5513764: __GI___strcasecmp_l (strcmp.S:2257) by 0x54BED31: bsearch (bsearch.c:38) by 0x54BA326: _nl_expand_alias (localealias.c:160) by 0x54B83A7: _nl_find_domain (finddomain.c:120) by 0x54B7AD2: __dcigettext (dcigettext.c:628) by 0x550D61D: strerror_r (_strerror.c:73) by 0x550D51D: strerror (strerror.c:33) by 0x4E61C22: _do_dm_ioctl (libdm-iface.c:1664) by 0x4E6225B: dm_task_run (libdm-iface.c:1757) by 0x4E602D7: _create_and_load_v4 (libdm-iface.c:1291) by 0x4E61E4B: dm_task_run (libdm-iface.c:1722) by 0x40422A: _create (dmsetup.c:669) by 0x40AEB7: main (dmsetup.c:3512) Uninitialised value was created by a stack allocation at 0x54B7A5E: __dcigettext (dcigettext.c:575) Use of uninitialised value of size 8 at 0x5513768: __GI___strcasecmp_l (strcmp.S:2258) by 0x54BED31: bsearch (bsearch.c:38) by 0x54BA326: _nl_expand_alias (localealias.c:160) by 0x54B83A7: _nl_find_domain (finddomain.c:120) by 0x54B7AD2: __dcigettext (dcigettext.c:628) by 0x550D61D: strerror_r (_strerror.c:73) by 0x550D51D: strerror (strerror.c:33) by 0x4E61C22: _do_dm_ioctl (libdm-iface.c:1664) by 0x4E6225B: dm_task_run (libdm-iface.c:1757) by 0x4E602D7: _create_and_load_v4 (libdm-iface.c:1291) by 0x4E61E4B: dm_task_run (libdm-iface.c:1722) by 0x40422A: _create (dmsetup.c:669) by 0x40AEB7: main (dmsetup.c:3512) Uninitialised value was created by a stack allocation at 0x54B7A5E: __dcigettext (dcigettext.c:575) Conditional jump or move depends on uninitialised value(s) at 0x5513130: __GI___strcasecmp_l (strcmp.S:1873) by 0x54A95E2: __gconv_open (gconv_open.c:70) by 0x54B7589: _nl_find_msg (dcigettext.c:974) by 0x54B7D24: __dcigettext (dcigettext.c:640) by 0x550D61D: strerror_r (_strerror.c:73) by 0x550D51D: strerror (strerror.c:33) by 0x4E61C22: _do_dm_ioctl (libdm-iface.c:1664) by 0x4E6225B: dm_task_run (libdm-iface.c:1757) by 0x4E602D7: _create_and_load_v4 (libdm-iface.c:1291) by 0x4E61E4B: dm_task_run (libdm-iface.c:1722) by 0x40422A: _create (dmsetup.c:669) by 0x40AEB7: main (dmsetup.c:3512) Uninitialised value was created by a stack allocation at 0x54A94FD: __gconv_open (gconv_open.c:65)
Do you have a complete reproducer? I tried with the simplest testcase I could think of: $ cat strerr.c #include <stdio.h> #include <string.h> int main(int argc, char **argv) { printf("strerror(0): %s\n", strerror(0)); return 0; } $ gcc -Wall -g -o strerr strerr.c $ valgrind ./strerr ==1830== Memcheck, a memory error detector ==1830== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==1830== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==1830== Command: ./strerr ==1830== strerror(0): Success ==1830== ==1830== HEAP SUMMARY: ==1830== in use at exit: 0 bytes in 0 blocks ==1830== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==1830== ==1830== All heap blocks were freed -- no leaks are possible ==1830== ==1830== For counts of detected and suppressed errors, rerun with: -v ==1830== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Could you test against 3.8.1-4 and/or provide a self-contained reproducer for the issue?
Created attachment 634965 [details] Example which reproduces the problem on RHEL 6.3 The attached example reproduces the problem on RHEL 6.3: ==17311== Command: ./bug746216 ==17311== ==17311== Conditional jump or move depends on uninitialised value(s) ==17311== at 0x32638864D0: __GI___strcasecmp_l (strcmp.S:1998) ==17311== by 0x326381FF24: __gconv_open (gconv_open.c:70) ==17311== by 0x326382D3B7: _nl_find_msg (dcigettext.c:974) ==17311== by 0x326382DB83: __dcigettext (dcigettext.c:640) ==17311== by 0x400993: main (bug746216.cc:28) This is with valgrind-3.6.0-5.el6.x86_64 and fltk-1.1.10-1.el6.x86_64. Also verified with own build of FLTK 1.3.
(In reply to comment #4) > This is with valgrind-3.6.0-5.el6.x86_64 and fltk-1.1.10-1.el6.x86_64. Sorry, I cannot reproduce with either valgrind-3.8.1 from fedora, nor with valgrind-3.6.0 from RHEL6.3 with the EPEL fltk packages installed. Output from both versions look clean: $ rpm -q valgrind fltk valgrind-3.8.1-4.fc17.x86_64 valgrind-3.8.1-4.fc17.i686 fltk-1.3.0-4.fc17.x86_64 $ valgrind ./bug746216 ==24749== Memcheck, a memory error detector ==24749== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==24749== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==24749== Command: ./bug746216 ==24749== ==24749== ==24749== HEAP SUMMARY: ==24749== in use at exit: 0 bytes in 0 blocks ==24749== total heap usage: 74 allocs, 74 frees, 14,028 bytes allocated ==24749== ==24749== All heap blocks were freed -- no leaks are possible ==24749== ==24749== For counts of detected and suppressed errors, rerun with: -v ==24749== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) $ rpm -q valgrind fltk valgrind-3.6.0-5.el6.x86_64 fltk-1.1.10-1.el6.x86_64 $ valgrind ./bug746216 ==2389== Memcheck, a memory error detector ==2389== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2389== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==2389== Command: ./bug746216 ==2389== ==2389== ==2389== HEAP SUMMARY: ==2389== in use at exit: 0 bytes in 0 blocks ==2389== total heap usage: 55 allocs, 55 frees, 10,207 bytes allocated ==2389== ==2389== All heap blocks were freed -- no leaks are possible ==2389== ==2389== For counts of detected and suppressed errors, rerun with: -v ==2389== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) Might there be anything in your environment that could explain? Maybe some language setting that causes a different code path to be taken?
(In reply to comment #5) > Might there be anything in your environment that could explain? > Maybe some language setting that causes a different code path to be taken? Yes, probably. Here's my settings: $ locale LANG=sv_SE.utf8 LC_CTYPE="sv_SE.utf8" LC_NUMERIC="sv_SE.utf8" LC_TIME="sv_SE.utf8" LC_COLLATE="sv_SE.utf8" LC_MONETARY="sv_SE.utf8" LC_MESSAGES="sv_SE.utf8" LC_PAPER="sv_SE.utf8" LC_NAME="sv_SE.utf8" LC_ADDRESS="sv_SE.utf8" LC_TELEPHONE="sv_SE.utf8" LC_MEASUREMENT="sv_SE.utf8" LC_IDENTIFICATION="sv_SE.utf8" LC_ALL= $ env | grep LC_ $ env | grep LANG LANG=sv_SE.utf8
(In reply to comment #6) > (In reply to comment #5) > > > Might there be anything in your environment that could explain? > > Maybe some language setting that causes a different code path to be taken? > > Yes, probably. Here's my settings: > > $ env | grep LANG > LANG=sv_SE.utf8 Thanks, I can replicate the issue doing an export LANG=sv_SE.utf8 first against valgrind 3.6.0. It doesn't happen with valgrind 3.8.1 (and probably some earlier versions) since those intercept __GI___strcasecmp_l.