valgrind-users — General discussion list for Valgrind users

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

[Philippe W. <phi...@sk...>]

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.

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).

Philippe

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

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

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)
> 
> > the involved fuctions are shown below; the statement in question (see below)
> > is
> > 
> >   sprintf (select_anw, sel_anw, name, name);      <********* sisisinst.c:1397
> > 
> > I have checked carefully the code and the 4 args to sprintf() are
> > all correct defined on the stack; when I change the code to:
> > 
> > 
> >   select_anw[0] = '\0';
> >   sprintf (select_anw, sel_anw, name, name); 
> > 	
> > then is valgrind happy, i.e, does not raise the messages any more;
> 
> You say that all 4 args are on the stack.  What are their actual addresses?
> Run with --db-attach=yes, say 'y' when asked, and use gdb to look around.
> 
> One possibility is that sel_anw (the format string) has been overwritten
> because the string being built into select_anw (the buffer) has overflowed.
> 
> Try changing the code to use
> 	snprintf(select_anw, LEN_SELECT, sel_anw, name, name);
> which is much safer.

Thanks for your hints. Before I will change the code (yes, your proposal is
much safer), I will try to understand why valgrind is complaining;

I grabbed the gdb and debugged through the code:

(gdb) where
#0  DB_rdir (tabmodul=0xf6a68170 <sisisinst>, key=2, scroll=1, lock=0, p_daten=0xffffc860) at dbcall.c:1834
#1  0xf6a4cc21 in DB_ChkVer () at dbcall.c:604
#2  0xf6a4d099 in DB_opdbP (mode=1) at dbcall.c:955
#3  0xf6a4cd3a in DB_opdb () at dbcall.c:654
#4  0x0804bf6a in InitVDaemon () at ZFLVDaemon.c:715
#5  0x0804baad in main (argc=1, argv=0xffffce14) at ZFLVDaemon.c:413
(gdb) p &sel_anw
$3 = (char (*)[1000]) 0xffffc3c0

sel_anw is an automatic char[1000] area and will now be initialized from
some static string 'SELECT1':

1885        strcpy(sel_anw, SELECT1);
(gdb) 
1887      strcpy(where_anw, WHERE1);
(gdb) 

'sel_anw' and 'where_anw' both are set correctly:

(gdb) p sel_anw
$4 = "SELECT rowid, %s.* from %s", '\000' <repeats 46 times> ...
(gdb) p where_anw
$5 = "%s = :v1", '\000' <repeats 24 times> ...

(gdb) p &sel_anw
$6 = (char (*)[1000]) 0xffffc3c0

(gdb) p &where_anw
$7 = (char (*)[5000]) 0xffffb030

the pointers are passed correctly to sisisinst() function:

(gdb) s
sisisinst (zugriff=1, scroll=1, lock=0, key=2, sto=-20000, p_daten=0xffffc860, 
    sel_anw=0xffffc3c0 "SELECT rowid, %s.* from %s", where_anw=0xffffb030 "%s = :v1", p_btw_daten=0x0, 
    order_by=0x0, auf_ab=0x0, group_by=0x0, having=0x0, into_temp=0x0, count=0xffffb02c) at sisisinst.c:799

933         case  RDIR  :   db_ret = select_record(scroll, lock, key,
(gdb) s

and passed further to select_record() function:

Breakpoint 2, select_record (scroll=1, lock=0, key=2, sel_anw=0xffffc3c0 "SELECT rowid, %s.* from %s", 
    where_anw=0xffffb030 "%s = :v1", p_daten=0xf6ae04a0 <hrec_sisisinst>, i_between=0, p_oben=0xffffaf30, 
    order_by=0x0, auf_ab=0x0, group_by=0x0, having=0x0, into_temp=0x0, count=0xffffb02c) at sisisinst.c:1353

(gdb) p sel_anw
$8 = 0xffffc3c0 "SELECT rowid, %s.* from %s"
(gdb) p where_anw
$9 = 0xffffb030 "%s = :v1"

(gdb) 
1396      char *name = TAB_SISISINST;
(gdb) 

this is now the call to sprintf() which was identified by valgrind:

1397      sprintf (select_anw, sel_anw, name, name);
(gdb) p name
$10 = 0xf6ac8f3e "sisisinst"
(gdb) p sel_anw
$11 = 0xffffc3c0 "SELECT rowid, %s.* from %s"
(gdb) p &select_anw
$12 = (char (*)[5000]) 0xffff9ac0

now executing the sprintf() ...

(gdb) n
1401      switch (key)

the result is fine and the target buffer of sprintf(), the 'select_anw'
is corretcly filled:

(gdb) p select_anw
$13 = "SELECT rowid, sisisinst.* from sisisinst", '\000' <repeats 536 times>, "ALTER SESSION SET NLS_LANGUAGE= 'GERMAN' NLS_TERRITORY= 'GERMANY' NLS_CURRENCY= '??' NLS_ISO_CURRENCY= 'GERMANY' NLS_NUMERIC_CHARACTERS= ',.' NLS_CALEN"...
(gdb) p &select_anw
$14 = (char (*)[5000]) 0xffff9ac0

All was fine. Why is valgrind complaining?

Thanks

	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

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

[John R. <jr...@Bi...>]

> --db-attach=yes should be considered as (is?) obsolete.
> 
> You could instead use --vgdb-error=1 (to just attach when the error is
> reported) or better use --vgdb-error=0, put breakpoints
> and verify the (un-)definedness of the relevant variables at various
> points between their declaration and their usage.

https://bugs.kde.org/show_bug.cgi?id=337871
   deprecate --db-attach=yes in favor of --vgdb-debug=1

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

[Philippe W. <phi...@sk...>]

On Mon, 2014-07-28 at 07:11 -0700, John Reiser wrote:
> > ==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)
> 
> > the involved fuctions are shown below; the statement in question (see below)
> > is
> > 
> >   sprintf (select_anw, sel_anw, name, name);      <********* sisisinst.c:1397
> > 
> > I have checked carefully the code and the 4 args to sprintf() are
> > all correct defined on the stack; when I change the code to:
> > 
> > 
> >   select_anw[0] = '\0';
> >   sprintf (select_anw, sel_anw, name, name); 
> > 	
> > then is valgrind happy, i.e, does not raise the messages any more;
> 
> You say that all 4 args are on the stack.  What are their actual addresses?
> Run with --db-attach=yes, say 'y' when asked, and use gdb to look around.
--db-attach=yes should be considered as (is?) obsolete.

You could instead use --vgdb-error=1 (to just attach when the error is
reported) or better use --vgdb-error=0, put breakpoints
and verify the (un-)definedness of the relevant variables at various
points between their declaration and their usage.

Philippe

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

[John R. <jr...@Bi...>]

> ==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)

> the involved fuctions are shown below; the statement in question (see below)
> is
> 
>   sprintf (select_anw, sel_anw, name, name);      <********* sisisinst.c:1397
> 
> I have checked carefully the code and the 4 args to sprintf() are
> all correct defined on the stack; when I change the code to:
> 
> 
>   select_anw[0] = '\0';
>   sprintf (select_anw, sel_anw, name, name); 
> 	
> then is valgrind happy, i.e, does not raise the messages any more;

You say that all 4 args are on the stack.  What are their actual addresses?
Run with --db-attach=yes, say 'y' when asked, and use gdb to look around.

One possibility is that sel_anw (the format string) has been overwritten
because the string being built into select_anw (the buffer) has overflowed.

Try changing the code to use
	snprintf(select_anw, LEN_SELECT, sel_anw, name, name);
which is much safer.

[Valgrind-users] valgrind && sprintf arguments

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

Hello,

While analyzing a complex C-written database layer with valgrind 3.9.0, I
encounter the following problem in some statement; the called functions
are putting together a database SELECT statement:

...
==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)
==17454==    by 0x59076FB: vsprintf (in /lib/libc-2.11.3.so)
==17454==    by 0x58EF96A: sprintf (in /lib/libc-2.11.3.so)
==17454==    by 0x5555A0C: select_record (sisisinst.c:1397)
==17454==    by 0x55553F4: sisisinst (sisisinst.c:933)
==17454==    by 0x553AC45: DB_rdir (dbcall.c:1894)
==17454==    by 0x5539C20: DB_ChkVer (dbcall.c:604)
==17454==    by 0x553A098: DB_opdbP (dbcall.c:955)
==17454==    by 0x5539D39: DB_opdb (dbcall.c:654)
==17454==    by 0x804BF69: InitVDaemon (ZFLVDaemon.c:715)
==17454==    by 0x804BAAC: main (ZFLVDaemon.c:413)
==17454==  Uninitialised value was created by a stack allocation
==17454==    at 0x553AA48: DB_rdir (dbcall.c:1827)

the involved fuctions are shown below; the statement in question (see below)
is

  sprintf (select_anw, sel_anw, name, name);      <********* sisisinst.c:1397

I have checked carefully the code and the 4 args to sprintf() are
all correct defined on the stack; when I change the code to:


  select_anw[0] = '\0';
  sprintf (select_anw, sel_anw, name, name); 
	
then is valgrind happy, i.e, does not raise the messages any more;

I have two questions:

1) What makes valgrind complaining about this code exactly?
2) When I write a small example like:

   #include <stdio.h>

   main() {
      char select_anw[1024];
      sprintf (select_anw, "SELECT %s.* from %s ", "bla", "bla");
   }

   I'm not able to reproduce the valgrind warning, why?

Thanks

	matthias





DB_rdir():

DB_rdir(int (*tabmodul)(), /* Name des Moduls, das die DB-Operationen
                            * fuer die gewuenschte Tabelle realisiert      */
        int key,           /* Bezeichner f. Schluessel                     */
        int scroll,        /* SCROLL-Cursor anlegen oder nicht             */
        int lock,          /* Satz sperren oder nicht                      */
        void *p_daten      /* Zeiger auf die Struktur der jeweiligen
                            * Datenbanktabelle. Vor Aufruf m?ssen die Werte
                            * der Felder, die zum Key geh?ren, gef?llt
                            * werden. Nach Ablauf der Funktion ist Struktur
                            * bei erfolgreicher Abarbeitung mit erstem Satz
                            * der Ergebnismenge gef?llt                    */
       )
{                                                                           <******* dbcall.c:1827
/*----------------------------------------------------------------------*
 *                     DB_rdir()                                        *
 *----------------------------------------------------------------------*/
int db_ret=RC_OK;
char sel_anw[LEN_SELECT];
^^^^^^^^^^^^^^^^^^^^^^^^^
....

  /*
   * SELECT-Anweisung in Teilen zusammen setzen
   * DB_NORID: keine rowids lesen
   */
  if(lock == DB_NORID) {
    /* no rowid und scroll cursor passen nicht zusammen: Fehler */
    if(scroll == DB_SCROLL) {
      db_ret = db_errfill(DBCALL_FEHLER, RC_NORIDSCR);
      if(db_report_is_on) db_report(REPORT_FCT_OUT, "DB_rdir", db_ret);
      return(db_ret);
    }
    strcpy(sel_anw, SELECT0);
  } else {
    strcpy(sel_anw, SELECT1);
  }
  strcpy(where_anw, WHERE1);


  /*
   *  Aufruf tabellenspezifisches Modul
   */
  if(sql_trace_is_on) sybDebug("now entering tabmodul");
  db_ret = ((* tabmodul) (RDIR, scroll, lock, key, (int)DB_NOPARA, p_daten,
                          sel_anw, where_anw, (void *)NULL,
                          (char *)NULL, (char *)NULL, (char *)NULL, (char *)NULL, (char *)NULL, (long *)&count));



sisisinst():

/*------------------------------------------------------------------------*/
/*                    tabmodul                                            */
/*------------------------------------------------------------------------*/
int sisisinst (
     int zugriff,        /* Art der Zugriffsanforderung             */
     int scroll,         /* Typ des Satzzeigers SCROLL/NOSCROLL     */
     int lock,           /* Datensatz sperren  DB_LOCK/DB_NOLOCK    */
     int key,            /* Nummer des Schluessels f. <zugriff>     */
     int sto,            /* ein Satz oder alle (nur DB_dlet())      */
     void *p_daten,      /* Pointer auf Struktur d. DB-Tabelle      */
     char *sel_anw,      /* 1.Teil der SELECT-Anweisung             */
     char *where_anw,    /* 2.Teil der SELECT-Anw (WHERE-Bedingung) */
     void *p_btw_daten,  /* Pointer auf zustzl. Struktur            *
                          * nur fuer DB_rbtw().                     *
                          * beschreibt Obergrenze f.Bereichssuche   */
     char *order_by,     /* Liste der Spaltennamen fuer ORDER BY    */
     char *auf_ab,       /* Sortierung erfolgt aufsteigend (DB_ASC) *
                          *              bzw.  absteigend (DB_DESC) */
     char *group_by,     /* Liste der Spaltennamen fuer GROUP BY    */
     char *having,       /* Bedingung fuer HAVING                   */
     char *into_temp,    /* Name der temp. Tabelle fuer INTO TEMP   */
     long *count         /* fuer Lese-Operationen Rxxx :
                          * wenn Wert bei Aufruf
                          * DO_COUNT : Anzahl Saetze der Ergebnismenge
                          *            ermitteln und in count
                          *            zurueckgeliefern
                          * NULL     : Leseoperation durchfuehren
                          */
             )


...
  /*
   *   Verzeigung zu DB-Operation
   */
  switch (zugriff)
  {
    case  RGEQ  :
    case  RGRT  :
    case  RLEQ  :
    case  RLES  :
    case  RWHR  :
    case  RDIR  :   db_ret = select_record(scroll, lock, key,
                                           sel_anw, where_anw, p_tabdaten,
                                           NOBTW, p_oben,
                                           order_by, auf_ab, group_by,
                                           having, into_temp,
                                           count
                                          );
                    break;






select_record():

static int
select_record (
int             scroll,       /* Angabe, ob SCROLL-Cursor oder sequent.  *
                               * Cursor                                  */
int             lock,         /* Satz sperren oder nicht                 */
int             key,          /* Lesen mit einem Key oder der ganzen     *
                               * Tabelle (NOKEY)                         */
char           *sel_anw,      /* erster Teil der Select-Anweisung        */
char           *where_anw,    /* where- Klausel                          */
t_sisisinst_ec *p_daten,      /* Datensatz :   enthaelt                   *
                               * - Werte d. Schluesselfelder, nach denen  *
                               *   gesucht wird                           *
                               * - nach Suchen : 1. Satz d. Ergebnismenge *
                               * - bei Bereichssuche : Untergrenze        */
int             i_between,    /* Bereichssuche, oder nicht  (BTW/NOBTW)   */
t_sisisinst_ec  *p_oben,      /* Datensatz, Obergrenze des Suchbereichs   *
                               * bei Bereichssuche (i_between==BTW)       */
char            *order_by,    /* Liste der Spaltennamen fuer ORDER BY     */
char            *auf_ab,      /* Sortierung erfolgt aufsteigend (DB_ASC)  *
                               *              bzw.  absteigend (DB_DESC)  */
char            *group_by,    /* Liste der Spaltennamen fuer GROUP BY     */
char            *having,      /* Bedingung fuer HAVING                    */
char            *into_temp,   /* Name der temp. Tabelle fuer INTO TEMP    */
long            *count        /* wenn Wert bei Aufruf
                               * DO_COUNT : Anzahl Saetze der Ergebnismenge
                               *            ermitteln und in count
                               *            zurueckgeliefern
                               * NULL     : Leseoperation durchfuehren
                               */
  )

{
....
  char           select_anw[MAX_SEL_LEN];  /* Bereich fuer aufbereitete */
....
#ifdef ORACLE
  {
  /* how to make valgrind happy */
  char *name = TAB_SISISINST;
  sprintf (select_anw, sel_anw, name, name);      <********* sisisinst.c:1397
  }
#endif



-- 
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

Re: [Valgrind-users] Callgrind

[Brian B. <bri...@gm...>]

You can build openmpi to have better valgrind support.  See the openmpi
docs for details.
On Jul 23, 2014 4:59 AM, "Olaf Lenz" <ol...@ic...> wrote:

> Hi!
>
> It looks as though I'm homing in on the culprit.
> The problem seems to be that the program is MPI-enabled. When disabling
> MPI in ESPResSo, valgrind works fine.
> It should be noted that OpenMPI provides its own compiler wrapper (mpic++)
> around g++ and does some heavy meddling with the internals. I assume that
> this somehow causes valgrind not to be able to use the symbol table. I am
> still looking into it.
>
> Olaf
>
>
> 2014-07-22 23:15 GMT+02:00 Philippe Waroquiers <
> phi...@sk...>:
>
>> On Tue, 2014-07-22 at 15:20 +0200, Olaf Lenz wrote:
>> > I'm using OpenSUSE 12.3, 64bit.
>> > I have used current valgrind and also the SVN version, but to no
>> > avail.
>> > "nm" tells me that the debuginfo is in the binary, but valgrind won't
>> > find it.
>> >
>> >
>> > I did use valgrind to profile other binaries on the same machine,
>> > built with the same compiler, and it worked fine. Could that be
>> > something in the build system of our software? Or am I safe to say
>> > that when nm finds the info, valgrind should, too?
>> What you could do is to take a binary which is ok,
>> and the binary that is not ok.
>>
>> Then for both, you run valgrind, increasing the level of
>> tracing/debugging, until you see a difference which could explain
>> what is going wrong with espresso.
>>
>> You could first try with -v
>> and then succesfully add more -v and more -d (up to 3 each).
>> After that, even more heavyweight tracing can be enabled by adding
>> one or more of :
>> --debug-dump=syms
>> --debug-dump=line
>> --debug-dump=frames
>> --trace-symtab=yes
>>
>> Philippe
>>
>>
>>
>>
>
>
> --
> Dr. rer. nat. Olaf Lenz
> Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
> Phone: +49-711-685-63607
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>

Re: [Valgrind-users] Callgrind

[Olaf L. <ol...@ic...>]

Hi!

It looks as though I'm homing in on the culprit.
The problem seems to be that the program is MPI-enabled. When disabling MPI
in ESPResSo, valgrind works fine.
It should be noted that OpenMPI provides its own compiler wrapper (mpic++)
around g++ and does some heavy meddling with the internals. I assume that
this somehow causes valgrind not to be able to use the symbol table. I am
still looking into it.

Olaf


2014-07-22 23:15 GMT+02:00 Philippe Waroquiers <
phi...@sk...>:

> On Tue, 2014-07-22 at 15:20 +0200, Olaf Lenz wrote:
> > I'm using OpenSUSE 12.3, 64bit.
> > I have used current valgrind and also the SVN version, but to no
> > avail.
> > "nm" tells me that the debuginfo is in the binary, but valgrind won't
> > find it.
> >
> >
> > I did use valgrind to profile other binaries on the same machine,
> > built with the same compiler, and it worked fine. Could that be
> > something in the build system of our software? Or am I safe to say
> > that when nm finds the info, valgrind should, too?
> What you could do is to take a binary which is ok,
> and the binary that is not ok.
>
> Then for both, you run valgrind, increasing the level of
> tracing/debugging, until you see a difference which could explain
> what is going wrong with espresso.
>
> You could first try with -v
> and then succesfully add more -v and more -d (up to 3 each).
> After that, even more heavyweight tracing can be enabled by adding
> one or more of :
> --debug-dump=syms
> --debug-dump=line
> --debug-dump=frames
> --trace-symtab=yes
>
> Philippe
>
>
>
>


-- 
Dr. rer. nat. Olaf Lenz
Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
Phone: +49-711-685-63607

Re: [Valgrind-users] Callgrind

[Philippe W. <phi...@sk...>]

On Tue, 2014-07-22 at 15:20 +0200, Olaf Lenz wrote:
> I'm using OpenSUSE 12.3, 64bit.
> I have used current valgrind and also the SVN version, but to no
> avail.
> "nm" tells me that the debuginfo is in the binary, but valgrind won't
> find it.
> 
> 
> I did use valgrind to profile other binaries on the same machine,
> built with the same compiler, and it worked fine. Could that be
> something in the build system of our software? Or am I safe to say
> that when nm finds the info, valgrind should, too?
What you could do is to take a binary which is ok,
and the binary that is not ok.

Then for both, you run valgrind, increasing the level of
tracing/debugging, until you see a difference which could explain
what is going wrong with espresso.

You could first try with -v 
and then succesfully add more -v and more -d (up to 3 each).
After that, even more heavyweight tracing can be enabled by adding
one or more of :
--debug-dump=syms
--debug-dump=line
--debug-dump=frames
--trace-symtab=yes

Philippe

Re: [Valgrind-users] Callgrind

[Philippe W. <phi...@sk...>]

On Tue, 2014-07-22 at 14:48 +0200, Josef Weidendorfer wrote:
> Am 22.07.2014 14:31, schrieb Olaf Lenz:
> > Hi Josef!
> > 
> > I have just installed valgrind-3.9.0, and it doesn't solve the problem. 
> > Also, the problem seems to be there in memcheck, so it seems to be a
> > problem with the debuginfo loader.
> > Is there a way to explicitly check the loader?
> 
> Hmm. You could check the current SVN version. There are some fixes
> for the DWARF loader. Also, a sync with the demangler code from
> gdb was recently done.
> Or recompile (part of the code) with different debug info generation
> flags of the compiler (-gdwarf-3, -gstabs, ..).
Note that valgrind stabs reader is broken and disabled since 3.9.0.

Philippe

Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

[Anmol P. <An...@fr...>]

Hi Rajendra,

Glad to hear! You are most welcome. Thank you for the note.
Do let us know how the experience using the tool on the p2020 goes.

Regards,
Anmol.

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Tuesday, July 22, 2014 9:45 AM
To: Paralkar Anmol-B07584; val...@li...
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Anmol,

Thanks for all the help. I tried valgrind sources in Freescale SDK 1.6 and I am able to run valgrind on P2020 with powerpcspe ABI.

Regards,
Rajendra

From: Anmol Paralkar [mailto:An...@fr...]
Sent: Monday, July 21, 2014 7:18 PM
To: Rajendra Dendukuri; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Rajendra,

The port also comes with a regression test that has a unit-test for each SPE insn, please see: https://bugs.kde.org/show_bug.cgi?id=321396#c7

Thanks,
Anmol.

From: Paralkar Anmol-B07584
Sent: Monday, July 21, 2014 5:58 PM
To: 'Rajendra Dendukuri'; 'val...@li...'
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Rajendra,


 Actually, see:  meta-fsl-networking/recipes-devtools/valgrind/files/*.patch
and the SRC_URI variable in meta-fsl-networking/recipes-devtools/valgrind/valgrind_fsl.bb that lists the patches that get applied in the SDK.

Regards,
Anmol.

From: Paralkar Anmol-B07584
Sent: Monday, July 21, 2014 5:43 PM
To: 'Rajendra Dendukuri'; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Rajendra,

We do not have them in 3.9.0 but following http://valgrind.org/downloads/repository.html if you get a current repository then
doing a: 'svn diff -c 13504 configure.ac' likely gets you the patch that you are looking for.

Regards,
Anmol.

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Monday, July 21, 2014 5:14 PM
To: Paralkar Anmol-B07584; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

HI Anmol,

Thanks for all the help.

I downloaded the 1.6 SDK and was able to find the valgrind-3.8.1. However the buildroot based cross-toolchain uses glibc-2.18 which is not supported in valgrind-3.8.1. It requires later versions of 3.9.0 onwards. Can you please let me know if the SPE patches are available for a Valgrind-3.9.0 based sources.

Regards,
Rajendra

From: Anmol Paralkar [mailto:An...@fr...]
Sent: Monday, July 21, 2014 1:42 PM
To: Rajendra Dendukuri; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Saturday, July 19, 2014 6:22 PM
To: val...@li...<mailto:val...@li...>
Subject: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi,

I noticed that Valgrind-3.9.0 does not support the powerpc SPE based toolchains for e500v2 based platforms.  buildroot currently does not allow classic PowerPC ABI to be selectable for e500v2/e500v1 class of machines.

I do not want to switch to classic ABI as I want to build toolchains out of buildroot without any customizations. Is there any patch available for Valgrind to support SPE instructions.

Thanks,
Rajendra Dendukuri
[]
Hi Rajendra,

We have made available, a Valgrind-3.8.1 based port to e500v2 SPE; please see: https://bugs.kde.org/show_bug.cgi?id=321396#c6
The instructions are for an earlier version of the SDK, but everything should essentially still be the same, please use:
https://www.freescale.com/webapp/Download?colCode=QorIQ-SDK-V1.6-SOURCE&appType=license&location=null&Parent_nodeId=1305667348816721107821&Parent_pageType=product


Best Regards,
Anmol P. Paralkar

Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

[Rajendra D. <raj...@br...>]

Hi Anmol,

Thanks for all the help. I tried valgrind sources in Freescale SDK 1.6 and I am able to run valgrind on P2020 with powerpcspe ABI.

Regards,
Rajendra

From: Anmol Paralkar [mailto:An...@fr...]
Sent: Monday, July 21, 2014 7:18 PM
To: Rajendra Dendukuri; val...@li...
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Rajendra,

The port also comes with a regression test that has a unit-test for each SPE insn, please see: https://bugs.kde.org/show_bug.cgi?id=321396#c7

Thanks,
Anmol.

From: Paralkar Anmol-B07584
Sent: Monday, July 21, 2014 5:58 PM
To: 'Rajendra Dendukuri'; 'val...@li...'
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Rajendra,


 Actually, see:  meta-fsl-networking/recipes-devtools/valgrind/files/*.patch
and the SRC_URI variable in meta-fsl-networking/recipes-devtools/valgrind/valgrind_fsl.bb that lists the patches that get applied in the SDK.

Regards,
Anmol.

From: Paralkar Anmol-B07584
Sent: Monday, July 21, 2014 5:43 PM
To: 'Rajendra Dendukuri'; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Rajendra,

We do not have them in 3.9.0 but following http://valgrind.org/downloads/repository.html if you get a current repository then
doing a: 'svn diff -c 13504 configure.ac' likely gets you the patch that you are looking for.

Regards,
Anmol.

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Monday, July 21, 2014 5:14 PM
To: Paralkar Anmol-B07584; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

HI Anmol,

Thanks for all the help.

I downloaded the 1.6 SDK and was able to find the valgrind-3.8.1. However the buildroot based cross-toolchain uses glibc-2.18 which is not supported in valgrind-3.8.1. It requires later versions of 3.9.0 onwards. Can you please let me know if the SPE patches are available for a Valgrind-3.9.0 based sources.

Regards,
Rajendra

From: Anmol Paralkar [mailto:An...@fr...]
Sent: Monday, July 21, 2014 1:42 PM
To: Rajendra Dendukuri; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Saturday, July 19, 2014 6:22 PM
To: val...@li...<mailto:val...@li...>
Subject: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi,

I noticed that Valgrind-3.9.0 does not support the powerpc SPE based toolchains for e500v2 based platforms.  buildroot currently does not allow classic PowerPC ABI to be selectable for e500v2/e500v1 class of machines.

I do not want to switch to classic ABI as I want to build toolchains out of buildroot without any customizations. Is there any patch available for Valgrind to support SPE instructions.

Thanks,
Rajendra Dendukuri
[]
Hi Rajendra,

We have made available, a Valgrind-3.8.1 based port to e500v2 SPE; please see: https://bugs.kde.org/show_bug.cgi?id=321396#c6
The instructions are for an earlier version of the SDK, but everything should essentially still be the same, please use:
https://www.freescale.com/webapp/Download?colCode=QorIQ-SDK-V1.6-SOURCE&appType=license&location=null&Parent_nodeId=1305667348816721107821&Parent_pageType=product


Best Regards,
Anmol P. Paralkar

Re: [Valgrind-users] Callgrind

[Olaf L. <ol...@ic...>]

I'm using OpenSUSE 12.3, 64bit.
I have used current valgrind and also the SVN version, but to no avail.
"nm" tells me that the debuginfo is in the binary, but valgrind won't find
it.

I did use valgrind to profile other binaries on the same machine, built
with the same compiler, and it worked fine. Could that be something in the
build system of our software? Or am I safe to say that when nm finds the
info, valgrind should, too?

Olaf


2014-07-22 14:48 GMT+02:00 Josef Weidendorfer <Jos...@gm...>:

> Am 22.07.2014 14:31, schrieb Olaf Lenz:
> > Hi Josef!
> >
> > I have just installed valgrind-3.9.0, and it doesn't solve the problem.
> > Also, the problem seems to be there in memcheck, so it seems to be a
> > problem with the debuginfo loader.
> > Is there a way to explicitly check the loader?
>
> Hmm. You could check the current SVN version. There are some fixes
> for the DWARF loader. Also, a sync with the demangler code from
> gdb was recently done.
> Or recompile (part of the code) with different debug info generation
> flags of the compiler (-gdwarf-3, -gstabs, ..).
> What compiler/architecture is this?
>
> Josef
>
>
> >
> > Olaf
> >
> >
> > 2014-07-22 10:25 GMT+02:00 Josef Weidendorfer <Jos...@gm...
> > <mailto:Jos...@gm...>>:
> >
> >     Hi Olaf,
> >
> >     Am 21.07.2014 14 <tel:21.07.2014%2014>:48, schrieb Olaf Lenz:
> >     > Hi everybody!
> >     >
> >     > I am trying to use callgrind (3.8.0) to profile our simulation
> software
> >     > ESPResSo (http://espressomd.org) on Linux.
> >     >
> >     > Unfortunately, callgrind seems to loose the information on where
> to find
> >     > the source files when running the binary.  When I use 'nm -lC
> Espresso'
> >     > on the binary file, I see that the binary does contain the source
> code
> >     > information, e.g.:
> >
> >     Can you check out with Valgrind 3.9.0 ?
> >     This is not Callgrind related, but about the debuginfo loader, which
> >     also
> >     should affect the other tools, such as memcheck output on finding
> >     errors.
> >     It would be good if you can confirm that.
> >
> >     If the problem persists, please open a bug.
> >
> >     Josef
> >
> >     >
> >     > 000000000049e605 W add_lj_pair_force(Particle*, Particle*,
> >     > IA_parameters*, double*, double, double*)
> >     >  /home/olenz/projects/espresso/src/src/core/lj.hpp:45
> >     >
> >     > However, when I run the binary under callgrind, the output file
> does not
> >     > contain any of the symbols from the binary file, but only the
> addresses.
> >     >
> >     > Interestingly, when I test callgrind on a simple test program,
> >     > everything works fine...
> >     >
> >     > Steps to reproduce:
> >     > 1. Download source code.
> >     > 2. Compile with
> >     >> configure CXXFLAGS="-O0 -g"
> >     >> make
> >     > 3. Check the binary file that it contains symbols:
> >     >> nm -lC Espresso | grep add_lj_pair_force
> >     > 4. Run test with
> >     >> cd testsuite
> >     >> valgrind --tool=callgrind ../Espresso lj.tcl
> >     > 5. Examine "callgrind.out.XXX": no symbols are contained.
> >     >
> >     > Does anybody have an idea what goes wrong?
> >     >
> >     > Olaf
> >     >
> >     > --
> >     > Dr. rer. nat. Olaf Lenz
> >     > Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
> >     > Phone: +49-711-685-63607
> >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     > Want fast and easy access to all the code in your enterprise?
> Index and
> >     > search up to 200,000 lines of code with a free copy of Black Duck
> >     > Code Sight - the same software that powers the world's largest code
> >     > search on Ohloh, the Black Duck Open Hub! Try it now.
> >     > http://p.sf.net/sfu/bds
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Valgrind-users mailing list
> >     > Val...@li...
> >     <mailto:Val...@li...>
> >     > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >     >
> >
> >
> ------------------------------------------------------------------------------
> >     Want fast and easy access to all the code in your enterprise? Index
> and
> >     search up to 200,000 lines of code with a free copy of Black Duck
> >     Code Sight - the same software that powers the world's largest code
> >     search on Ohloh, the Black Duck Open Hub! Try it now.
> >     http://p.sf.net/sfu/bds
> >     _______________________________________________
> >     Valgrind-users mailing list
> >     Val...@li...
> >     <mailto:Val...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> >
> >
> >
> > --
> > Dr. rer. nat. Olaf Lenz
> > Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
> > Phone: +49-711-685-63607
>
>


-- 
Dr. rer. nat. Olaf Lenz
Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
Phone: +49-711-685-63607

Re: [Valgrind-users] Callgrind

[Josef W. <Jos...@gm...>]

Am 22.07.2014 14:31, schrieb Olaf Lenz:
> Hi Josef!
> 
> I have just installed valgrind-3.9.0, and it doesn't solve the problem. 
> Also, the problem seems to be there in memcheck, so it seems to be a
> problem with the debuginfo loader.
> Is there a way to explicitly check the loader?

Hmm. You could check the current SVN version. There are some fixes
for the DWARF loader. Also, a sync with the demangler code from
gdb was recently done.
Or recompile (part of the code) with different debug info generation
flags of the compiler (-gdwarf-3, -gstabs, ..).
What compiler/architecture is this?

Josef


> 
> Olaf
> 
> 
> 2014-07-22 10:25 GMT+02:00 Josef Weidendorfer <Jos...@gm...
> <mailto:Jos...@gm...>>:
> 
>     Hi Olaf,
> 
>     Am 21.07.2014 14 <tel:21.07.2014%2014>:48, schrieb Olaf Lenz:
>     > Hi everybody!
>     >
>     > I am trying to use callgrind (3.8.0) to profile our simulation software
>     > ESPResSo (http://espressomd.org) on Linux.
>     >
>     > Unfortunately, callgrind seems to loose the information on where to find
>     > the source files when running the binary.  When I use 'nm -lC Espresso'
>     > on the binary file, I see that the binary does contain the source code
>     > information, e.g.:
> 
>     Can you check out with Valgrind 3.9.0 ?
>     This is not Callgrind related, but about the debuginfo loader, which
>     also
>     should affect the other tools, such as memcheck output on finding
>     errors.
>     It would be good if you can confirm that.
> 
>     If the problem persists, please open a bug.
> 
>     Josef
> 
>     >
>     > 000000000049e605 W add_lj_pair_force(Particle*, Particle*,
>     > IA_parameters*, double*, double, double*)
>     >  /home/olenz/projects/espresso/src/src/core/lj.hpp:45
>     >
>     > However, when I run the binary under callgrind, the output file does not
>     > contain any of the symbols from the binary file, but only the addresses.
>     >
>     > Interestingly, when I test callgrind on a simple test program,
>     > everything works fine...
>     >
>     > Steps to reproduce:
>     > 1. Download source code.
>     > 2. Compile with
>     >> configure CXXFLAGS="-O0 -g"
>     >> make
>     > 3. Check the binary file that it contains symbols:
>     >> nm -lC Espresso | grep add_lj_pair_force
>     > 4. Run test with
>     >> cd testsuite
>     >> valgrind --tool=callgrind ../Espresso lj.tcl
>     > 5. Examine "callgrind.out.XXX": no symbols are contained.
>     >
>     > Does anybody have an idea what goes wrong?
>     >
>     > Olaf
>     >
>     > --
>     > Dr. rer. nat. Olaf Lenz
>     > Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
>     > Phone: +49-711-685-63607
>     >
>     >
>     > ------------------------------------------------------------------------------
>     > Want fast and easy access to all the code in your enterprise? Index and
>     > search up to 200,000 lines of code with a free copy of Black Duck
>     > Code Sight - the same software that powers the world's largest code
>     > search on Ohloh, the Black Duck Open Hub! Try it now.
>     > http://p.sf.net/sfu/bds
>     >
>     >
>     >
>     > _______________________________________________
>     > Valgrind-users mailing list
>     > Val...@li...
>     <mailto:Val...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>     >
> 
>     ------------------------------------------------------------------------------
>     Want fast and easy access to all the code in your enterprise? Index and
>     search up to 200,000 lines of code with a free copy of Black Duck
>     Code Sight - the same software that powers the world's largest code
>     search on Ohloh, the Black Duck Open Hub! Try it now.
>     http://p.sf.net/sfu/bds
>     _______________________________________________
>     Valgrind-users mailing list
>     Val...@li...
>     <mailto:Val...@li...>
>     https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> 
> 
> -- 
> Dr. rer. nat. Olaf Lenz
> Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
> Phone: +49-711-685-63607

Re: [Valgrind-users] Callgrind

[Olaf L. <ol...@ic...>]

Hi Josef!

I have just installed valgrind-3.9.0, and it doesn't solve the problem.
Also, the problem seems to be there in memcheck, so it seems to be a
problem with the debuginfo loader.
Is there a way to explicitly check the loader?

Olaf


2014-07-22 10:25 GMT+02:00 Josef Weidendorfer <Jos...@gm...>:

> Hi Olaf,
>
> Am 21.07.2014 14:48, schrieb Olaf Lenz:
> > Hi everybody!
> >
> > I am trying to use callgrind (3.8.0) to profile our simulation software
> > ESPResSo (http://espressomd.org) on Linux.
> >
> > Unfortunately, callgrind seems to loose the information on where to find
> > the source files when running the binary.  When I use 'nm -lC Espresso'
> > on the binary file, I see that the binary does contain the source code
> > information, e.g.:
>
> Can you check out with Valgrind 3.9.0 ?
> This is not Callgrind related, but about the debuginfo loader, which also
> should affect the other tools, such as memcheck output on finding errors.
> It would be good if you can confirm that.
>
> If the problem persists, please open a bug.
>
> Josef
>
> >
> > 000000000049e605 W add_lj_pair_force(Particle*, Particle*,
> > IA_parameters*, double*, double, double*)
> >  /home/olenz/projects/espresso/src/src/core/lj.hpp:45
> >
> > However, when I run the binary under callgrind, the output file does not
> > contain any of the symbols from the binary file, but only the addresses.
> >
> > Interestingly, when I test callgrind on a simple test program,
> > everything works fine...
> >
> > Steps to reproduce:
> > 1. Download source code.
> > 2. Compile with
> >> configure CXXFLAGS="-O0 -g"
> >> make
> > 3. Check the binary file that it contains symbols:
> >> nm -lC Espresso | grep add_lj_pair_force
> > 4. Run test with
> >> cd testsuite
> >> valgrind --tool=callgrind ../Espresso lj.tcl
> > 5. Examine "callgrind.out.XXX": no symbols are contained.
> >
> > Does anybody have an idea what goes wrong?
> >
> > Olaf
> >
> > --
> > Dr. rer. nat. Olaf Lenz
> > Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
> > Phone: +49-711-685-63607
> >
> >
> >
> ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise? Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>


-- 
Dr. rer. nat. Olaf Lenz
Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
Phone: +49-711-685-63607

Re: [Valgrind-users] [Question] If "-static" linker option can influence the result of memory leak check?

[Tom H. <to...@co...>]

On 22/07/14 10:21, quentin.li wrote:

>      I use Codeblocks create a project to do some device operations in
> my code,
>      and find that if I use "-static" as linker option, memory leak of
> the executable file create by Codeblocks won't be detected by valgrind.
>      Like the memory I malloc that not released by calling free.
>      But if I close "-static" linker option, all memory leak will be
> detected again.
>      I use cmd: "valgrind --tool=memcheck --leak-check=full .//MyProgram/".
>      Can anyone kindly tell me why?

http://valgrind.org/docs/manual/faq.html#faq.hiddenbug

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] [Question] If "-static" linker option can influence the result of memory leak check?

[quentin.li <sno...@16...>]

Hi,
    I use Codeblocks create a project to do some device operations in my code,
    and find that if I use "-static" as linker option, memory leak of the executable file create by Codeblocks won't be detected by valgrind.
    Like the memory I malloc that not released by calling free.
    But if I close "-static" linker option, all memory leak will be detected again.
    I use cmd: "valgrind --tool=memcheck --leak-check=full ./MyProgram".
    Can anyone kindly tell me why?


BR

[Valgrind-users] valgrind-3.9.0 on MIPS64 fails to load any binary

[Filip B. <fil...@gm...>]

Hi, anyone can help with this problem of valgrind failure on an
embedded mips  platform?

Executing valgrind /bin/ls (as well as with any other binary) always
fails shortly after starting because of:

Inconsistency detected by ld.so: ../elf/dl-sysdep.c: 457:
_dl_important_hwcaps: Assertion `m == cnt' failed!

This is Linux version 2.6.27.39 (gcc version 4.3.2 ) #1 SMP PREEMPT
Thu Mar 27 14:46:35 KST 2014 mips64 mips64 mips64 GNU/Linux

with glibc 2.8, ld-2.8.so

valgrind was cross compiled.

I have little experience with linux shared lib mechanics so not sure
what is needed to investigate this but I am willing to provide
necessary information if specific instructions are given.

Regards,
Filip

Re: [Valgrind-users] Callgrind

[Josef W. <Jos...@gm...>]

Hi Olaf,

Am 21.07.2014 14:48, schrieb Olaf Lenz:
> Hi everybody!
> 
> I am trying to use callgrind (3.8.0) to profile our simulation software
> ESPResSo (http://espressomd.org) on Linux.
> 
> Unfortunately, callgrind seems to loose the information on where to find
> the source files when running the binary.  When I use 'nm -lC Espresso'
> on the binary file, I see that the binary does contain the source code
> information, e.g.:

Can you check out with Valgrind 3.9.0 ?
This is not Callgrind related, but about the debuginfo loader, which also
should affect the other tools, such as memcheck output on finding errors.
It would be good if you can confirm that.

If the problem persists, please open a bug.

Josef

> 
> 000000000049e605 W add_lj_pair_force(Particle*, Particle*,
> IA_parameters*, double*, double, double*)  
>  /home/olenz/projects/espresso/src/src/core/lj.hpp:45
> 
> However, when I run the binary under callgrind, the output file does not
> contain any of the symbols from the binary file, but only the addresses.
> 
> Interestingly, when I test callgrind on a simple test program,
> everything works fine...
> 
> Steps to reproduce:
> 1. Download source code.
> 2. Compile with 
>> configure CXXFLAGS="-O0 -g"
>> make
> 3. Check the binary file that it contains symbols:
>> nm -lC Espresso | grep add_lj_pair_force
> 4. Run test with
>> cd testsuite
>> valgrind --tool=callgrind ../Espresso lj.tcl
> 5. Examine "callgrind.out.XXX": no symbols are contained.
> 
> Does anybody have an idea what goes wrong?
> 
> Olaf
> 
> -- 
> Dr. rer. nat. Olaf Lenz
> Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
> Phone: +49-711-685-63607
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Valgrind doesnot show any memory Leaks

[Jonnavithula S. <sar...@gm...>]

Hi Julian,

Thanks for the big help.. It worked for me with the LD_PRELOAD Support
enabled.
I am surprised how valgrind didnot mention regarding this in any of their
docs.

Anyhow,Thanks again valgrind is working in my environment .


Regards,
Sarma J



On Tue, Jul 15, 2014 at 2:06 PM, Julian Seward <js...@ac...> wrote:

>
> I think we saw recently (last couple of months?) a case where Memcheck
> didn't do any intercepts with uClibC, and it turned out that the problem
> was that uClibc had not been built with LD_PRELOAD support.  So the
> intercept .so never got loaded into the process.  I wonder if that is
> the case here?
>
> J
>
> On 07/09/2014 12:43 PM, Philippe Waroquiers wrote:
> > On Wed, 2014-07-09 at 15:58 +0530, Jonnavithula Sharma wrote:
> >> Hi ,
> >>
> > ...
> >> But somehow there were no leaks detected and the output is as
> >> below(attached is the complete valgrind output)
> >>
> > ...
> >> Any suggestions or help is highly appreciated.
> >>
> >>
> >> I am compiling my application with all debug options as well. I was
> >> struck and not able to proceed ahead.
> >
> > The most frequent source of this kind of problems is the fact
> > that the malloc library is statically linked with your app.
> >
> > You must then indicate that to valgrind, using the option
> >    --soname-synonyms=...
> > (see user manual for details).
> >
> > If that is not the case, then the 2nd most frequent source of problem
> > is that the redirection of the malloc etc symbols are not done
> > due to the name of the library not being what is expected by valgrind.
> > Use the options -v -v -v -d -d -d --trace-redir=yes
> > and try to understand what is going wrong.
> >
> >
> > Philippe
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community
> Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>

Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

[Anmol P. <An...@fr...>]

Hi Rajendra,


 Actually, see:  meta-fsl-networking/recipes-devtools/valgrind/files/*.patch
and the SRC_URI variable in meta-fsl-networking/recipes-devtools/valgrind/valgrind_fsl.bb that lists the patches that get applied in the SDK.
Regards,
Anmol.

From: Paralkar Anmol-B07584
Sent: Monday, July 21, 2014 5:43 PM
To: 'Rajendra Dendukuri'; val...@li...
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Rajendra,

We do not have them in 3.9.0 but following http://valgrind.org/downloads/repository.html if you get a current repository then
doing a: 'svn diff -c 13504 configure.ac' likely gets you the patch that you are looking for.

Regards,
Anmol.

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Monday, July 21, 2014 5:14 PM
To: Paralkar Anmol-B07584; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

HI Anmol,

Thanks for all the help.

I downloaded the 1.6 SDK and was able to find the valgrind-3.8.1. However the buildroot based cross-toolchain uses glibc-2.18 which is not supported in valgrind-3.8.1. It requires later versions of 3.9.0 onwards. Can you please let me know if the SPE patches are available for a Valgrind-3.9.0 based sources.

Regards,
Rajendra

From: Anmol Paralkar [mailto:An...@fr...]
Sent: Monday, July 21, 2014 1:42 PM
To: Rajendra Dendukuri; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Saturday, July 19, 2014 6:22 PM
To: val...@li...<mailto:val...@li...>
Subject: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi,

I noticed that Valgrind-3.9.0 does not support the powerpc SPE based toolchains for e500v2 based platforms.  buildroot currently does not allow classic PowerPC ABI to be selectable for e500v2/e500v1 class of machines.

I do not want to switch to classic ABI as I want to build toolchains out of buildroot without any customizations. Is there any patch available for Valgrind to support SPE instructions.

Thanks,
Rajendra Dendukuri
[]
Hi Rajendra,

We have made available, a Valgrind-3.8.1 based port to e500v2 SPE; please see: https://bugs.kde.org/show_bug.cgi?id=321396#c6
The instructions are for an earlier version of the SDK, but everything should essentially still be the same, please use:
https://www.freescale.com/webapp/Download?colCode=QorIQ-SDK-V1.6-SOURCE&appType=license&location=null&Parent_nodeId=1305667348816721107821&Parent_pageType=product


Best Regards,
Anmol P. Paralkar

Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

[Anmol P. <An...@fr...>]

Hi Rajendra,

The port also comes with a regression test that has a unit-test for each SPE insn, please see: https://bugs.kde.org/show_bug.cgi?id=321396#c7

Thanks,
Anmol.

From: Paralkar Anmol-B07584
Sent: Monday, July 21, 2014 5:58 PM
To: 'Rajendra Dendukuri'; 'val...@li...'
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Rajendra,


 Actually, see:  meta-fsl-networking/recipes-devtools/valgrind/files/*.patch
and the SRC_URI variable in meta-fsl-networking/recipes-devtools/valgrind/valgrind_fsl.bb that lists the patches that get applied in the SDK.

Regards,
Anmol.

From: Paralkar Anmol-B07584
Sent: Monday, July 21, 2014 5:43 PM
To: 'Rajendra Dendukuri'; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi Rajendra,

We do not have them in 3.9.0 but following http://valgrind.org/downloads/repository.html if you get a current repository then
doing a: 'svn diff -c 13504 configure.ac' likely gets you the patch that you are looking for.

Regards,
Anmol.

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Monday, July 21, 2014 5:14 PM
To: Paralkar Anmol-B07584; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

HI Anmol,

Thanks for all the help.

I downloaded the 1.6 SDK and was able to find the valgrind-3.8.1. However the buildroot based cross-toolchain uses glibc-2.18 which is not supported in valgrind-3.8.1. It requires later versions of 3.9.0 onwards. Can you please let me know if the SPE patches are available for a Valgrind-3.9.0 based sources.

Regards,
Rajendra

From: Anmol Paralkar [mailto:An...@fr...]
Sent: Monday, July 21, 2014 1:42 PM
To: Rajendra Dendukuri; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Saturday, July 19, 2014 6:22 PM
To: val...@li...<mailto:val...@li...>
Subject: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi,

I noticed that Valgrind-3.9.0 does not support the powerpc SPE based toolchains for e500v2 based platforms.  buildroot currently does not allow classic PowerPC ABI to be selectable for e500v2/e500v1 class of machines.

I do not want to switch to classic ABI as I want to build toolchains out of buildroot without any customizations. Is there any patch available for Valgrind to support SPE instructions.

Thanks,
Rajendra Dendukuri
[]
Hi Rajendra,

We have made available, a Valgrind-3.8.1 based port to e500v2 SPE; please see: https://bugs.kde.org/show_bug.cgi?id=321396#c6
The instructions are for an earlier version of the SDK, but everything should essentially still be the same, please use:
https://www.freescale.com/webapp/Download?colCode=QorIQ-SDK-V1.6-SOURCE&appType=license&location=null&Parent_nodeId=1305667348816721107821&Parent_pageType=product


Best Regards,
Anmol P. Paralkar

Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

[Anmol P. <An...@fr...>]

Hi Rajendra,

We do not have them in 3.9.0 but following http://valgrind.org/downloads/repository.html if you get a current repository then
doing a: 'svn diff -c 13504 configure.ac' likely gets you the patch that you are looking for.

Regards,
Anmol.

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Monday, July 21, 2014 5:14 PM
To: Paralkar Anmol-B07584; val...@li...
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

HI Anmol,

Thanks for all the help.

I downloaded the 1.6 SDK and was able to find the valgrind-3.8.1. However the buildroot based cross-toolchain uses glibc-2.18 which is not supported in valgrind-3.8.1. It requires later versions of 3.9.0 onwards. Can you please let me know if the SPE patches are available for a Valgrind-3.9.0 based sources.

Regards,
Rajendra

From: Anmol Paralkar [mailto:An...@fr...]
Sent: Monday, July 21, 2014 1:42 PM
To: Rajendra Dendukuri; val...@li...<mailto:val...@li...>
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Saturday, July 19, 2014 6:22 PM
To: val...@li...<mailto:val...@li...>
Subject: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi,

I noticed that Valgrind-3.9.0 does not support the powerpc SPE based toolchains for e500v2 based platforms.  buildroot currently does not allow classic PowerPC ABI to be selectable for e500v2/e500v1 class of machines.

I do not want to switch to classic ABI as I want to build toolchains out of buildroot without any customizations. Is there any patch available for Valgrind to support SPE instructions.

Thanks,
Rajendra Dendukuri
[]
Hi Rajendra,

We have made available, a Valgrind-3.8.1 based port to e500v2 SPE; please see: https://bugs.kde.org/show_bug.cgi?id=321396#c6
The instructions are for an earlier version of the SDK, but everything should essentially still be the same, please use:
https://www.freescale.com/webapp/Download?colCode=QorIQ-SDK-V1.6-SOURCE&appType=license&location=null&Parent_nodeId=1305667348816721107821&Parent_pageType=product


Best Regards,
Anmol P. Paralkar

Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

[Rajendra D. <raj...@br...>]

HI Anmol,

Thanks for all the help.

I downloaded the 1.6 SDK and was able to find the valgrind-3.8.1. However the buildroot based cross-toolchain uses glibc-2.18 which is not supported in valgrind-3.8.1. It requires later versions of 3.9.0 onwards. Can you please let me know if the SPE patches are available for a Valgrind-3.9.0 based sources.

Regards,
Rajendra

From: Anmol Paralkar [mailto:An...@fr...]
Sent: Monday, July 21, 2014 1:42 PM
To: Rajendra Dendukuri; val...@li...
Subject: RE: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Saturday, July 19, 2014 6:22 PM
To: val...@li...<mailto:val...@li...>
Subject: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi,

I noticed that Valgrind-3.9.0 does not support the powerpc SPE based toolchains for e500v2 based platforms.  buildroot currently does not allow classic PowerPC ABI to be selectable for e500v2/e500v1 class of machines.

I do not want to switch to classic ABI as I want to build toolchains out of buildroot without any customizations. Is there any patch available for Valgrind to support SPE instructions.

Thanks,
Rajendra Dendukuri
[]
Hi Rajendra,

We have made available, a Valgrind-3.8.1 based port to e500v2 SPE; please see: https://bugs.kde.org/show_bug.cgi?id=321396#c6
The instructions are for an earlier version of the SDK, but everything should essentially still be the same, please use:
https://www.freescale.com/webapp/Download?colCode=QorIQ-SDK-V1.6-SOURCE&appType=license&location=null&Parent_nodeId=1305667348816721107821&Parent_pageType=product


Best Regards,
Anmol P. Paralkar

Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

[Anmol P. <An...@fr...>]

From: Rajendra Dendukuri [mailto:raj...@br...]
Sent: Saturday, July 19, 2014 6:22 PM
To: val...@li...
Subject: [Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

Hi,

I noticed that Valgrind-3.9.0 does not support the powerpc SPE based toolchains for e500v2 based platforms.  buildroot currently does not allow classic PowerPC ABI to be selectable for e500v2/e500v1 class of machines.

I do not want to switch to classic ABI as I want to build toolchains out of buildroot without any customizations. Is there any patch available for Valgrind to support SPE instructions.

Thanks,
Rajendra Dendukuri
[]
Hi Rajendra,

We have made available, a Valgrind-3.8.1 based port to e500v2 SPE; please see: https://bugs.kde.org/show_bug.cgi?id=321396#c6
The instructions are for an earlier version of the SDK (v1.5), but everything should essentially still be the same for SDK (v1.6), please use:
https://www.freescale.com/webapp/Download?colCode=QorIQ-SDK-V1.6-SOURCE&appType=license&location=null&Parent_nodeId=1305667348816721107821&Parent_pageType=product


Best Regards,
Anmol P. Paralkar