El día Tuesday, July 29, 2014 a las 08:35:51PM +0200, Philippe Waroquiers
escribió:
> On Tue, 2014-07-29 at 08:15 +0200, Matthias Apitz wrote:
> > El día Monday, July 28, 2014 a las 07:11:02AM -0700, John Reiser escribió:
> >
> > > > ==17454== Conditional jump or move depends on uninitialised value(s)
> > > > ==17454== at 0x5921F10: strchrnul (in /lib/libc-2.11.3.so)
> > > > ==17454== by 0x58E55D6: vfprintf (in /lib/libc-2.11.3.so)
> ...
> > All was fine. Why is valgrind complaining?
>
> Here is an hypothesis:
>
> Looking at (in the SVN version) shared/vg_replace_strmem.c
> strchrnul should have been replaced by the implementation
> in vg_replace_strmem.c.
>
> From the stacktrace above, it looks like strchrnul was not replaced.
This (your hypothesis) matches with the fact that I was not able to
reproduce the same problem with a small C-pgm doing exactly the same
sprintf() call:
#include <stdio.h>
#define MAX_SEL_LEN 1024
static int select_record();
main()
{
select_record("SELECT rowid, sisisinst.* from sisisinst");
}
static int select_record (char *sel_anw)
{
char select_anw[MAX_SEL_LEN];
char *name = "sisisinst";
sprintf (select_anw, sel_anw, name, name);
}
in this case the valgrind does not complain with the sprintf() ...
strchrnul() stack trace; and in addition, the output shows the
replacement of strchrnul() to some valgrind' function implementation; I
have the output here:
the big C-server (where strchrnul() is not replaced):
http://www.unixarea.de/valg1.txt
the small C-code aboce (where strchrnul() is replaced):
http://www.unixarea.de/valg2.txt
I'm not a valgrind expert and can not say what is causing the
difference; let me know if you want me to file a bug report with the data.
> Often, the glibc implementations of the str* functions
> are highly optimised, and causes false positive
> (e.g. by assuming they can read a few more bytes than
> the end of the string).
>
> That might be the case for you.
>
> What you could do is to redo your GDB session, but using
> the valgrind gdbserver monitor command to check the definedness
> of the printf args at various momenets and
> just before the print call.
>
> Note that using --track-origins=yes should indicate where
> this unitialised byte is coming from.
>
> Would be nice to understand why strchrnul was not replaced
> (using e.g. -v -v -v --trace-redir=yes).
yes, would be nice; let me know if you need more data to understand this
problem of not replacing strchrnul()
Thx
matthias
--
Matthias Apitz | /"\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X - No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
