On Tue, Mar 16, 2010 at 7:29 PM, Julian Seward <[email protected]> wrote: > I suggest you try the svn trunk valgrind. I put in some automatic > replacements for strchr and some related ones (see h_intercepts.c) > and so you should not see these complaints any more. Build details > are at http://www.valgrind.org/downloads/repository.html
Excellent, the svn version removes many violations. I still have a couple, though. Here are two samples which show up quite often: ==5789== Thread 1: ==5789== Invalid read of size 16 ==5789== at 0x303E27E164: __GI_strcmp (in /lib64/libc-2.11.1.so) ==5789== by 0x303E296036: __tzstring (in /lib64/libc-2.11.1.so) ==5789== by 0x303E297EE2: __tzfile_read (in /lib64/libc-2.11.1.so) ==5789== by 0x303E296B61: tzset_internal (in /lib64/libc-2.11.1.so) ==5789== by 0x303E296CF8: __tz_convert (in /lib64/libc-2.11.1.so) ==5789== by 0x42337E: getCurrTime (datetime.c:96) ==5789== by 0x41B6ED: msgConstruct (msg.c:723) ==5789== by 0x40C122: logmsgInternal (syslogd.c:880) ==5789== by 0x40C9E1: init (syslogd.c:2422) ==5789== by 0x40DC70: realMain (syslogd.c:2842) ==5789== by 0x303E21EB1C: (below main) (in /lib64/libc-2.11.1.so) ==5789== Address 0x4c7a930 is 16 bytes inside the accessing pointer's ==5789== legitimate range, a block of size 20 alloc'd ==5789== at 0x4A04AC2: malloc (vg_replace_malloc.c:236) ==5789== by 0x303E296051: __tzstring (in /lib64/libc-2.11.1.so) ==5789== by 0x303E297EE2: __tzfile_read (in /lib64/libc-2.11.1.so) ==5789== by 0x303E296B61: tzset_internal (in /lib64/libc-2.11.1.so) ==5789== by 0x303E296CF8: __tz_convert (in /lib64/libc-2.11.1.so) ==5789== by 0x42337E: getCurrTime (datetime.c:96) ==5789== by 0x41B6ED: msgConstruct (msg.c:723) ==5789== by 0x40C122: logmsgInternal (syslogd.c:880) ==5789== by 0x40C9E1: init (syslogd.c:2422) ==5789== by 0x40DC70: realMain (syslogd.c:2842) ==5789== by 0x303E21EB1C: (below main) (in /lib64/libc-2.11.1.so) ==5789== AND ==5789== Thread 4: ==5789== Invalid read of size 8 ==5789== at 0x303E324A99: __strncmp_ssse3 (in /lib64/libc-2.11.1.so) ==5789== by 0x42A8B1: Load (modules.c:614) ==5789== by 0x427E51: UseObj (obj.c:1156) ==5789== by 0x5433D2A: netstrmsConstructFinalize (netstrms.c:79) ==5789== by 0x563D67D: tcpsrvConstructFinalize (tcpsrv.c:612) ==5789== by 0x52304DF: runInput (imtcp.c:233) ==5789== by 0x44EB5F: thrdStarter (threads.c:139) ==5789== by 0x303EE06A39: start_thread (in /lib64/libpthread-2.11.1.so) ==5789== Address 0x4c32ee8 is 2 bytes after the accessing pointer's ==5789== legitimate range, a block of size 6 alloc'd ==5789== at 0x4A04AC2: malloc (vg_replace_malloc.c:236) ==5789== by 0x303E27F021: strdup (in /lib64/libc-2.11.1.so) ==5789== by 0x42A683: doModInit (modules.c:420) ==5789== by 0x42AB82: Load (modules.c:707) ==5789== by 0x427E51: UseObj (obj.c:1156) ==5789== by 0x416181: confClassInit (conf.c:1293) ==5789== by 0x41550D: rsrtInit (rsyslog.c:185) ==5789== by 0x40D5D6: realMain (syslogd.c:2912) ==5789== by 0x303E21EB1C: (below main) (in /lib64/libc-2.11.1.so) ==5789== They all seem to occur in some system /glibc routines. Given your previous answer, I assume it is safe to create supressions for them (I am trying not to remove those actually caused by my program bug;))? Thanks again, Rainer ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
