|
From: galapogos <go...@gm...> - 2009-01-15 04:14:15
|
Hi, I am trying to run valgrind on my program, which uses other standard libraries such as pthread and ncurses. My program is compiled statically. Valgrind is complaining about some errors/warnings from these libraries, which are out of my control, and I wish to suppress these messages. I've run gen-suppressions=yes to generate suppressions, but there are hundreds of them and I don't wish to have such a long suppression file if possible. Is it thus possible to suppress all messages from specified libraries? I've looked at the valgrind manual under suppressions but I can't figure out how to do it. I've tried using wildcards (* and ...) but they don't seem to work. Thanks! -- View this message in context: http://www.nabble.com/Suppressing-messages-from-libraries-tp21471039p21471039.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Konstantin S. <kon...@gm...> - 2009-01-15 05:50:23
|
On Thu, Jan 15, 2009 at 7:14 AM, galapogos <go...@gm...> wrote: > > Hi, > > I am trying to run valgrind on my program, which uses other standard > libraries such as pthread and ncurses. My program is compiled statically. >From http://valgrind.org/docs/manual/faq.html: if your program is statically linked, most Valgrind tools won't work as well, because they won't be able to replace certain functions, such as malloc(), with their own versions. --kcc > Valgrind is complaining about some errors/warnings from these libraries, > which are out of my control, and I wish to suppress these messages. I've run > gen-suppressions=yes to generate suppressions, but there are hundreds of > them and I don't wish to have such a long suppression file if possible. > > Is it thus possible to suppress all messages from specified libraries? I've > looked at the valgrind manual under suppressions but I can't figure out how > to do it. I've tried using wildcards (* and ...) but they don't seem to > work. > > Thanks! > -- > View this message in context: http://www.nabble.com/Suppressing-messages-from-libraries-tp21471039p21471039.html > Sent from the Valgrind - Users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: galapogos <go...@gm...> - 2009-01-15 06:09:24
|
Thanks kcc. I've compiled it dynamically now for debugging, but I'm still getting many errors, particularly of these type Syscall param <function(params)> points to uninitialised byte(s) and/or Conditional jump or move depends on uninitialised value(s) This doesn't make sense to me since the values are in fact initialized, or if they're not, it doesn't matter because the function will write to the variable, hence initializing it. I'm getting these errors on simple ioctl() calls, and even malloc()/strcpy()/etc. Bugzilla from kon...@gm... wrote: > > On Thu, Jan 15, 2009 at 7:14 AM, galapogos <go...@gm...> wrote: >> >> Hi, >> >> I am trying to run valgrind on my program, which uses other standard >> libraries such as pthread and ncurses. My program is compiled statically. > >>From http://valgrind.org/docs/manual/faq.html: > if your program is statically linked, most Valgrind tools won't work > as well, because they won't be able to replace certain functions, such > as malloc(), with their own versions. > > --kcc > > >> Valgrind is complaining about some errors/warnings from these libraries, >> which are out of my control, and I wish to suppress these messages. I've >> run >> gen-suppressions=yes to generate suppressions, but there are hundreds of >> them and I don't wish to have such a long suppression file if possible. >> >> Is it thus possible to suppress all messages from specified libraries? >> I've >> looked at the valgrind manual under suppressions but I can't figure out >> how >> to do it. I've tried using wildcards (* and ...) but they don't seem to >> work. >> >> Thanks! >> -- >> View this message in context: >> http://www.nabble.com/Suppressing-messages-from-libraries-tp21471039p21471039.html >> Sent from the Valgrind - Users mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- View this message in context: http://www.nabble.com/Suppressing-messages-from-libraries-tp21471039p21471981.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Konstantin S. <kon...@gm...> - 2009-01-15 07:05:00
|
On Thu, Jan 15, 2009 at 9:09 AM, galapogos <go...@gm...> wrote: > > Thanks kcc. I've compiled it dynamically now for debugging, but I'm still > getting many errors, particularly of these type > > Syscall param <function(params)> points to uninitialised byte(s) and/or > Conditional jump or move depends on uninitialised value(s) > > This doesn't make sense to me since the values are in fact initialized, or > if they're not, it doesn't matter because the function will write to the > variable, hence initializing it. I'm getting these errors on simple ioctl() > calls, and even malloc()/strcpy()/etc. What compiler options did you use? Also, could you please provide more info (compiler version, valgrind version, linux version, maybe some exemplary output). --kcc > > > Bugzilla from kon...@gm... wrote: >> >> On Thu, Jan 15, 2009 at 7:14 AM, galapogos <go...@gm...> wrote: >>> >>> Hi, >>> >>> I am trying to run valgrind on my program, which uses other standard >>> libraries such as pthread and ncurses. My program is compiled statically. >> >>>From http://valgrind.org/docs/manual/faq.html: >> if your program is statically linked, most Valgrind tools won't work >> as well, because they won't be able to replace certain functions, such >> as malloc(), with their own versions. >> >> --kcc >> >> >>> Valgrind is complaining about some errors/warnings from these libraries, >>> which are out of my control, and I wish to suppress these messages. I've >>> run >>> gen-suppressions=yes to generate suppressions, but there are hundreds of >>> them and I don't wish to have such a long suppression file if possible. >>> >>> Is it thus possible to suppress all messages from specified libraries? >>> I've >>> looked at the valgrind manual under suppressions but I can't figure out >>> how >>> to do it. I've tried using wildcards (* and ...) but they don't seem to >>> work. >>> >>> Thanks! >>> -- >>> View this message in context: >>> http://www.nabble.com/Suppressing-messages-from-libraries-tp21471039p21471039.html >>> Sent from the Valgrind - Users mailing list archive at Nabble.com. >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by: >>> SourcForge Community >>> SourceForge wants to tell your story. >>> http://p.sf.net/sfu/sf-spreadtheword >>> _______________________________________________ >>> Valgrind-users mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> > > -- > View this message in context: http://www.nabble.com/Suppressing-messages-from-libraries-tp21471039p21471981.html > Sent from the Valgrind - Users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: galapogos <go...@gm...> - 2009-01-15 07:30:12
|
Bugzilla from kon...@gm... wrote: > > On Thu, Jan 15, 2009 at 9:09 AM, galapogos <go...@gm...> wrote: >> >> Thanks kcc. I've compiled it dynamically now for debugging, but I'm still >> getting many errors, particularly of these type >> >> Syscall param <function(params)> points to uninitialised byte(s) and/or >> Conditional jump or move depends on uninitialised value(s) >> >> This doesn't make sense to me since the values are in fact initialized, >> or >> if they're not, it doesn't matter because the function will write to the >> variable, hence initializing it. I'm getting these errors on simple >> ioctl() >> calls, and even malloc()/strcpy()/etc. > > What compiler options did you use? > Also, could you please provide more info (compiler version, valgrind > version, linux version, maybe some exemplary output). > Sure. I'm using gcc with -Wall -g -O0 options. I'm building in Mandriva Linux 2008.1 using gcc 4.2.3, and using valgrind-3.3.0-3mdv2008.1.i586.rpm Here are the 1st few output: ==30486== Syscall param ioctl(SG_GET_VERSION_NUM) points to uninitialised byte(s) ==30486== at 0x4100299: ioctl (in /lib/i686/libc-2.7.so) ==30486== by 0x80498A5: main (a_scsi.c:1139) ==30486== Address 0xbe8f4f20 is on thread 1's stack ==30486== ==30486== Conditional jump or move depends on uninitialised value(s) ==30486== at 0x804883F: a_identify_device (a_scsi.c:135) ==30486== by 0x80498A5: main (a_scsi.c:1139) ==30486== ==30486== Conditional jump or move depends on uninitialised value(s) ==30486== at 0x402398B: strncpy (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==30486== by 0x804898A: a_identify_device (a_scsi.c:203) ==30486== by 0x80498A5: main (a_scsi.c:1139) ==30486== ==30486== Conditional jump or move depends on uninitialised value(s) ==30486== at 0x4023997: strncpy (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==30486== by 0x804898A: a_identify_device (a_scsi.c:203) ==30486== by 0x80498A5: main (a_scsi.c:1139) ==30486== ==30486== Conditional jump or move depends on uninitialised value(s) ==30486== at 0x402274B: strlen (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==30486== by 0x408FF94: puts (in /lib/i686/libc-2.7.so) ==30486== by 0x80498C5: main (a_scsi.c:1142) Basically my main calls a_identify_device() in a_scsi.c, which does an if (ioctl()) call, and apparently valgrind is complaining that SG_GET_VERSION_NUM, which is one of its parameters, is uninitialized. This doesn't make sense to me since SG_GET_VERSION_NUM is a constant integer? The other string functions that are reported are also used in if statements, however all data have been previously initialized. Let me know if you need more information. Thanks again! -- View this message in context: http://www.nabble.com/Suppressing-messages-from-libraries-tp21471039p21472673.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: galapogos <go...@gm...> - 2009-01-15 09:01:45
|
Tom Hughes-2 wrote: > > galapogos wrote: > >> I'm using gcc with -Wall -g -O0 options. >> I'm building in Mandriva Linux 2008.1 using gcc 4.2.3, and using >> valgrind-3.3.0-3mdv2008.1.i586.rpm >> Here are the 1st few output: >> >> ==30486== Syscall param ioctl(SG_GET_VERSION_NUM) points to uninitialised >> byte(s) >> ==30486== at 0x4100299: ioctl (in /lib/i686/libc-2.7.so) >> ==30486== by 0x80498A5: main (a_scsi.c:1139) >> ==30486== Address 0xbe8f4f20 is on thread 1's stack > > It's a bug - that ioctl is wrong marked as reading an int from the > pointer instead of writing an int to it. So it is (wrongly) expecting > the point you give it to point at initialised memory. > >> ==30486== Conditional jump or move depends on uninitialised value(s) >> ==30486== at 0x804883F: a_identify_device (a_scsi.c:135) >> ==30486== by 0x80498A5: main (a_scsi.c:1139) > > This and the other complaints then follow as the result of the ioctl has > not been marked as initialised. > > I've just committed a fix. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > Thanks. So it's a bug in valgrind? My distribution's version isn't the latest one. Does the latest version have a fix? Meanwhile how do I suppress these errors? Also, you mention it's a bug concerning ioctl(). What about the other string functions? Same bug as well? -- View this message in context: http://www.nabble.com/Suppressing-messages-from-libraries-tp21471039p21473735.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Tom H. <to...@co...> - 2009-01-15 09:15:24
|
galapogos wrote: > Thanks. So it's a bug in valgrind? My distribution's version isn't the > latest one. Does the latest version have a fix? Meanwhile how do I suppress > these errors? I just said that I just committed a fix, so unless somebody has done a release in the last ten minutes when I wasn't looking then no, the latest version does not have a fix. The best fix is probably to use VALGRIND_MAKE_MEM_DEFINED() to mark the result of the ioctl as defined. You will still get a warning about the ioctl itself (though you could do the MAKE_MEM_DEFINED before the ioctl call to avoid that as well) but the other warnings should vanish. > Also, you mention it's a bug concerning ioctl(). What about the other string > functions? Same bug as well? They probably all follow from the bug - the uninitialised result of the ioctl will propagate through code which uses that result. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <to...@co...> - 2009-01-15 08:54:11
|
galapogos wrote: > I'm using gcc with -Wall -g -O0 options. > I'm building in Mandriva Linux 2008.1 using gcc 4.2.3, and using > valgrind-3.3.0-3mdv2008.1.i586.rpm > Here are the 1st few output: > > ==30486== Syscall param ioctl(SG_GET_VERSION_NUM) points to uninitialised > byte(s) > ==30486== at 0x4100299: ioctl (in /lib/i686/libc-2.7.so) > ==30486== by 0x80498A5: main (a_scsi.c:1139) > ==30486== Address 0xbe8f4f20 is on thread 1's stack It's a bug - that ioctl is wrong marked as reading an int from the pointer instead of writing an int to it. So it is (wrongly) expecting the point you give it to point at initialised memory. > ==30486== Conditional jump or move depends on uninitialised value(s) > ==30486== at 0x804883F: a_identify_device (a_scsi.c:135) > ==30486== by 0x80498A5: main (a_scsi.c:1139) This and the other complaints then follow as the result of the ioctl has not been marked as initialised. I've just committed a fix. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |