Re: [Valgrind-users] valgrind && sprintf arguments

[Matthias A. <gu...@un...>]

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: gu...@un...     |  \ /   - 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