Oh, sorry

By mistake i wrote incorrect distro numbers and no suggestion.

I saw error with Fedora 14/x64

Now i see no error with F15 and F16 /x64


What changes if you set LANG to smth different from "C"?

Dmitry

2011/11/26 Дмитрий Дьяченко <[email protected]>:
> Under Fedora 15/x64 i saw issue with setlocale()  around mid-february-2011
>
> interesting part from report
> ==9569== Conditional jump or move depends on uninitialised value(s)
> ==9569== at 0x3A45283D82: __GI___strcasecmp_l
> (/usr/src/debug////////glibc-2.13/string/../sysdeps/x86_64/strcmp.S:409)
> ==9569== by 0x3A4521FEB1: __gconv_open
> (/usr/src/debug/glibc-2.13/iconv/gconv_open.c:70)
> ==9569== by 0x3A4522D266: _nl_find_msg
> (/usr/src/debug/glibc-2.13/intl/dcigettext.c:974)
> ==9569== by 0x3A4522D9A7: __dcigettext
> (/usr/src/debug/glibc-2.13/intl/dcigettext.c:640)
> ==9569== by 0x3A4527FDC7: strerror_r
> (/usr/src/debug/glibc-2.13/string/_strerror.c:65)
> ==9569== by 0x3A4527FCCD: strerror
> (/usr/src/debug/glibc-2.13/string/strerror.c:33)
>
> If run as LANG=ru_RU.utf-8 valgrind ./a.out
> then err present
>
> If run as LANG=C  valgrind ./a.out
> then i saw no error
>
> Now F15/x64 has no such err.
>
> Dmitry
>
> 2011/11/26 John Reiser <[email protected]>:
>> On 11/25/2011 05:56 AM, Dominic Monroe wrote:
>>> I've been trying to run Valgrind on an application, and found a ridicolous 
>>> amount of false positives. It was suggested to me I should email this list 
>>> with errors. I identified the function setlocale to be "errorneous"
>>   [snip]
>>>     ==23068== Invalid read of size 4
>>>     ==23068==    at 0x40C901B: ??? (in /lib/libc-2.14.1.so 
>>> <http://libc-2.14.1.so>)
>>>     ==23068==    by 0x40771E8: ??? (in /lib/libc-2.14.1.so 
>>> <http://libc-2.14.1.so>)
>>>     ==23068==    by 0x4076D33: setlocale (in /lib/libc-2.14.1.so 
>>> <http://libc-2.14.1.so>)
>>>     ==23068==    by 0x8048400: main (val2.c:5)
>>>     ==23068==  Address 0x41d002c is 4 bytes inside a block of size 5 alloc'd
>>>     ==23068==    at 0x402A018: malloc (in 
>>> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
>>>     ==23068==    by 0x407E42B: ??? (in /lib/libc-2.14.1.so 
>>> <http://libc-2.14.1.so>)
>>>     ==23068==    by 0x40784A4: ??? (in /lib/libc-2.14.1.so 
>>> <http://libc-2.14.1.so>)
>>>     ==23068==    by 0x40771E8: ??? (in /lib/libc-2.14.1.so 
>>> <http://libc-2.14.1.so>)
>>>     ==23068==    by 0x4076D33: setlocale (in /lib/libc-2.14.1.so 
>>> <http://libc-2.14.1.so>)
>>>     ==23068==    by 0x8048400: main (val2.c:5)
>>   [snip]
>>> I am using Arch Linux (Which I think is in the above log, but regardless) 
>>> I'm not sure if I have done something wrong, or there's an issue with the 
>>> Arch package. But either way I am stuck.Thanks for any help you guys can 
>>> provide to me.
>>
>> Using a fresh installation, I cannot reproduce those problems:
>>
>> + pacman --query gcc glibc valgrind
>> gcc 4.6.2-1
>> glibc 2.14-4
>> valgrind 3.7.0-1
>> + uname -a
>> Linux myhost 3.0-ARCH #1 SMP PREEMPT Wed Aug 17 20:24:07 UTC 2011 i686 
>> Intel(R) Pentium(R) 4 CPU 1.60GHz GenuineIntel GNU/Linux
>> + cat setlocale.c
>> #include <stdio.h>
>> #include <locale.h>
>>
>> main()
>> {
>>        setlocale(LC_ALL, "");
>> }
>> + gcc -g -o setlocale setlocale.c
>> + valgrind --leak-check=yes -v --track-origins=yes ./setlocale
>> ==936== Memcheck, a memory error detector
>> ==936== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
>> ==936== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
>> ==936== Command: ./setlocale
>> ==936==
>> --936-- Valgrind options:
>> --936--    --leak-check=yes
>> --936--    -v
>> --936--    --track-origins=yes
>> --936-- Contents of /proc/version:
>> --936--   Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 (GCC) 
>> ) #1 SMP PREEMPT Wed Aug 17 20:24:07 UTC 2011
>> --936-- Arch and hwcaps: X86, x86-sse1-sse2
>> --936-- Page sizes: currently 4096, max supported 4096
>> --936-- Valgrind library directory: /usr/lib/valgrind
>> --936-- Reading syms from /lib/ld-2.14.so (0x4000000)
>> --936-- Reading syms from /home/jreiser/setlocale (0x8048000)
>> --936-- Reading syms from /usr/lib/valgrind/memcheck-x86-linux (0x38000000)
>> --936--    object doesn't have a symbol table
>> --936--    object doesn't have a dynamic symbol table
>> --936-- Reading suppressions file: /usr/lib/valgrind/default.supp
>> ==936== embedded gdbserver: reading from 
>> /tmp/vgdb-pipe-from-vgdb-to-936-by-jreiser-on-???
>> ==936== embedded gdbserver: writing to   
>> /tmp/vgdb-pipe-to-vgdb-from-936-by-jreiser-on-???
>> ==936== embedded gdbserver: shared mem   
>> /tmp/vgdb-pipe-shared-mem-vgdb-936-by-jreiser-on-???
>> ==936==
>> ==936== TO CONTROL THIS PROCESS USING vgdb (which you probably
>> ==936== don't want to do, unless you know exactly what you're doing,
>> ==936== or are doing some strange experiment):
>> ==936==   /usr/lib/valgrind/../../bin/vgdb --pid=936 ...command...
>> ==936==
>> ==936== TO DEBUG THIS PROCESS USING GDB: start GDB like this
>> ==936==   /path/to/gdb ./setlocale
>> ==936== and then give GDB the following command
>> ==936==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=936
>> ==936== --pid is optional if only one valgrind process is running
>> ==936==
>> --936-- REDIR: 0x40176c0 (strlen) redirected to 0x38056b04 (???)
>> --936-- REDIR: 0x4017500 (index) redirected to 0x38056adf (???)
>> --936-- Reading syms from /usr/lib/valgrind/vgpreload_core-x86-linux.so 
>> (0x4023000)
>> --936--    object doesn't have a symbol table
>> --936-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so 
>> (0x4026000)
>> --936--    object doesn't have a symbol table
>> --936-- Reading syms from /lib/libc-2.14.so (0x4037000)
>> --936--    object doesn't have a symbol table
>> --936-- REDIR: 0x40ad6c0 (rindex) redirected to 0x402a320 (rindex)
>> --936-- REDIR: 0x40acc80 (strcmp) redirected to 0x402b430 (strcmp)
>> --936-- REDIR: 0x40ad2c0 (strlen) redirected to 0x402a800 (strlen)
>> --936-- REDIR: 0x40ad4e0 (strncmp) redirected to 0x402aca0 (strncmp)
>> --936-- REDIR: 0x40acb10 (index) redirected to 0x402a430 (index)
>> --936-- REDIR: 0x40b1980 (strchrnul) redirected to 0x402cd90 (strchrnul)
>> --936-- REDIR: 0x40a9460 (malloc) redirected to 0x4029fb0 (malloc)
>> --936-- REDIR: 0x40aed70 (mempcpy) redirected to 0x402cec0 (mempcpy)
>> --936-- REDIR: 0x40af1d0 (memcpy) redirected to 0x402bae0 (memcpy)
>> --936-- REDIR: 0x40a9910 (free) redirected to 0x40291b0 (free)
>> ==936==
>> ==936== HEAP SUMMARY:
>> ==936==     in use at exit: 0 bytes in 0 blocks
>> ==936==   total heap usage: 28 allocs, 28 frees, 1,953 bytes allocated
>> ==936==
>> ==936== All heap blocks were freed -- no leaks are possible
>> ==936==
>> ==936== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)
>> --936--
>> --936-- used_suppression:     13 U1004-ARM-_dl_relocate_object
>> ==936==
>> ==936== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)
>>
>> --
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Valgrind-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to