valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] detection of gcc version

[Kissami I. <kis...@gm...>]

Hello, 
Thanks for your response,
> Which version of mac/os?
The latest one 10.13 high sierra, I checked in valgrind code source and I see that is no supported (this valgrind version support only 16.* versions) 
> Which version of valgrind?
Valgrind version is 3.13.0


I modified the source code with adding same option for darwin 17.* and I success to install valgrind but when I used it for profiling I had this warning

--55943-- WARNING: unhandled amd64-darwin syscall: unix:464
--55943-- You may be able to write your own handler.
--55943-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--55943-- Nevertheless we consider this a bug.  Please report
--55943-- it at http://valgrind.org/support/bug_reports.html.
--55943-- WARNING: unhandled amd64-darwin syscall: unix:464
--55943-- You may be able to write your own handler.
--55943-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--55943-- Nevertheless we consider this a bug.  Please report
--55943-- it at http://valgrind.org/support/bug_reports.html.


and the running of code is stopped.

Best regards,




Imad Kissami
Post-Doc 
Université Paris 13, Sorbonne Paris Cité
LAGA
99, av. J-B Clément 93430 Villetaneuse, France

> Le 21 nov. 2017 à 15:01, John Reiser <jr...@bi...> a écrit :
> 
> *ALWAYS* give an appropriate Subject: when posting an inquiry.
> 
> On 11/21/2017 1004Z, Kissami Imad wrote in a posting with no subject:
> 
>> I was using valgrind on my Mac, but when I installed the last version of mac/os valgrind doesn't work.
> 
> Which version of mac/os?
> Which version of valgrind?
> 
>> When i run ./configure I have this error message : please use gcc => 3.0 ....
>> My gcc version is 4.2.1
>> clang version is 5.0
>> icc version is 15.0.2
> 
> Look in config.log, which is created by running ./configure, such as:
>> This file contains any messages produced by compilers while
>> running configure, to aid debugging if configure makes a mistake.
>> It was created by Valgrind configure 3.13.0, which was
>> generated by GNU Autoconf 2.69.  Invocation command line was
>>  $ ./configure --prefix=my_prefix
> 
> Look for the section that detects compiler configuration, such as:
>> configure:3404: checking for gcc
>> configure:3420: found /usr/bin/gcc
>> configure:3431: result: gcc
>> configure:3660: checking for C compiler version
>> configure:3669: gcc --version >&5
>> gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
>> Copyright (C) 2016 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> configure:3680: $? = 0
>> configure:3669: gcc -v >&5
> 
> Copy+paste (into a reply to this posting) what you see in _your_ config.log.
> Copy+paste any other lines related to detection of a compiler.
> What clues do those messages give you?
> 
> -- 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] detection of gcc version

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

*ALWAYS* give an appropriate Subject: when posting an inquiry.

On 11/21/2017 1004Z, Kissami Imad wrote in a posting with no subject:

> I was using valgrind on my Mac, but when I installed the last version of mac/os valgrind doesn't work.

Which version of mac/os?
Which version of valgrind?

> When i run ./configure I have this error message : please use gcc => 3.0 ....
> My gcc version is 4.2.1
> clang version is 5.0
> icc version is 15.0.2
> 

Look in config.log, which is created by running ./configure, such as:
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> It was created by Valgrind configure 3.13.0, which was
> generated by GNU Autoconf 2.69.  Invocation command line was
> 
>   $ ./configure --prefix=my_prefix

Look for the section that detects compiler configuration, such as:
> configure:3404: checking for gcc
> configure:3420: found /usr/bin/gcc
> configure:3431: result: gcc
> configure:3660: checking for C compiler version
> configure:3669: gcc --version >&5
> gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> configure:3680: $? = 0
> configure:3669: gcc -v >&5

Copy+paste (into a reply to this posting) what you see in _your_ config.log.
Copy+paste any other lines related to detection of a compiler.
What clues do those messages give you?

-- 

[Valgrind-users] (no subject)

[Kissami I. <kis...@gm...>]

Hello,

I was using valgrind on my Mac, but when I installed the last version of
mac/os valgrind doesn't work.
When i run ./configure I have this error message : please use gcc => 3.0
....
My gcc version is 4.2.1
clang version is 5.0
icc version is 15.0.2

Best regards,


-- 
*Imad Kissami*
Université Paris 13, Sorbonne Paris Cité
IUT, département informatique
99, avenue Jean-Baptiste Clément
F-93430 Villetaneuse, France
kis...@gm...

Re: [Valgrind-users] Illegal Instruction

[Dalon W. <dw...@gm...>]

Thanks for the info. I was able to upgrade to 3.12, which resolved the
issue.

Dalon

On Tue, Oct 31, 2017 at 5:52 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> Before doing any such bug reproducer, it would be better to
> first upgrade to the last release 3.13. Quite a lot of bugs
> were solved since 3.10.0 (which dates from 2014).
>
> Philippe
>
>
> For sure, quite a lot of bugs and missing instructions
> On Tue, 2017-10-31 at 17:43 +0000, Jeff Hammond wrote:
> > VCMPPD is AVX, which should be supported in 3.10. Looks like a bug.
> > Perhaps you can provide a reproducer (yes, this is trivial but it’s
> > good if you provide it to ensure it captures your usage exactly).
> >
> > Jeff
> >
> > On Tue, Oct 31, 2017 at 10:08 AM Dalon Work <dw...@gm...> wrote:
> > > All,
> > >
> > > I'm getting an illegal instruction error from valgrind what running
> > > the following avx function: _mm256_cmp_pd.
> > > I am using version 3.10.0.
> > >
> > > From my own reading online, it looks like there isn't anyway around
> > > this problem, other than upgrading my version.
> > >
> > > My question is this: Does anybody know what version I should be
> > > using?
> > >
> > > Thank you!
> > >
> > > Dalon
> > > -----------------------------------------------------------------
> > > -------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot________
> > > _______________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > >
> >
> > --
> > Jeff Hammond
> > jef...@gm...
> > http://jeffhammond.github.io/
> > -------------------------------------------------------------------
> > -----------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Illegal Instruction

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

Before doing any such bug reproducer, it would be better to
first upgrade to the last release 3.13. Quite a lot of bugs
were solved since 3.10.0 (which dates from 2014).

Philippe


For sure, quite a lot of bugs and missing instructions 
On Tue, 2017-10-31 at 17:43 +0000, Jeff Hammond wrote:
> VCMPPD is AVX, which should be supported in 3.10. Looks like a bug.
> Perhaps you can provide a reproducer (yes, this is trivial but it’s
> good if you provide it to ensure it captures your usage exactly).
> 
> Jeff
> 
> On Tue, Oct 31, 2017 at 10:08 AM Dalon Work <dw...@gm...> wrote:
> > All,
> > 
> > I'm getting an illegal instruction error from valgrind what running
> > the following avx function: _mm256_cmp_pd.
> > I am using version 3.10.0.
> > 
> > From my own reading online, it looks like there isn't anyway around
> > this problem, other than upgrading my version. 
> > 
> > My question is this: Does anybody know what version I should be
> > using? 
> > 
> > Thank you!
> > 
> > Dalon
> > -----------------------------------------------------------------
> > -------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot________
> > _______________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > 
> 
> -- 
> Jeff Hammond
> jef...@gm...
> http://jeffhammond.github.io/
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Illegal Instruction

[Jeff H. <jef...@gm...>]

VCMPPD is AVX, which should be supported in 3.10. Looks like a bug. Perhaps
you can provide a reproducer (yes, this is trivial but it’s good if you
provide it to ensure it captures your usage exactly).

Jeff

On Tue, Oct 31, 2017 at 10:08 AM Dalon Work <dw...@gm...> wrote:

> All,
>
> I'm getting an illegal instruction error from valgrind what running the
> following avx function: _mm256_cmp_pd.
> I am using version 3.10.0.
>
> From my own reading online, it looks like there isn't anyway around this
> problem, other than upgrading my version.
>
> My question is this: Does anybody know what version I should be using?
>
> Thank you!
>
> Dalon
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
-- 
Jeff Hammond
jef...@gm...
http://jeffhammond.github.io/

[Valgrind-users] Illegal Instruction

[Dalon W. <dw...@gm...>]

All,

I'm getting an illegal instruction error from valgrind what running the
following avx function: _mm256_cmp_pd.
I am using version 3.10.0.

>From my own reading online, it looks like there isn't anyway around this
problem, other than upgrading my version.

My question is this: Does anybody know what version I should be using?

Thank you!

Dalon

Re: [Valgrind-users] valgrind and strspn behaviour change

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

> I dont understand the change in behaviour due to valgrind. Is this a 
> known issue or a bug?
This is a bug in the strspn replacement, used a.o. by memcheck,
helgrind, ...

I fixed it in commit c1eace647ca4f670ef9bec0d0fe72cdd25a96394
Now, your small test case works similarly with or without valgrind.
You might get and compile the last git version, and double check it
all works ok for you now.

(I still have to add a test case for this, to be done in a follow-up)

Thanks for the analysis/bug reproduction/small test case : this all
helps a lot.

Philippe

[Valgrind-users] valgrind and strspn behaviour change

[Emmanuel R. <emm...@er...>]

Hi all,

I'm having an issue running a application under valgrind.
The application runs fine without it, but some code has a different 
behaviour with valgrind.

I've managed to track and isolate the issue to the following piece (full 
example is attached as test.c) :
     //work4 = 0x e2 e3 d9
     //                     S  T  R
     if((offset = strspn((char*)work4, alphanumericOrNational)) != 
(unsigned) tulen - 1){
         printf("name+%d character 0x%.2X is not alphanumeric or 
national\n", offset + 1, work4[offset]);
     }
     else
     {
         printf("Ok.\n");
     }

(it's ebcdic characters).

I upgrade to the latest but i had the same issue in an older version :

[user@vm01 valgrind]$ valgrind --version
valgrind-3.13.0

If i'm using GCC :

[user@vm01 valgrind]$ gcc test.c -o test
[user@vm01 valgrind]$ ./test
0xe2e3d9
Ok.
Offset = 3
[user@vm01 valgrind]$ valgrind ./test
==23848== Memcheck, a memory error detector
==23848== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et 
al.
==23848== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright 
info
==23848== Command: ./test
==23848==
0xe2e3d9
name+1 character 0xE2 is not alphanumeric or national
Offset = 0
==23848==
==23848== HEAP SUMMARY:
==23848==     in use at exit: 0 bytes in 0 blocks
==23848==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==23848==
==23848== All heap blocks were freed -- no leaks are possible
==23848==
==23848== For counts of detected and suppressed errors, rerun with: -v
==23848== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[user@vm01 valgrind]$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap 
--enable-shared --enable-threads=posix --enable-checking=release 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --enable-linker-build-id 
--with-linker-hash-style=gnu 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto 
--enable-plugin --enable-initfini-array --disable-libgcj 
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install 
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install 
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)

Same thing with clang :

[user@vm01 valgrind]$ clang test.c -o test
[user@vm01 valgrind]$ ./test
0xe2e3d9
Ok.
Offset = 3
[user@vm01 valgrind]$ valgrind ./test
==27955== Memcheck, a memory error detector
==27955== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et 
al.
==27955== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright 
info
==27955== Command: ./test
==27955==
0xe2e3d9
name+1 character 0xE2 is not alphanumeric or national
Offset = 0
==27955==
==27955== HEAP SUMMARY:
==27955==     in use at exit: 0 bytes in 0 blocks
==27955==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==27955==
==27955== All heap blocks were freed -- no leaks are possible
==27955==
==27955== For counts of detected and suppressed errors, rerun with: -v
==27955== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[user@vm01 valgrind]$ clang --version
clang version 3.8.0 (http://llvm.org/git/clang.git 
81e96a3d20c4d1c3bdc6fdbc2a800d11f7347c7e) (http://llvm.org/git/llvm.git 
f5ab7a4dbb3061b17b6cc010e6b5fa802e913a52)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

I dont understand the change in behaviour due to valgrind. Is this a 
known issue or a bug?

Thanks!

Emmanuel Reynard

Re: [Valgrind-users] Getting a spurious invalid-write error with a program that uses swapcontext

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

On Thu, 2017-10-19 at 12:06 -0400, Zack Weinberg wrote:
> I can work around this by forcibly adjusting valgrind's state for the
> "data" object (compile with -DDO_MAKE_MEM_WRITABLE to see) but I
> would
> like to understand *why* this memory has become unwritable, why the
> STACK_REGISTER/DEREGISTER was insufficient, and whether there's a
> more
> appropriate work-around.

STACK_REGISTER (STACK_DEREGISTER) is just marking a piece
of memory as being a stack (not being a stack anymore).
This is a.o. used to help unwind logic, provide better description
of an address in error messages, etc ...

These do not change the Addressable or Validity-bits of the
 piece of memory.
So, after a piece of memory has been used as a stack,
depending on how much of this stack was used, the 'normal'
valgrind memcheck code has marked some memory unaccessible
Typically, when a function returns, the space that was used
by the frame of the returning function is marked as unaccessible.

When you deregister the stack, these V-bits/A-bits are not 
changed, and so part of this memory is now marked as not addressable.

IMO, before switching to a new stack, it would be better to
mark the stack as not addressable (maybe a small part of the
stack must be kept addressable, to just allow switching to this
stack).
Marking the stack as unaddressable would help memcheck to detect e.g.
a dereference to a 'not valid' part of the stack.

And when a stack is not used anymore, it might be needed
(like in your case) to mark the memory as addressable again.

So, I think that what you see is all normal :
STACK_REGISTER (STACK_DEREGISTER) are low level features,
they do not do the whole valgrind magic that might be needed
e.g. for your memset after usage.
And I think that your usage of VALGRIND_MAKE_MEM_UNDEFINED
is the correct thing to do.

Philippe

[Valgrind-users] Getting a spurious invalid-write error with a program that uses swapcontext

[Zack W. <za...@pa...>]

The test program at the end of this message is cut down from a real
program that uses swapcontext and friends (from ucontext.h) to run a
computation on sensitive data and then erase the stack used by that
computation.  The memset at the end of call_worker provokes an
invalid-write error from memcheck:

==12261== Memcheck, a memory error detector
==12261== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==12261== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==12261== Command: ./vg_test_2
==12261==
sizeof(data)        = 17328
offsetof(inner_ctx) = 16384
34 34
==12261== Invalid write of size 8
==12261==    at 0x4C32547: memset (vg_replace_strmem.c:1234)
==12261==    by 0x1089E6: call_worker.constprop.0 (vg_test_2.c:42)
==12261==    by 0x10874E: main (vg_test_2.c:62)
==12261==  Address 0x30cfe0 is 16224 bytes inside data symbol "ss.3473"
==12261==
00 00
==12261==
==12261== HEAP SUMMARY:
==12261==     in use at exit: 0 bytes in 0 blocks
==12261==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==12261==
==12261== All heap blocks were freed -- no leaks are possible
==12261==
==12261== For counts of detected and suppressed errors, rerun with: -v
==12261== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

"16224 bytes inside data symbol ss.3473" is 160 bytes from the high
end of the inner stack -- it's plausible that about this much space
would be used on the inner stack, on this architecture, by using
makecontext and swapcontext to call a no-op function.  If you compile
the test program with -DDONT_CALL_SWAPCONTEXT, the error goes away, so
this is definitely provoked by whatever swapcontext does internally.
Note that the program already has VALGRIND_STACK_REGISTER/DEREGISTER
annotations.

I can work around this by forcibly adjusting valgrind's state for the
"data" object (compile with -DDO_MAKE_MEM_WRITABLE to see) but I would
like to understand *why* this memory has become unwritable, why the
STACK_REGISTER/DEREGISTER was insufficient, and whether there's a more
appropriate work-around.

Thanks,
zw

#include <stdalign.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ucontext.h>
#include <valgrind/memcheck.h>

struct data
{
  char alignas(max_align_t) inner_stack[16384];
  ucontext_t inner_ctx;
};

static void
worker(void)
{
}

static void
call_worker(struct data *ip)
{
  ucontext_t outer_ctx;
  unsigned vg_stackid;
  if (getcontext(&ip->inner_ctx))
    abort();

  vg_stackid = VALGRIND_STACK_REGISTER
    (ip->inner_stack, ip->inner_stack + sizeof ip->inner_stack);

  ip->inner_ctx.uc_stack.ss_sp   = ip->inner_stack;
  ip->inner_ctx.uc_stack.ss_size = sizeof ip->inner_stack;
  ip->inner_ctx.uc_link          = &outer_ctx;
  makecontext(&ip->inner_ctx, worker, 0);

#ifndef DONT_CALL_SWAPCONTEXT
  swapcontext(&outer_ctx, &ip->inner_ctx);
#endif

  VALGRIND_STACK_DEREGISTER(vg_stackid);

#ifdef DO_MAKE_MEM_WRITABLE
  VALGRIND_MAKE_MEM_UNDEFINED(ip, sizeof *ip);
#endif

  memset(ip, 0, sizeof *ip);
}

#define ZX(x) ((unsigned int)(unsigned char)(x))

int
main(void)
{
  printf("sizeof(data)        = %zu\n"
         "offsetof(inner_ctx) = %zu\n",
         sizeof(struct data),
         offsetof(struct data, inner_ctx));

  static struct data ss;
  memset(&ss, 0x34, sizeof ss);

  printf("%02x %02x\n",
         ZX(((char *)&ss)[0]),
         ZX(((char *)&ss)[sizeof ss - 1]));

  call_worker(&ss);

  printf("%02x %02x\n",
         ZX(((char *)&ss)[0]),
         ZX(((char *)&ss)[sizeof ss - 1]));

  return 0;
}

[Valgrind-users] [FOSDEM] Call for Participation: Debugging Tools DevRoom at FOSDEM 2018

[Mark W. <ma...@kl...>]

On Fri, 2017-10-13 at 12:37 +0200, Ivo Raisr wrote:
> Debugging Tools developer room at FOSDEM 2018
> (Brussels, Belgium, February 3th).
> [...]
> ** How to Submit
> 
> There are two ways.
> The first one is to use the FOSDEM 'pentabarf' tool to submit your
> proposal:
> https://penta.fosdem.org/submission/FOSDEM18
> 
> [...]
> The second way is to email your talk proposal to
> val...@fo... alias.
> 
> Julian, Philippe, Mark, Ivosh, and Pedro will review the proposals
> and organize the schedule for the day.  Please feel free to suggest
> or discuss any ideas for the devroom on
> val...@fo... alias.

Apologies, that was the old name.
Please use deb...@fo...

> Important dates:
> 
>   Talk/Discussion Submission deadline:  Friday        1 Dec 2017
>   Devroom Schedule announcement:        Friday       15 Dec 2017
>   Devroom day:                          Saturday      3 Feb 2018

[Valgrind-users] [FOSDEM] Call for Participation: Debugging Tools DevRoom at FOSDEM 2018

[Ivo R. <iv...@iv...>]

Debugging Tools developer room at FOSDEM 2018
(Brussels, Belgium, February 3th).

FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate.  It is renown for being
highly developer-oriented and brings together 5000+ hackers from all
over the world.  It is held in the city of Brussels (Belgium).
http://fosdem.org/

FOSDEM 2018 will take place during the weekend of Saturday, February 3th
and Sunday February 4th 2018.  On Saturday we will have a devroom for
Debugging Tools, jointly organized by the Valgrind and GDB projects.
Devrooms are a place for development teams to meet, discuss, hack and publicly
present the project's latest improvements and future directions.

We will have a whole day to hang out together as community
embracing debugging tools, such as Valgrind, gdb, RR, Infinity, radare...
Please join us, regardless of whether you are a core hacker,
a plugin hacker, a user, a packager or a hacker on a
project that integrates, extends or complements debugging tools.

** Call for Participation

We would like to organize a series of talks/discussions on various
topics relevant to both core hackers, new developers, users, packagers
and cross project functionality.  Please do submit a talk proposal by
Friday December 1st 2017, so we can make a list of activities during the
day.

Some possible topics for talks/discussions are:

- The recently added functional changes (for users).
- Get feedback on what what kinds of new functionality would be
useful. Which tools and functionality users would like to see.
- Discuss release/bugfixing strategy/policy (core hackers, packagers).
- Connecting debugging tools together.
- Latest DWARF extensions, going from binary back to source.
- Multi, multi, multi... threads, processes and targets.
- Debugging anything, everywhere. Dealing with complex systems.
- Dealing with the dynamic loader and the kernel.
- Intercepting and interposing functions and events.
- Adding GDB features, such as designing GDB python scripts for your
data structures.
- Advances in gdbserver and the GDB remote serial protocol.
- Adding Valgrind features (adding syscalls for a platform or VEX
instructions for an architecture port).
- Infrastructure changes to the Valgrind JIT framework.
- Your interesting use case with a debugging tool.

** How to Submit

There are two ways.
The first one is to use the FOSDEM 'pentabarf' tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM18

- If necessary, create a Pentabarf account and activate it.
  Please reuse your account from previous years if you have
  already created it.

- In the "Person" section, provide First name, Last name
  (in the "General" tab), Email (in the "Contact" tab)
  and Bio ("Abstract" field in the "Description" tab).

- Submit a proposal by clicking on "Create event".

- Important! Select the "Debugging Tools devroom" track
  (on the "General" tab).

- Provide the title of your talk ("Event title" in the "General" tab).

- Provide a description of the subject of the talk and the
  intended audience (in the "Abstract" field of the "Description" tab)

- Provide a rough outline of the talk or goals of the session (a short
  list of bullet points covering topics that will be discussed) in the
  "Full description" field in the "Description" tab

The second way is to email your talk proposal to
val...@fo... alias.

Julian, Philippe, Mark, Ivosh, and Pedro will review the proposals and
organize the
schedule for the day.  Please feel free to suggest or discuss any ideas
for the devroom on val...@fo... alias.

** Recording of Talks

As usually the FOSDEM organisers plan to have live streaming and
recording fully working, both for remote/later viewing of talks, and
so that people can watch streams in the hallways when rooms are full.
This obviously requires speakers to consent to being recorded and
streamed.  If you plan to be a speaker, please understand that by
doing so you implicitly give consent for your talk to be recorded and
streamed.  The recordings will be published under the same licence as
all FOSDEM content (CC-BY).

Important dates:

  Talk/Discussion Submission deadline:    Friday        1 Dec 2017
  Devroom Schedule announcement:        Friday      15 Dec 2017
  Devroom day:                                          Saturday   3 Feb 2018

Hope to see you all at FOSDEM 2018 in the joint Debugging Tools devroom.
Brussels (Belgium), Saturday February 3th 2018.

On behalf of the devroom committee,
Ivo Raisr

Re: [Valgrind-users] Error during configure sparc sun4v

[Ivo R. <iv...@iv...>]

>> Sparc is not, and never has been, a supported platform. The list of
>> supported platforms can be found here:
>>
>>    http://valgrind.org/info/platforms.html
>>
>> Note at the bottom that there are details of an out of tree attempt at a
>> port, but there is no support in the main valgrind release.
>
>
> Oh and that is sparc/linux anyway, not sparc/solaris.

Nope. sparc/solaris is listed on that page together with sparc/linux.
They are out-of-tree ports, though, that's true.

If you are really interested, please follow the instructions on that page.
Perhaps you would like to continue the porting effort?

I.

Re: [Valgrind-users] Error during configure sparc sun4v

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

On 11/10/17 16:04, Tom Hughes wrote:
> On 11/10/17 15:58, Daniel Nuño wrote:
> 
>> I'm trying to compile valgrind-3.13.0 or valgrind-3.2.1 on the 
>> following architecture:
>> $ uname -a
>> SunOS slc11gbh 5.11 11.3 sun4v sparc sun4v
>>
>> And I'm having the following error:
>>
>> checking build system type... sparc-sun-solaris2.11
>> checking host system type... sparc-sun-solaris2.11
>> checking for a supported CPU... no (sparc)
>> configure: error: Unsupported host architecture. Sorry
>>
>> Any help that you could provide?
> 
> Well I'm not sure you'll consider it help as such...
> 
> Sparc is not, and never has been, a supported platform. The list of 
> supported platforms can be found here:
> 
>    http://valgrind.org/info/platforms.html
> 
> Note at the bottom that there are details of an out of tree attempt at a 
> port, but there is no support in the main valgrind release.

Oh and that is sparc/linux anyway, not sparc/solaris.

Tom

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

Re: [Valgrind-users] Error during configure sparc sun4v

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

On 11/10/17 15:58, Daniel Nuño wrote:

> I'm trying to compile valgrind-3.13.0 or valgrind-3.2.1 on the following 
> architecture:
> $ uname -a
> SunOS slc11gbh 5.11 11.3 sun4v sparc sun4v
> 
> And I'm having the following error:
> 
> checking build system type... sparc-sun-solaris2.11
> checking host system type... sparc-sun-solaris2.11
> checking for a supported CPU... no (sparc)
> configure: error: Unsupported host architecture. Sorry
> 
> Any help that you could provide?

Well I'm not sure you'll consider it help as such...

Sparc is not, and never has been, a supported platform. The list of 
supported platforms can be found here:

   http://valgrind.org/info/platforms.html

Note at the bottom that there are details of an out of tree attempt at a 
port, but there is no support in the main valgrind release.

Tom

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

[Valgrind-users] Error during configure sparc sun4v

[Daniel N. <dan...@ho...>]

Hello All, good day!

I'm trying to compile valgrind-3.13.0 or valgrind-3.2.1 on the following architecture:
$ uname -a
SunOS slc11gbh 5.11 11.3 sun4v sparc sun4v

And I'm having the following error:

checking build system type... sparc-sun-solaris2.11
checking host system type... sparc-sun-solaris2.11
checking for a supported CPU... no (sparc)
configure: error: Unsupported host architecture. Sorry

Any help that you could provide?

Thank you,
Daniel

email: dan...@ho...<mailto:dan...@ho...>

Re: [Valgrind-users] valgrind vxworks

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

> Is that possible to check memory leak in vxworks os by valgrind tool?   As I understand it, valgrind can check user space application on linux or other os, it can’t check the linux os/kernel itself.

About 9 years ago there was an independent project to make memcheck work
for checking User Mode Linux.  The project succeeded in "booting" UML
and getting to a "login: " prompt on a terminal console.  But the work
was too hard; the project was abandoned.  Even User Mode Linux made
too many assumptions about its environment that were too different
from memcheck's usual user mode (non-privileged) environment.
Dan Kegel of Google provided funding; I did the work.

-- 

[Valgrind-users] valgrind vxworks

[Li, J. <Jin...@wi...>]

Hi,

Is that possible to check memory leak in vxworks os by valgrind tool?   As I understand it, valgrind can check user space application on linux or other os, it can't check the linux os/kernel itself.

Thanks,
Jinliang

Re: [Valgrind-users] Detecting memory leaks in Google Test EXPECT_EXIT

[Benjamin M. <bmo...@uw...>]

Uh oh, this is embarrassing, but apparently I failed to read the output
correctly.  I used the "--log-file=valgrind_mem_leak_%p" to separate the
parent and child process logs by PID, and IT WAS detecting the leak in the
subprocess. (This is an awesome feature btw!!!)I was just missed it before
because I didn't pay enough attention to the PIDs in the logs. Also, the
final leak summary doesn't aggregate the leaked subprocess memory with the
parent process' leaked memory so I thought it wasn't detecting it. Sorry
for spamming the list =/

TL;DR: It is actually doing what I expect, I just failed to read the
results properly.

Sorry again,

~Benjamin

On Mon, Oct 9, 2017 at 12:53 PM, John Reiser <jr...@bi...> wrote:

> On 10/09/2017 10:38 AM, Benjamin Morgan wrote:
>
> I am using Google Test's EXPECT_EXIT() to sandbox my code in a separate
>> process on my x86_64 Ubuntu machine and I'm trying to check if there are
>> any memory leaks in my code. To verify that memory leaks can be detected I
>> created a dummy test below:
>>
>>     void leaky_function(void)
>>     {
>>          int* sub_proc_leak  = (int*) malloc(1000);
>>     }
>>
>>     TEST(my_test_case, memory_leak)
>>     {
>>          EXPECT_EXIT({
>>              leaky_function();
>>              exit(0);
>>          }, ::testing::ExitedWithCode(0),"");
>>     }
>>
>>
> There is only one call to leaky_function() in the above code.
>
> I'm compiling it using cmake/make to link in google test with the binary
>> being called mem_leak_test.
>>
>> I'm then running it with:
>>
>>     $ valgrind -v --trace-children=yes --tool=memcheck --leak-check=full
>> --show-leak-kinds=all ./mem_leak_test
>>
>> I would expect that it would detect 2000 bytes lost, or somehow indicate
>> that 1000 bytes were lost in the subprocess launched by EXPECT_EXIT() and
>> another in the main process.
>>
>> However, the LEAK summary only indicates 1000 bytes lost total:
>>
>>     ==64382== LEAK SUMMARY:
>>
>>     ==64382==    definitely lost: 1,000 bytes in 1 blocks
>>
>
> and if I comment out the second call to leaky_function() it will indicate
>> 0 bytes lost.
>>
>
> Please show the exact code after commenting out the second call.  (The
> original post has no second call.)
>
> --
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Benjamin Morgan
University of Washington
Electrical Engineering
bmo...@uw...
425.652.9094

Re: [Valgrind-users] Detecting memory leaks in Google Test EXPECT_EXIT

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

On 10/09/2017 10:38 AM, Benjamin Morgan wrote:

> I am using Google Test's EXPECT_EXIT() to sandbox my code in a separate process on my x86_64 Ubuntu machine and I'm trying to check if there are any memory leaks in my code. To verify that memory leaks can be detected I created a dummy test below:
> 
>     void leaky_function(void)
>     {
>          int* sub_proc_leak  = (int*) malloc(1000);
>     }
> 
>     TEST(my_test_case, memory_leak)
>     {
>          EXPECT_EXIT({
>              leaky_function();
>              exit(0);
>          }, ::testing::ExitedWithCode(0),"");
>     }
> 

There is only one call to leaky_function() in the above code.

> I'm compiling it using cmake/make to link in google test with the binary being called mem_leak_test.
> 
> I'm then running it with:
> 
>     $ valgrind -v --trace-children=yes --tool=memcheck --leak-check=full --show-leak-kinds=all ./mem_leak_test
> 
> I would expect that it would detect 2000 bytes lost, or somehow indicate that 1000 bytes were lost in the subprocess launched by EXPECT_EXIT() and another in the main process.
> 
> However, the LEAK summary only indicates 1000 bytes lost total:
> 
>     ==64382== LEAK SUMMARY:
> 
>     ==64382==    definitely lost: 1,000 bytes in 1 blocks

> and if I comment out the second call to leaky_function() it will indicate 0 bytes lost.

Please show the exact code after commenting out the second call.  (The original post has no second call.)

-- 

[Valgrind-users] Detecting memory leaks in Google Test EXPECT_EXIT

[Benjamin M. <ben...@gm...>]

.Hi All,

I am using Google Test's EXPECT_EXIT() to sandbox my code in a separate
process on my x86_64 Ubuntu machine and I'm trying to check if there are
any memory leaks in my code. To verify that memory leaks can be detected I
created a dummy test below:

void leaky_function(void)
{
    int* sub_proc_leak  = (int*) malloc(1000);
}

TEST(my_test_case, memory_leak)
{
    EXPECT_EXIT({
        leaky_function();
        exit(0);
    }, ::testing::ExitedWithCode(0),"");
}

I'm compiling it using cmake/make to link in google test with the binary
being called mem_leak_test.

I'm then running it with:

$ valgrind -v --trace-children=yes --tool=memcheck --leak-check=full
--show-leak-kinds=all ./mem_leak_test

I would expect that it would detect 2000 bytes lost, or somehow indicate
that 1000 bytes were lost in the subprocess launched by EXPECT_EXIT() and
another in the main process.

However, the LEAK summary only indicates 1000 bytes lost total:

==64382== LEAK SUMMARY:

==64382==    definitely lost: 1,000 bytes in 1 blocks

==64382==    indirectly lost: 0 bytes in 0 blocks

==64382==      possibly lost: 0 bytes in 0 blocks

==64382==    still reachable: 72,704 bytes in 1 blocks

==64382==         suppressed: 0 bytes in 0 blocks

and if I comment out the second call to leaky_function() it will indicate 0
bytes lost.

Is there a way to run my test with valgrind such that it detects the memory
leak in the subprocess?

According to valgrind's documentation:


--trace-children=<yes|no> [default: no]
           When enabled, Valgrind will trace into sub-processes initiated
via the exec system call.
           This is necessary for multi-process programs.

           Note that Valgrind does trace into the child of a fork (it would
be difficult not to, since
           fork makes an identical copy of a process), so this option is
arguably badly named. However,
           most children of fork calls immediately call exec anyway.

With this in mind I looked into how Google Test implements their
EXPECT_EXIT() macro and found that it uses clone() by default, but it has a
flag that can be toggled so that it uses fork() & execve() instead. So I
toggled that to true as shown below:

GTEST_DEFINE_bool_(
    death_test_use_fork,
    internal::BoolFromGTestEnv("death_test_use_fork", true),
    "Instructs to use fork()/_exit() instead of clone() in death tests. "
    "Ignored and always uses fork() on POSIX systems where clone() is not "
    "implemented. Useful when running under valgrind or similar tools if "
    "those do not support clone(). Valgrind 3.3.1 will just fail if "
    "it sees an unsupported combination of clone() flags. "
    "It is not recommended to use this flag w/o valgrind though it will "
    "work in 99% of the cases. Once valgrind is fixed, this flag will "
    "most likely be removed.");

As far as I can tell, Valgrind's documentation says that it can detect
memory leaks in a fork()/exec() subprocess and I have confirmed that my
google test is in fact calling execve() under the covers of the
EXPECT_EXIT(). Is this the correct interpretation of Valgrind's
documentation? And if so, why is it that Valgrind does not report the
memory leak in the subprocess?

Thanks,

~Benjamin

Re: [Valgrind-users] Valgrind on mips64

[Vikram C. <vik...@gm...>]

Thanks Maran. I am trying to compile this branch for mips and it is giving
these errors:

This is my configure string:
./configure --host=mips64-poky-linux --prefix=...install_oct CFLAGS=-mips64
--build=x86_64-linux CC=...mips64-poky-linux-gcc
CXX=...mips64-poky-linux-g++

mv -f priv/.deps/libvex_mips64_linux_a-guest_s390_toIR.Tpo
priv/.deps/libvex_mips64_linux_a-guest_s390_toIR.Po
/home/vchhibbe/workspace/tools/1.6.2/sysroots/x86_64-pokysdk-linux/usr/bin/mips64-poky-linux/mips64-poky-linux-gcc
-DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../include -I../VEX/pub
-I../VEX/pub -DVGA_mips64=1 -DVGO_linux=1 -DVGP_mips64_linux=1
-DVGPV_mips64_linux_vanilla=1 -Ipriv  -O2 -g -std=gnu99 -Wall
-Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
-Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
-Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
-Wmissing-parameter-type -Wold-style-declaration -fno-stack-protector
-fno-strict-aliasing -fno-builtin  -Wbad-function-cast -fstrict-aliasing
-mips64 -MT priv/libvex_mips64_linux_a-guest_mips_helpers.o -MD -MP -MF
priv/.deps/libvex_mips64_linux_a-guest_mips_helpers.Tpo -c -o
priv/libvex_mips64_linux_a-guest_mips_helpers.o `test -f
'priv/guest_mips_helpers.c' || echo './'`priv/guest_mips_helpers.c
/tmp/ccr6aN6R.s: Assembler messages:
/tmp/ccr6aN6R.s:995: Error: invalid operands `dmtc2 $4,0x256'
/tmp/ccr6aN6R.s:1080: Error: invalid operands `dmtc2 $4,0x5C'
/tmp/ccr6aN6R.s:1149: Error: invalid operands `dmtc2 $4,0x1207'
/tmp/ccr6aN6R.s:1217: Error: invalid operands `dmtc2 $4,0x10C'
/tmp/ccr6aN6R.s:1266: Error: invalid operands `dmtc2 $4,0x2C8'
/tmp/ccr6aN6R.s:1316: Error: invalid operands `dmtc2 $4,0x245'
/tmp/ccr6aN6R.s:1372: Error: invalid operands `dmtc2 $4,0x404F'
/tmp/ccr6aN6R.s:1427: Error: invalid operands `dmtc2 $4,0x48'
/tmp/ccr6aN6R.s:1462: Error: invalid operands `dmtc2 $4,0x2D0'
/tmp/ccr6aN6R.s:1504: Error: invalid operands `dmtc2 $4,0x206'
/tmp/ccr6aN6R.s:1545: Error: invalid operands `dmtc2 $4,0x25C'
/tmp/ccr6aN6R.s:1586: Error: invalid operands `dmtc2 $4,0x3114'

Please let me know if I am missing anything.
Thanks

On Tue, Oct 3, 2017 at 1:53 PM, Vikram Chhibber <vik...@gm...>
wrote:

> Thanks a lot. This looks promising. I will try and get back to you.
>
> Vikram
>
> On Tue, Oct 3, 2017 at 4:01 AM, Maran Pakkirisamy <
> mpa...@ca...> wrote:
>
>> Probably your application is accessing xkphys address space on cavium
>> processor.
>>
>> Try this branch which has support for applications accessing xkphys
>> address space specifically on octeon processors.
>> https://github.com/valgrindocteon/valgrind/commits/devel/octeon3
>>
>> You would have to add following command line switch when invoking
>> valgrind (to instruct valgrind to ignore xkphys address space)
>>
>> --ignore-ranges=0x8000000000000000-0xbfffffffffffffff
>>
>>
>>
>> On Wednesday 20 September 2017 03:20 AM, Vikram Chhibber wrote:
>>
>> Hi All,
>>
>> I am trying to run valgrind on our mips 64 bit platform. I have compiled
>> valgrind 3.13 with following configure arguments:
>>
>> ./configure --host=mips64-poky-linux --prefix=...  --build=x86_64-linux
>> CC=... CXX=...
>>
>> My code access memory-address range starting from 0x8001180000000000.
>> This is ligitimate access.
>> We have added following valgrind macro in the code before this access as:
>> VALGRIND_MALLOCLIKE_BLOCK(CVMX_ADD_IO_SEG(0x8001180000000000ull),
>> 0x0000000000f00000ull, 0, 1);
>>
>> But when the code tries accessing the memory region, it simply terminates
>> with SIGBUS:
>>
>> ==1492== Process terminating with default action of signal 10 (SIGBUS)
>>
>>
>> If we remove the above valgrind macro, the program still terminates with
>> SIGBUS with additional error message.
>>
>> ==890==  Address 0x8001180000001500 is not stack'd, malloc'd or
>> (recently) free'
>>
>> ==890== Process terminating with default action of signal 10 (SIGBUS)
>>
>>
>> I have tried valgrind 3.12 with same issue. If I run any other
>> application under valgrind that does not access this memory region, it
>> works fine.
>>
>> Also, this application runs fine without valgrind.
>>
>> Please let me know what can we do to get around this issue.
>>
>> Thanks
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>>
>> --
>> Maran Pakkirisamy
>>
>>
>

Re: [Valgrind-users] Valgrind on mips64

[Vikram C. <vik...@gm...>]

Thanks a lot. This looks promising. I will try and get back to you.

Vikram

On Tue, Oct 3, 2017 at 4:01 AM, Maran Pakkirisamy <
mpa...@ca...> wrote:

> Probably your application is accessing xkphys address space on cavium
> processor.
>
> Try this branch which has support for applications accessing xkphys
> address space specifically on octeon processors.
> https://github.com/valgrindocteon/valgrind/commits/devel/octeon3
>
> You would have to add following command line switch when invoking valgrind
> (to instruct valgrind to ignore xkphys address space)
>
> --ignore-ranges=0x8000000000000000-0xbfffffffffffffff
>
>
>
> On Wednesday 20 September 2017 03:20 AM, Vikram Chhibber wrote:
>
> Hi All,
>
> I am trying to run valgrind on our mips 64 bit platform. I have compiled
> valgrind 3.13 with following configure arguments:
>
> ./configure --host=mips64-poky-linux --prefix=...  --build=x86_64-linux
> CC=... CXX=...
>
> My code access memory-address range starting from 0x8001180000000000. This
> is ligitimate access.
> We have added following valgrind macro in the code before this access as:
> VALGRIND_MALLOCLIKE_BLOCK(CVMX_ADD_IO_SEG(0x8001180000000000ull),
> 0x0000000000f00000ull, 0, 1);
>
> But when the code tries accessing the memory region, it simply terminates
> with SIGBUS:
>
> ==1492== Process terminating with default action of signal 10 (SIGBUS)
>
>
> If we remove the above valgrind macro, the program still terminates with
> SIGBUS with additional error message.
>
> ==890==  Address 0x8001180000001500 is not stack'd, malloc'd or
> (recently) free'
>
> ==890== Process terminating with default action of signal 10 (SIGBUS)
>
>
> I have tried valgrind 3.12 with same issue. If I run any other application
> under valgrind that does not access this memory region, it works fine.
>
> Also, this application runs fine without valgrind.
>
> Please let me know what can we do to get around this issue.
>
> Thanks
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Valgrind-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
> --
> Maran Pakkirisamy
>
>

Re: [Valgrind-users] ARMv5?

[Ivo R. <iv...@iv...>]

2017-09-23 9:01 GMT+02:00 Julian Seward <js...@ac...>:
>
> On 19/09/17 20:19, John Reiser wrote:
>>> Can someone who has worked on the code clarify if Valgrind is in fact
>>> expected to work on an ARMv5?
>
> ARMv5 and ARMv6 aren't supported.

In that case we need to update http://www.valgrind.org/info/platforms.html
to say for example:

- ARM/Linux: up to and including ARMv7.
- ARM64/Linux: Up to and including ARMv8.
+ ARM/Linux: supported since ARMv7.
+ ARM64/Linux:  support for ARMv8.0.

I.