valgrind-users — General discussion list for Valgrind users

[Valgrind-users] FOSDEM Valgrind dev-room - Brussels, 31 Jan 2015

[Mark W. <mj...@re...>]

Hi Valgrind Users and Developers!

It is December already and we would really like to collect some more
proposals for our FOSDEM collaboration room in Brussels on Sunday 31
January 2015.

The original Call For Participation (see below) said the Talk/Discussion
Submission deadline was today, but we will extend it a little to make
sure we have enough interesting talks/discussion topics.

If you are coming and want to talk about or discuss something, please
submit a proposal (they don't have to be perfect or complete yet). And
please feel free to contact one of the organizers or discuss your idea
on the developer list first before entering it into the penta system.

[Original CFP follows]

Valgrind developer room at FOSDEM 2015 (Brussels, Belgium, 31 January).

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 2015 will take place during the weekend of Saturday, 31 January
and Sunday 1 February 2015.  On Saturday we will have a devroom for
Valgrind.  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 Valgrind community.
Please join us, regardless of whether you are a Valgrind core hacker,
Valgrind tool hacker, Valgrind user, Valgrind packager or hacker on a
project that integrates, extends or complements Valgrind.

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
Monday 1 December 2014, so we can make a list of activities during the
day.

Some possible topics for talks/discussions are:

- Recently added functional changes (for valgrind users).

- State of the valgrind code base (core hackers).

- Speeding up Memcheck by inlining of the fast cases of its helper
  function calls (core hackers).

- Supporting Valgrind on MacOS X 10.9 (Mavericks) and 10.10 (Yosemite)
  (valgrind developers and users).

- The AArch64 ARMv8 port (valgrind developers and users).

- Valgrind and Wine (valgrind developers and users).

- Helgrind - basic design, problems and opportunities (core and tools).

- Get feedback on what what kinds of new functionality would
  be useful. Which tools users would like to see and/or which new
  features for the existing tools. (valgrind developers and users).

  - Modify memcheck to report the last leaked pointer to a block
    integrate "omega" as a memcheck option or omega as a separate tool.

  - Better support compiled and JITted code.
    allowing the JIT compiler to indicate the link between
    the JITted code and the source code.

  - Valgrind and transactional memory.

- How to add simple features (adding syscalls for a platform or VEX
  instructions for a architecture port). (new core developers).

- Making Valgrind really multi-threaded, parallelising Memcheck
  parallelising the rest of the framework, and tools (for core hackers).

- Should we continue to support MacOS? What about Valgrind on
  MS-Windows? Solaris? (attracting new hackers).

- Redo the JIT framework to reduce baseline overheads? (core hackers).

- Make Callgrind work sanely on ARM (core hackers).

- Discuss release/bugfixing strategy/policy (core hackers, packagers).

- Packaging valgrind for distros, handling patches, suppressions, etc.
  (packagers).

- Valgrind/GDB integration (cross project).

- Valgrind vs the compiler. Compilers like GCC and clang now have
  "valgrind like" features, eg -fsanitize=address|thread|undefined.
  How does valgrind complement or improve on these features?

- Eclipse and other visualisation tools for valgrind (cross project).

- Practical examples of using Valgrind in (big) system automatic
  regression testing (users).

Use the FOSDEM 'pentabarf' tool to submit your proposal.
https://penta.fosdem.org/submission/FOSDEM15/

- If necessary, create a Pentabarf account and activate 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 "Valgrind 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

Julian, Philippe and Mark will review the proposals and organize the
schedule for the day.  Please feel free to suggest or discuss any ideas
for the devroom on the Valgrind developer mailinglist before creating a
proposal: val...@li...

Recording of talks

This year 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:    Monday    1 Dec 2014
  Devroom Schedule announcement:          Monday   15 Dec 2014
  Devroom day:                            Saturday 31 Jan 2015

Hope to see you all at FOSDEM 2015 in the Valgrind devroom.
Brussels (Belgium), Saturday 31 January 2015.
https://fosdem.org/2015/schedule/track/valgrind/

Re: [Valgrind-users] Problem running even simple programs

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

On Thu, 2014-11-27 at 23:06 +0300, Mikhail Baikov wrote:

> ==1654== Invalid read of size 4
> ==1654==    at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so)
> ==1654==  Address 0xbdd74b44 is on thread 1's stack
> ==1654==  20 bytes below stack pointer
> ==1654==
> I also have
> # valgrind -v -v -v -d -d -d --trace-redir=yes /bin/true
> log but it's really big to attach it here.
> 
> And i really can't understand where is the problem because I tried to 
> build trunk valgring (which fails with the same errors), tried 3.10.0 
> with patches from buildroot with the same result.
> 
> And now I don't know where to dig.
A possible cause of the above problem is that valgrind does
not recognise the name of the uClibc dynamic loader.
There is some code that handles specially the dynamic loader.
See coregrind/m_redir.c line 1363 for the expected names on arm
or some similar names in include/pub_tool_redir.h

It might also just be "normal" errors, that are suppressed
by the standard valgrind suppression files, but that in your
case are not matching due to the uClibc use ?
See e.g. default.supp (generated from various *.supp files).
I see no uclibc specific files there, which makes me believe
valgrind is not (yet) fine tuned to be used with uclibc.

For what concerns the error message
   /bin/true: can't resolve symbol '__libc_freeres'
again that is probably caused by uClib, which I guess does not
provide __libc_freeres
To avoid this msg, you can use --run-libc-freeres=no

Note however that I see in coregrind/vg_preloaded.c (line 59)
that the call should not be done when valgrind is "compiled"
for UCLIBC.
So, might be good to verify how e.g. vg_preloaded.c was
compiled.

Philippe

[Valgrind-users] Problem running even simple programs

[Mikhail B. <mik...@de...>]

Hello
I built valgrind 3.10.1 for arm platform (on amd64 host system) and got 
a problem. Memcheck fails finding problems even in /bin/true

# valgrind /bin/true
==1654== Memcheck, a memory error detector
==1654== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1654== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==1654== Command: /bin/true
==1654==
==1654== Invalid read of size 4
==1654==    at 0x40071B0: _dl_get_ready_to_run (in 
/lib/ld-uClibc-0.9.32.1.so)
==1654==  Address 0xbdd749d4 is on thread 1's stack
==1654==  20 bytes below stack pointer
==1654==
==1654== Invalid read of size 4
==1654==    at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so)
==1654==  Address 0xbdd74b44 is on thread 1's stack
==1654==  20 bytes below stack pointer
==1654==
==1654== Invalid read of size 4
==1654==    at 0x489B02C: __uClibc_fini (in /lib/libuClibc-0.9.32.1.so)
==1654==  Address 0xbdd74aec is on thread 1's stack
==1654==  20 bytes below stack pointer
==1654==
==1654== Invalid read of size 4
==1654==    at 0x4002324: ??? (in /lib/ld-uClibc-0.9.32.1.so)
==1654==  Address 0xbdd74ab4 is on thread 1's stack
==1654==  20 bytes below stack pointer
==1654==
/bin/true: can't resolve symbol '__libc_freeres'
==1654==
==1654== HEAP SUMMARY:
==1654==     in use at exit: 0 bytes in 0 blocks
==1654==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1654==
==1654== All heap blocks were freed -- no leaks are possible
==1654==
==1654== For counts of detected and suppressed errors, rerun with: -v
==1654== ERROR SUMMARY: 48 errors from 4 contexts (suppressed: 0 from 0)

I also have
# valgrind -v -v -v -d -d -d --trace-redir=yes /bin/true
log but it's really big to attach it here.

And i really can't understand where is the problem because I tried to 
build trunk valgring (which fails with the same errors), tried 3.10.0 
with patches from buildroot with the same result.

And now I don't know where to dig.

[Valgrind-users] Valgrind-3.10.1 is available

[Julian S. <js...@ac...>]

We are pleased to announce a new release of Valgrind, version 3.10.1,
available from http://www.valgrind.org.  See the attached release
notes for details.

Happy (and productive) debugging and profiling,

-- The Valgrind Developers


Release 3.10.1 (25 November 2014)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.10.1 is a bug fix release.  It fixes various bugs reported in 3.10.0
and backports fixes for all reported missing AArch64 ARMv8 instructions
and syscalls from the trunk.  If you package or deliver 3.10.0 for others
to use, you might want to consider upgrading to 3.10.1 instead.

Note that this release does not contain backports of recent improvements
to support for MacOS 10.9 (Mavericks) or 10.10 (Yosemite).  If you are
looking for improved support on those targets, please try the trunk
instead, as described at http://valgrind.org/downloads/repository.html.

The following bugs have been fixed or resolved.  Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry.  We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.

To see details of a given bug, visit
  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.

335440  arm64: ld1 (single structure) is not implemented
335713  arm64: unhanded instruction: prfm (immediate)
339020  ppc64: memcheck/tests/ppc64/power_ISA2_05 failing in nightly build
339182  ppc64: AvSplat ought to load destination vector register with [..]
339336  PPC64 store quad instruction (stq) is not supposed to change [..]
339433  ppc64 lxvw4x instruction uses four 32-byte loads
339645  Use correct tag names in sys_getdents/64 wrappers
339706  Fix false positive for ioctl(TIOCSIG) on linux
339721  assertion 'check_sibling == sibling' failed in readdwarf3.c ...
339853  arm64 times syscall unknown
339855  arm64 unhandled getsid/setsid syscalls
339858  arm64 dmb sy not implemented
339926  Unhandled instruction 0x1E674001 (frintx) on aarm64
339927  Unhandled instruction 0x9E7100C6 (fcvtmu) on aarch64
339938  disInstr(arm64): unhandled instruction 0x4F8010A4 (fmla)
        == 339950
339940  arm64: unhandled syscall: 83 (sys_fdatasync) + patch
340033  arm64: unhandled insn dmb ishld and some other isb-dmb-dsb variants
340028  unhandled syscalls for arm64 (msync, pread64, setreuid and setregid)
340036  arm64: Unhandled instruction ld4 (multiple structures, no offset)
340236  arm64: unhandled syscalls: mknodat, fchdir, chroot, fchownat
340509  arm64: unhandled instruction fcvtas
340630  arm64: fchmod (52) and fchown (55) syscalls not recognized
340632  arm64: unhandled instruction fcvtas
340725  AVX2: Incorrect decoding of vpbroadcast{b,w} reg,reg forms
340788  warning: unhandled syscall: 318 (getrandom)
340807  disInstr(arm): unhandled instruction: 0xEE989B20
340856  disInstr(arm64): unhandled instruction 0x1E634C45 (fcsel)
340922  arm64: unhandled getgroups/setgroups syscalls
n-i-bz  DRD and Helgrind: Handle Imbe_CancelReservation (clrex on ARM)
n-i-bz  Add missing ]] to terminate CDATA.
n-i-bz  Glibc versions prior to 2.5 do not define PTRACE_GETSIGINFO
n-i-bz  Enable sys_fadvise64_64 on arm32.
n-i-bz  Add test cases for all remaining AArch64 SIMD, FP and memory insns.
n-i-bz  Add test cases for all known arm64 load/store instructions.
n-i-bz  PRE(sys_openat): when checking whether ARG1 == VKI_AT_FDCWD [..]
n-i-bz  Add detection of old ppc32 magic instructions from bug 278808.
n-i-bz  exp-dhat: Implement missing function "dh_malloc_usable_size".
n-i-bz  arm64: Implement "fcvtpu w, s".
n-i-bz  arm64: implement ADDP and various others
n-i-bz  arm64: Implement {S,U}CVTF (scalar, fixedpt).
n-i-bz  arm64: enable FCVT{A,N}S X,S.

(3.10.1: 25 November 2014, vex r3026, valgrind r14785)

Re: [Valgrind-users] Problem with helgrind?

[Julian S. <js...@ac...>]

On 11/25/2014 02:04 PM, Pohl, Hartmut wrote:
> As far as I understand, Thread #5 belongs to the second test case and
> thus cannot have a data race with thread #3 due to the pthread_join()s.

I agree.

> I put the annotation at the end of the while (that's what I started with).

I looked at this in some detail, but I don't understand what is happening.

I did notice that if you comment out the line causing the real race

  i = 40;

then no races are reported.  So at least you have a situation where, if
there is a race, then (multiple) races are reported, but if you have no
race, then no races are reported.

To investigate further I'd need to look at Helgrind's memory state machine
transitions for |i|.

J

Re: [Valgrind-users] Problem with helgrind?

[Pohl, H. <har...@ad...>]

Hi,

The stack I think is wrong is the following combination:
==7704== Possible data race during read of size 4 at 0xFFEFFFE40 by thread #5 ==7704== Locks held: 1, at address 0x6012E0
==7704==    at 0x4009F8: workWithMutex(void*) (helgrind_problem.cpp:82)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)
==7704==
==7704== This conflicts with a previous write of size 4 by thread #3 ==7704== Locks held: 1, at address 0x6012E0
==7704==    at 0x4009F8: workWithMutex(void*) (helgrind_problem.cpp:82)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)

As far as I understand, Thread #5 belongs to the second test case and thus cannot have a data race with thread #3 due to the pthread_join()s.

I put the annotation at the end of the while (that's what I started with). Same output.

Best regards,
	Hartmut

-----Original Message-----
From: Julian Seward [mailto:js...@ac...] 
Sent: Dienstag, 25. November 2014 13:40
To: val...@li...; Pohl, Hartmut
Subject: Re: [Valgrind-users] Problem with helgrind?

On 11/25/2014 10:22 AM, Pohl, Hartmut wrote:

> What confuses me is that the stack trace incorrectly reports a data 
> race between the first and the second test thread. Which is impossible 
> and makes me think that maybe the pthread_join() is incorrectly handled by helgrind?

There are a bunch of stack traces in this message.  Exactly which one is the one you think is wrong?

I don't exactly understand the test program, but this ..

>   bool wait = true;
>   do
>   {
>     wait = atomicWait.syncLoad();
>     ANNOTATE_HAPPENS_AFTER(atomicWait.getAddress());    
>   }
>   while (wait) ;

.. doesn't feel right to me.  You need to put the ANNOTATE_HAPPENS_AFTER after the end of the while loop, not inside it, because merely reading the value

>     wait = atomicWait.syncLoad();

doesn't mean the thread can go forwards.  It has to spin until that value becomes |true|.  So the h-b edge from the main thread "arrives here" after the loop, not inside it.

J

Re: [Valgrind-users] Problem with helgrind?

[Julian S. <js...@ac...>]

On 11/25/2014 10:22 AM, Pohl, Hartmut wrote:

> What confuses me is that the stack trace incorrectly reports a data race
> between the first and the second test thread. Which is impossible and makes me
> think that maybe the pthread_join() is incorrectly handled by helgrind?

There are a bunch of stack traces in this message.  Exactly which one is
the one you think is wrong?

I don't exactly understand the test program, but this ..

>   bool wait = true;
>   do
>   {
>     wait = atomicWait.syncLoad();
>     ANNOTATE_HAPPENS_AFTER(atomicWait.getAddress());    
>   }
>   while (wait) ;

.. doesn't feel right to me.  You need to put the ANNOTATE_HAPPENS_AFTER
after the end of the while loop, not inside it, because merely reading
the value

>     wait = atomicWait.syncLoad();

doesn't mean the thread can go forwards.  It has to spin until that
value becomes |true|.  So the h-b edge from the main thread "arrives
here" after the loop, not inside it.

J

[Valgrind-users] Problem with helgrind?

[Pohl, H. <har...@ad...>]

Hi,

I'm currently playing around with helgrind. 
First, I'm trying to understand the annotations, cause I want to use them for my atomics implementation.
Second, I'd like to understand how well helgrind works on transitive happens before/after relationships across threads.

While doing this I observed strange reports from helgrind. It reports a false positive with a strange stack trace.
I have 2 test cases doing similar shared data accesses, the first is synchronized by an atomic flag, the second is unsynchronized using sleep. Yes, I know, this can change the execution order, but in all my runs with and without helgrind, the execution order was correct. I use sleep to provoke data races.

While helgrind correctly reports the data race for the second test case, it fails to recognize the atomic synchronization for the first, although I've annotated the synchronization.
Interesting: If I remove the second test case, the report is correct. No race is found.
I get this report with helgrind 3.10 and 3.9 with RHEL5.

Maybe I don't use the annotations correctly?
Or is this just a false positive I have to live with?
What confuses me is that the stack trace incorrectly reports a data race between the first and the second test thread. Which is impossible and makes me think that maybe the pthread_join() is incorrectly handled by helgrind?

Thanks and best regards,
                Hartmut Pohl

The Code:
// g++ -g -O3 -pthread pt_thread_test.cpp
#include <stdio.h>
#include <pthread.h>
#include <assert.h>
#include <unistd.h>
#include <valgrind/helgrind.h>


template <class TYPE>
class AtomicAccess
{
  public:
    AtomicAccess(TYPE value)
    : mMemoryModel(__ATOMIC_SEQ_CST),
      mValue(value)
    {
      VALGRIND_HG_DISABLE_CHECKING(&mValue, sizeof(mValue));    
    }
    
    ~AtomicAccess()
    {
      VALGRIND_HG_ENABLE_CHECKING(&mValue, sizeof(mValue)); 
    }
    
    __attribute__ ((noinline)) TYPE syncLoad()
    {
      TYPE ret = __atomic_load_n(&mValue, mMemoryModel);
      return ret;
    }

    __attribute__ ((noinline)) void syncStore(const TYPE& value)
    {
      __atomic_store_n(&mValue, value, mMemoryModel);
    }

    TYPE * getAddress()
    {
      return &mValue;
    }

  private:
    // Memory model (Initializes to default memory model)
    const int mMemoryModel;
    // Variable to store the value
    TYPE mValue;
};


pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
AtomicAccess<bool> atomicWait(true);


void *timedWaitToGiveMutex(void *arg)
{
  printf("%s\n",__FUNCTION__);
  pthread_mutex_lock(&mutex);
  sleep(3);
  pthread_mutex_unlock(&mutex);
}


void *syncWaitToGiveMutex(void *arg)
{
  printf("%s\n",__FUNCTION__);
  pthread_mutex_lock(&mutex);
  bool wait = true;
  do
  {
    wait = atomicWait.syncLoad();
    ANNOTATE_HAPPENS_AFTER(atomicWait.getAddress());    
  }
  while (wait) ;
  pthread_mutex_unlock(&mutex);
}

void *workWithMutex(void *arg)
{
  printf("%s\n",__FUNCTION__);
  pthread_mutex_lock(&mutex);
  int *iptr = (int*) arg;
  (*iptr)++;
  pthread_mutex_unlock(&mutex);
  return iptr;
}

int main()
{
  int i = 10;
  pthread_t tid, tid2;
  int *ret;

// 1st test case: Start T1, take mutex, waits on atomic. Start T2, block on 
//                mutex. 
//                Main writes atomic - releases wait.
//                T1 unblocks, gives mutex, T2 takes it, reads and writes, unlocks
  pthread_create(&tid, 0, syncWaitToGiveMutex, 0);
  sleep(1);
  pthread_create(&tid2, 0, workWithMutex, &i);
  sleep(1);

  i = 30;
  ANNOTATE_HAPPENS_BEFORE(atomicWait.getAddress());
  atomicWait.syncStore(0);
  
  pthread_join(tid2, (void **)&ret);
  assert(i == *ret);
  pthread_join(tid, (void **)&ret); 


// 2nd test case: Same as 3 but with a timer instead of an atomic operation
  pthread_create(&tid, 0, timedWaitToGiveMutex, 0);
  sleep(1);
  pthread_create(&tid2, 0, workWithMutex, &i);
  sleep(1);
  i = 40;
  
  pthread_join(tid2, (void **)&ret);
  assert(i == *ret);
  pthread_join(tid, (void **)&ret);
}

The report:
==7704== Helgrind, a thread error detector
==7704== Copyright (C) 2007-2013, and GNU GPL'd, by OpenWorks LLP et al.
==7704== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==7704== Command: a.out
==7704== Parent PID: 22355
==7704== 
==7704== ---Thread-Announcement------------------------------------------
==7704== 
==7704== Thread #3 was created
==7704==    at 0x38458D496E: clone (in /lib64/libc-2.5.so)
==7704==    by 0x3846406DCB: create_thread (createthread.c:76)
==7704==    by 0x3846406DCB: pthread_create@@GLIBC_2.2.5 (pthread_create.c:544)
==7704==    by 0x4A10890: pthread_create_WRK (hg_intercepts.cpp:457)
==7704==    by 0x4006CB: main (helgrind_problem.cpp:101)
==7704== 
==7704== ----------------------------------------------------------------
==7704== 
==7704== Possible data race during read of size 8 at 0x4C225D0 by thread #3
==7704== Locks held: none
==7704==    at 0x4A1402F: pthread_mutex_lock (hg_intercepts.cpp:795)
==7704==    by 0x4009F7: workWithMutex(void*) (helgrind_problem.cpp:80)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)
==7704==  Address 0x4c225d0 is 0 bytes inside data symbol "_ZL21fn_pthread_mutex_lock"
==7704== 
==7704== ---Thread-Announcement------------------------------------------
==7704== 
==7704== Thread #5 was created
==7704==    at 0x38458D496E: clone (in /lib64/libc-2.5.so)
==7704==    by 0x3846406DCB: create_thread (createthread.c:76)
==7704==    by 0x3846406DCB: pthread_create@@GLIBC_2.2.5 (pthread_create.c:544)
==7704==    by 0x4A10890: pthread_create_WRK (hg_intercepts.cpp:457)
==7704==    by 0x40079A: main (helgrind_problem.cpp:116)
==7704== 
==7704== ----------------------------------------------------------------
==7704== 
==7704==  Lock at 0x6012E0 was first observed
==7704==    at 0x4A0E385: pthread_mutex_lock_WRK (hg_intercepts.cpp:778)
==7704==    by 0x4A1404C: pthread_mutex_lock (hg_intercepts.cpp:803)
==7704==    by 0x400A40: syncWaitToGiveMutex(void*) (helgrind_problem.cpp:65)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)
==7704==  Address 0x6012e0 is 0 bytes inside data symbol "mutex"
==7704== 
==7704== Possible data race during read of size 4 at 0xFFEFFFE40 by thread #5
==7704== Locks held: 1, at address 0x6012E0
==7704==    at 0x4009F8: workWithMutex(void*) (helgrind_problem.cpp:82)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)
==7704== 
==7704== This conflicts with a previous write of size 4 by thread #3
==7704== Locks held: 1, at address 0x6012E0
==7704==    at 0x4009F8: workWithMutex(void*) (helgrind_problem.cpp:82)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)
==7704==  Address 0xffefffe40 is on thread #1's stack
==7704==  in frame #2, created by main (helgrind_problem.cpp:90)
==7704== 
==7704== ---Thread-Announcement------------------------------------------
==7704== 
==7704== Thread #1 is the program's root thread
==7704== 
==7704== ----------------------------------------------------------------
==7704== 
==7704==  Lock at 0x6012E0 was first observed
==7704==    at 0x4A0E385: pthread_mutex_lock_WRK (hg_intercepts.cpp:778)
==7704==    by 0x4A1404C: pthread_mutex_lock (hg_intercepts.cpp:803)
==7704==    by 0x400A40: syncWaitToGiveMutex(void*) (helgrind_problem.cpp:65)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)
==7704==  Address 0x6012e0 is 0 bytes inside data symbol "mutex"
==7704== 
==7704== Possible data race during write of size 4 at 0xFFEFFFE40 by thread #5
==7704== Locks held: 1, at address 0x6012E0
==7704==    at 0x4009F8: workWithMutex(void*) (helgrind_problem.cpp:82)
==7704==    by 0x4A10A26: mythread_wrapper (hg_intercepts.cpp:421)
==7704==    by 0x384640677C: start_thread (pthread_create.c:301)
==7704==    by 0x38458D49AC: clone (in /lib64/libc-2.5.so)
==7704== 
==7704== This conflicts with a previous read of size 4 by thread #1
==7704== Locks held: none
==7704==    at 0x400750: main (helgrind_problem.cpp:109)
==7704==  Address 0xffefffe40 is on thread #1's stack
==7704==  in frame #2, created by main (helgrind_problem.cpp:90)
==7704== 
==7704== 
==7704== For counts of detected and suppressed errors, rerun with: -v
==7704== Use --history-level=approx or =none to gain increased speed, at
==7704== the cost of reduced accuracy of conflicting-access information
==7704== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 96 from 43)

Re: [Valgrind-users] massif instrumentation in C/C++ code

[Milian W. <ma...@mi...>]

On Thursday 20 November 2014 21:54:45 Peter Toft wrote:
> This is a *very* impressive tool.
> 
> It has already helped me A LOT today. Thanx!!
> 
> But adding my idea would make it super^2 (needs cowork between the
> valgrind core and your tool)

It's actually "my" tool and as I said in my other email, I totally agree that 
having markers in massif output would be an excellent addition! VTune also 
supports something like that for its runtime performance analysis.

Bye
-- 
Milian Wolff
ma...@mi...
http://milianw.de

Re: [Valgrind-users] massif instrumentation in C/C++ code

[Peter T. <pt...@li...>]

 

This is a *very* impressive tool. 

It has already helped me A LOT today. Thanx!! 

But adding my idea would make it super^2 (needs cowork between the
valgrind core and your tool) 

/P 

---
Peter Toft <pt...@li...>

Wilfried Goesgens skrev den 2014-11-20 12:57: 

> Hi Peter, 
> 
> you should try massif visiualizer: 
> 
> https://projects.kde.org/projects/extragear/sdk/massif-visualizer 
> 
>> Thu Nov 20 2014 03:04:14 EST from "Peter Toft" <pt...@li...> Subject: [Valgrind-users] massif instrumentation in C/C++ code 
>> Hi all
>> 
>> One thing that I often is missing with valgrind/massif is a way to know 
>> know where I roughly am in my code when I see a given memory peak.
>> 
>> I could envision to add a valgrind-macro or alike in my C-code to 
>> indicate where I am in my code add (tentative syntax)
>> 
>> VALGRIND_MASSIF("calculator1()")
>> 
>> and another place
>> 
>> VALGRIND_MASSIF("reduceMem - middle")
>> 
>> Then the ms_print output should indicate (see the % signs) when in the 
>> code flow that we had this function call executed.
>> 
>> 19.63^ ###
>> | % #
>> | % # ::
>> | % # : :::
>> | % :::::::::# : : ::%
>> | % : # : : : %::
>> | % : # : : : %: :::
>> | % : # : : : %: : ::
>> | % ::::::::::: # : : : %: : : 
>> :::
>> | % : : # : : : %: : : 
>> : ::
>> | ::%::: : # : : : %: : : 
>> : : ::
>> | @@@: % : : # : : : %: : : 
>> : : : @
>> | ::@ : % : : # : : : %: : : 
>> : : : @
>> | :::: @ : % : : # : : : %: : : 
>> : : : @
>> | ::: : @ : % : : # : : : %: : : 
>> : : : @
>> | ::: : : @ : % : : # : : : %: : : 
>> : : : @
>> | :::: : : : @ : % : : # : : : %: : : 
>> : : : @
>> | ::: : : : : @ : % : : # : : : %: : : 
>> : : : @
>> | :::: : : : : : @ : % : : # : : : %: : : 
>> : : : @
>> | ::: : : : : : : @ : % : : # : : : %: : : 
>> : : : @
>> 0 
>> +--------------------------%-------------------------------%-------------->KB 
>> 0 
>> 29.48
>> % % 
>> reduceMem - middle
>> % calculator1()
>> 
>> Number of snapshots: 25
>> Detailed snapshots: [9, 14 (peak), 24]
>> 
>> Does something remotely similar to this already exist?
>> 
>> Best
>> 
>> -- 
>> Peter Toft <pt...@li...>
>> 
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk [1]
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
 

Links:
------
[1]
http://pubads.gdoubleclick.net/gampad/clk?id=157005751&amp;iu=/4140/ostg.clktrk

[Valgrind-users] Helgrind on ARM: false positive on condition variable

[Schmidt, A. <adr...@si...>]

Hi all,

Running Helgrind (Valgrind 3.10.0) on ARM, I get a result I cannot explain, but which looks like a false positive to me. 
This is my sample code (cv.c):
----------
#include <pthread.h>
#include <unistd.h>
#include <stdio.h>

int flag;
pthread_cond_t cv;
pthread_mutex_t mutex;
pthread_t sender, receiver;

void *fn_send(void *arg)
{
  // "ensure" that the receiver is waiting before we signal
  usleep(1000000);

  pthread_mutex_lock(&mutex);
  printf(" *** sending ***\n");
  flag = 1;
  pthread_cond_signal(&cv);
  pthread_mutex_unlock(&mutex);
}

void *fn_receive(void *arg)
{
  pthread_mutex_lock(&mutex);
  printf(" *** waiting ***\n");
  while (!flag)
    pthread_cond_wait(&cv, &mutex);
  printf(" *** received ***\n");
  pthread_mutex_unlock(&mutex);
}

int main()
{
  flag = 0;
  pthread_mutex_init(&mutex, NULL);
  pthread_cond_init(&cv, NULL);

  pthread_create(&sender, NULL, fn_send, NULL);
  pthread_create(&receiver, NULL, fn_receive, NULL);

  pthread_join(sender, NULL);
  pthread_join(receiver, NULL);
	
  printf(" *** done. ***\n");
  return 0;
}
----------
I compile with:
$ gcc -g -c -o cv cv.c -lpthread

I'm running this on two different systems:
On x86 (Core i5), I see the expected result:
$ uname -a
Linux debian 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) x86_64 GNU/Linux
$ valgrind --tool=helgrind ./cv
==2636== Helgrind, a thread error detector
==2636== Copyright (C) 2007-2013, and GNU GPL'd, by OpenWorks LLP et al.
==2636== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2636== Command: ./cv
==2636== 
 *** waiting ***
 *** sending ***
 *** received ***
 *** done. ***
==2636== 
==2636== For counts of detected and suppressed errors, rerun with: -v
==2636== Use --history-level=approx or =none to gain increased speed, at
==2636== the cost of reduced accuracy of conflicting-access information
==2636== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 20 from 20)

On armv7 (i.MX6), I see the following:
$ uname -a
Linux nitrogen 3.10.17-8-boundary-4t3 #8 SMP Wed Jul 30 00:42:25 CEST 2014 armv7l armv7l armv7l GNU/Linux
$ valgrind --tool=helgrind ./cv
==2069== Helgrind, a thread error detector
==2069== Copyright (C) 2007-2013, and GNU GPL'd, by OpenWorks LLP et al.
==2069== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2069== Command: ./cv
==2069== 
 *** waiting ***
 *** sending ***
 *** received ***
==2069== ---Thread-Announcement------------------------------------------
==2069== 
==2069== Thread #3 was created
==2069==    at 0x4907946: clone (clone.S:62)
==2069== 
==2069== ----------------------------------------------------------------
==2069== 
==2069== Thread #3 unlocked a not-locked lock at 0x11058
==2069==    at 0x4835EB8: pthread_mutex_unlock (hg_intercepts.c:707)
==2069==    by 0x876F: fn_receive (cv.c:30)
==2069==    by 0x48348F3: mythread_wrapper (hg_intercepts.c:234)
==2069==    by 0x485EFBB: start_thread (pthread_create.c:314)
==2069==    by 0x490797B: ??? (clone.S:92)
==2069==  Lock at 0x11058 was first observed
==2069==    at 0x483577C: pthread_mutex_init (hg_intercepts.c:518)
==2069==    by 0x8795: main (cv.c:36)
==2069==  Address 0x11058 is 0 bytes inside data symbol "mutex"
==2069== 
==2069== 
==2069== ----------------------------------------------------------------
==2069== 
==2069== Thread #3: Exiting thread still holds 1 lock
==2069==    at 0x48665F6: __libc_do_syscall (libc-do-syscall.S:44)
==2069== 
 *** done. ***
==2069== 
==2069== For counts of detected and suppressed errors, rerun with: -v
==2069== Use --history-level=approx or =none to gain increased speed, at
==2069== the cost of reduced accuracy of conflicting-access information
==2069== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 22 from 19)


I did notice the section in the manual stating that condition variables can cause problems when running Helgrind (7.5, Section 3), but:
- in my example the waiting thread gets to the rendezvous first, and
- https://bugs.kde.org/show_bug.cgi?id=213383 says that the information is obsolete anyway, and
- this would not explain the different behavior on ARM vs. x86.

Am I missing something here?

Best regards,
Adriaan

Re: [Valgrind-users] massif instrumentation in C/C++ code

[Milian W. <ma...@mi...>]

On Thursday 20 November 2014 09:52:46 Julian Seward wrote:
> On 11/20/2014 09:04 AM, Peter Toft wrote:
> > One thing that I often is missing with valgrind/massif is a way to know
> > know where I roughly am in my code when I see a given memory peak.
> > 
> > I could envision to add a valgrind-macro or alike in my C-code to
> > indicate where I am in my code add (tentative syntax)
> > 
> > Does something remotely similar to this already exist?
> 
> Not as far as I can see.  I had a look through ms_main.c but it doesn't
> seem to support any client requests.
> 
> One thing you might consider is to use the stack recording facilities,
> VG_(get_ExeContext), to get a stack trace for each for each snapshot
> that Massif makes.  Not sure how you'd combine the output with the
> existing output, though.

One can already get a stacktrace for each snapshot that massif makes via
--detailed-freq=1, no?

Anyhow, having such a user API for markers in the output would certainly be 
welcome. From a output format POV I'd say it could be done by adding a "desc=" 
or similar to snapshot entries, and then the client request API could just 
trigger the creation of a new detailed snapshot.

#-----------
snapshot=7
#-----------
time=14790656197
mem_heap_B=140095127
mem_heap_extra_B=12551169
mem_stacks_B=0
heap_tree=detailed
desc=Label given by caller of client request API
n32: 140095127 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
 ...

Adding support for such labels in Massif-Visualizer would be trivial. No clue 
about ms_print though.

Bye
-- 
Milian Wolff
ma...@mi...
http://milianw.de

Re: [Valgrind-users] massif instrumentation in C/C++ code

[Wilfried G. <dot...@ci...>]

   

Hi Peter,  

you should try massif visiualizer:  

https://projects.kde.org/projects/extragear/sdk/massif-visualizer  
>  Thu Nov 20 2014 03:04:14 EST from "Peter Toft" <pt...@li...>  Subject:
>[Valgrind-users] massif instrumentation in C/C++ code
>
>  Hi all
> 
> One thing that I often is missing with valgrind/massif is a way to know 
> know where I roughly am in my code when I see a given memory peak.
> 
> I could envision to add a valgrind-macro or alike in my C-code to 
> indicate where I am in my code add (tentative syntax)
> 
> VALGRIND_MASSIF("calculator1()")
> 
> and another place
> 
> VALGRIND_MASSIF("reduceMem - middle")
> 
> 
> Then the ms_print output should indicate (see the % signs) when in the 
> code flow that we had this function call executed.
> 
> 
> 19.63^ ###
> | % #
> | % # ::
> | % # : :::
> | % :::::::::# : : ::%
> | % : # : : : %::
> | % : # : : : %: :::
> | % : # : : : %: : ::
> | % ::::::::::: # : : : %: : : 
> :::
> | % : : # : : : %: : : 
> : ::
> | ::%::: : # : : : %: : : 
> : : ::
> | @@@: % : : # : : : %: : : 
> : : : @
> | ::@ : % : : # : : : %: : : 
> : : : @
> | :::: @ : % : : # : : : %: : : 
> : : : @
> | ::: : @ : % : : # : : : %: : : 
> : : : @
> | ::: : : @ : % : : # : : : %: : : 
> : : : @
> | :::: : : : @ : % : : # : : : %: : : 
> : : : @
> | ::: : : : : @ : % : : # : : : %: : : 
> : : : @
> | :::: : : : : : @ : % : : # : : : %: : : 
> : : : @
> | ::: : : : : : : @ : % : : # : : : %: : : 
> : : : @
> 0 
>
>+--------------------------%-------------------------------%-------------->KB
>
> 0 
> 29.48
> % % 
> reduceMem - middle
> % calculator1()
> 
> Number of snapshots: 25
> Detailed snapshots: [9, 14 (peak), 24]
> 
> Does something remotely similar to this already exist?
> 
> Best
> 
> -- 
> Peter Toft <pt...@li...>
> 
>
>------------------------------------------------------------------------------
>
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
>http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
>
>  

  

 

Re: [Valgrind-users] massif instrumentation in C/C++ code

[Peter T. <pt...@li...>]

Julian Seward skrev den 2014-11-20 09:52:
> On 11/20/2014 09:04 AM, Peter Toft wrote:
>> One thing that I often is missing with valgrind/massif is a way to 
>> know
>> know where I roughly am in my code when I see a given memory peak.
>> 
>> I could envision to add a valgrind-macro or alike in my C-code to
>> indicate where I am in my code add (tentative syntax)
> 
>> Does something remotely similar to this already exist?
> 
> Not as far as I can see.  I had a look through ms_main.c but it doesn't
> seem to support any client requests.
> 
> One thing you might consider is to use the stack recording facilities,
> VG_(get_ExeContext), to get a stack trace for each for each snapshot
> that Massif makes.  Not sure how you'd combine the output with the
> existing output, though.
> 
> J

Could it be roadmapped?
IMHO it would be very nice to have.

/pto

Re: [Valgrind-users] massif instrumentation in C/C++ code

[Peter T. <pt...@li...>]

whooa - wrapping killed the text.
The nice ASCII diagram can be seen at  http://pastebin.com/HS5CVd4s

---
Peter Toft <pt...@li...>

Peter Toft skrev den 2014-11-20 09:04:
> Hi all
> 
> One thing that I often is missing with valgrind/massif is a way to know
> know where I roughly am in my code when I see a given memory peak.
> 
> I could envision to add a valgrind-macro or alike in my C-code to
> indicate where I am in my code add (tentative syntax)
> 
>    VALGRIND_MASSIF("calculator1()")
> 
> and another place
> 
>    VALGRIND_MASSIF("reduceMem - middle")
> 
> 
> Then the ms_print output should indicate (see the % signs) when in the
> code flow that we had this function call executed.

Re: [Valgrind-users] massif instrumentation in C/C++ code

[Julian S. <js...@ac...>]

On 11/20/2014 09:04 AM, Peter Toft wrote:
> One thing that I often is missing with valgrind/massif is a way to know 
> know where I roughly am in my code when I see a given memory peak.
> 
> I could envision to add a valgrind-macro or alike in my C-code to 
> indicate where I am in my code add (tentative syntax)

> Does something remotely similar to this already exist?

Not as far as I can see.  I had a look through ms_main.c but it doesn't
seem to support any client requests.

One thing you might consider is to use the stack recording facilities,
VG_(get_ExeContext), to get a stack trace for each for each snapshot
that Massif makes.  Not sure how you'd combine the output with the
existing output, though.

J

[Valgrind-users] massif instrumentation in C/C++ code

[Peter T. <pt...@li...>]

Hi all

One thing that I often is missing with valgrind/massif is a way to know 
know where I roughly am in my code when I see a given memory peak.

I could envision to add a valgrind-macro or alike in my C-code to 
indicate where I am in my code add (tentative syntax)

   VALGRIND_MASSIF("calculator1()")

and another place

   VALGRIND_MASSIF("reduceMem - middle")


Then the ms_print output should indicate (see the % signs) when in the 
code flow that we had this function call executed.


19.63^                                                ###
      |                          %                     #
      |                          %                     #  ::
      |                          %                     #  : :::
      |                          %            :::::::::#  : :  ::%
      |                          %            :        #  : :  : %::
      |                          %            :        #  : :  : %: :::
      |                          %            :        #  : :  : %: :  ::
      |                          %  :::::::::::        #  : :  : %: :  : 
:::
      |                          %  :         :        #  : :  : %: :  : 
:  ::
      |                        ::%:::         :        #  : :  : %: :  : 
:  : ::
      |                     @@@: %  :         :        #  : :  : %: :  : 
:  : : @
      |                   ::@  : %  :         :        #  : :  : %: :  : 
:  : : @
      |                :::: @  : %  :         :        #  : :  : %: :  : 
:  : : @
      |              :::  : @  : %  :         :        #  : :  : %: :  : 
:  : : @
      |            ::: :  : @  : %  :         :        #  : :  : %: :  : 
:  : : @
      |         :::: : :  : @  : %  :         :        #  : :  : %: :  : 
:  : : @
      |       :::  : : :  : @  : %  :         :        #  : :  : %: :  : 
:  : : @
      |    :::: :  : : :  : @  : %  :         :        #  : :  : %: :  : 
:  : : @
      |  :::  : :  : : :  : @  : %  :         :        #  : :  : %: :  : 
:  : : @
    0 
+--------------------------%-------------------------------%-------------->KB 
     0                                                                   
29.48
                                 %                               % 
reduceMem - middle
                                 % calculator1()

Number of snapshots: 25
  Detailed snapshots: [9, 14 (peak), 24]

Does something remotely similar to this already exist?

Best

-- 
Peter Toft <pt...@li...>

Re: [Valgrind-users] helgrind/drd in android(mips)

[Bart V. A. <bva...@ac...>]

On 18/11/2014 23:33, Benny anam wrote:
> I try to figure out some problems about invalid free in android(mips) 
> device, which may be caused by thread sync, I did as the 
> README.android says compile the source and push to device, memcheck 
> works fine in my device, but when I changed option to --tool=helgrind, 
> the android logcat says the following:
> |I/start_valgrind.sh(  9328):  link_image[2207]:   9329  couldnot  load needed library
> '/data/local/Inst/lib/valgrind/vgpreload_drd-mips32-linux.so'  for  '/system/bin/app_process'  
> (mips_relocate_got[1749]:   9329  cannot locate'sched_yield'...|
> but sched_yield is in /system/lib/libc.so. I use valgrind 3.10.0 and 
> android 4.1 on mips, ndk-r8 and ndk-r10c both tried with the same 
> results. So my question is helgrind/drd supported in android(arch 
> mips) yet, If so, how can I make it work in my device?  Thanks!

Can you check whether Helgrind and/or DRD work if the sched_yield() call 
is changed into sleep(1) ? I'm not sure yet what's going on but this 
might be the quickest way to get these tools working.

Bart.

[Valgrind-users] helgrind/drd in android(mips)

[Benny a. <buf...@gm...>]

Hi!
I try to figure out some problems about invalid free in android(mips)
device, which may be caused by thread sync, I did as the README.android
says compile the source and push to device, memcheck works fine in my
device, but when I changed option to --tool=helgrind, the android logcat
says the following:

I/start_valgrind.sh( 9328): link_image[2207]:  9329 could not load
needed library
'/data/local/Inst/lib/valgrind/vgpreload_drd-mips32-linux.so' for
'/system/bin/app_process'
(mips_relocate_got[1749]:  9329 cannot locate 'sched_yield'...

but sched_yield is in /system/lib/libc.so. I use valgrind 3.10.0 and
android 4.1 on mips, ndk-r8 and ndk-r10c both tried with the same results.
So my question is helgrind/drd supported in android(arch mips) yet, If so,
how can I make it work in my device?  Thanks!

[Valgrind-users] Mac OS X 10.10 (Yosemite) support

[Julian S. <js...@ac...>]

There has been some effort recently to improve Valgrind's support for
Yosemite.  If you develop on Mac OS, you might like to try out the
trunk (svn co svn://svn.valgrind.org/valgrind/trunk) and report any
breakage you get.  Support for Yosemite is good enough that at least
one large graphical application (Firefox) runs OK.  Support for the
previous release, 10.9 (Mavericks), is also substantially improved.

Note that the work has targetted 64 bit processes only.  32 bit might
work, and probably better on Mavericks, but I suspect it will be
increasingly problematic on Yosemite due to Valgrind's 32 bit x86
instruction set support not having progressed passed SSSE3.

J

Re: [Valgrind-users] Valgrind support for ppc e500v2 machines

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

Hello John and Niranjan,

Thank you for your support John. Niranjan, thanks for using e500v2 with our Valgrind port;
kindly let us know if you see any issues or need further support.

Regards,
Anmol P. Paralkar

From: niranjan varma [mailto:var...@gm...]
Sent: Tuesday, November 11, 2014 1:03 AM
To: John Reiser
Cc: val...@li...
Subject: Re: [Valgrind-users] Valgrind support for ppc e500v2 machines


Hello John,
Thank you very much. Valgrind given inside the Free scale SDK with patch for spe is working.

Regards,
Niranjan
On 6 Nov 2014 22:06, "John Reiser" <jr...@bi...<mailto:jr...@bi...>> wrote:
> Hi, I've cross compiled valgrind for ppc 32 bit linux. The target is e500v2 cpu. I'm getting unrecognised instruction in memcpy(ld-2.11.1.so<http://ld-2.11.1.so> <http://ld-2.11.1.so>).
> I've tried with -mno-spe build flag, but it was of no use.
> Can you please suggest a solution?

Searching the archives of [Valgrind-users] for the term "e500v2"
yields this message:
=====
From: An...@fr...<mailto:An...@fr...>
Date: Mon, 21 Jul 2014 18:24:12 +0000
Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains    for e500v2


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

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Val...@li...<mailto:Val...@li...>
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind support for ppc e500v2 machines

[niranjan v. <var...@gm...>]

Hello John,
Thank you very much. Valgrind given inside the Free scale SDK with patch
for spe is working.

Regards,
Niranjan
On 6 Nov 2014 22:06, "John Reiser" <jr...@bi...> wrote:

> > Hi, I've cross compiled valgrind for ppc 32 bit linux. The target is
> e500v2 cpu. I'm getting unrecognised instruction in memcpy(ld-2.11.1.so <
> http://ld-2.11.1.so>).
> > I've tried with -mno-spe build flag, but it was of no use.
> > Can you please suggest a solution?
>
> Searching the archives of [Valgrind-users] for the term "e500v2"
> yields this message:
> =====
> From: An...@fr...
> Date: Mon, 21 Jul 2014 18:24:12 +0000
> Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains
> for e500v2
>
>
> 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
> =====
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Valgrind support for ppc e500v2 machines

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

> Hi, I've cross compiled valgrind for ppc 32 bit linux. The target is e500v2 cpu. I'm getting unrecognised instruction in memcpy(ld-2.11.1.so <http://ld-2.11.1.so>).
> I've tried with -mno-spe build flag, but it was of no use.
> Can you please suggest a solution?

Searching the archives of [Valgrind-users] for the term "e500v2"
yields this message:
=====
From: An...@fr...
Date: Mon, 21 Jul 2014 18:24:12 +0000
Re: [Valgrind-users] Valgrind does not support powerpcspe toolchains	for e500v2


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

[Valgrind-users] Valgrind support for ppc e500v2 machines

[niranjan v. <var...@gm...>]

Hi, I've cross compiled valgrind for ppc 32 bit linux. The target is e500v2
cpu. I'm getting unrecognised instruction in memcpy(ld-2.11.1.so).
I've tried with -mno-spe build flag, but it was of no use.
Can you please suggest a solution?

Thanks,
Niranjan

[Valgrind-users] Call for Proposals: Valgrind developer room, FOSDEM 2015, Brussels, 31 Jan 2015

[Julian S. <js...@ac...>]

Valgrind developer room at FOSDEM 2015 (Brussels, Belgium, 31 January).

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 2015 will take place during the weekend of Saturday, 31 January
and Sunday 1 February 2015.  On Saturday we will have a devroom for
Valgrind.  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 Valgrind community.
Please join us, regardless of whether you are a Valgrind core hacker,
Valgrind tool hacker, Valgrind user, Valgrind packager or hacker on a
project that integrates, extends or complements Valgrind.

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
Monday 1 December 2014, so we can make a list of activities during the
day.

Some possible topics for talks/discussions are:

- Recently added functional changes (for valgrind users).

- State of the valgrind code base (core hackers).

- Speeding up Memcheck by inlining of the fast cases of its helper
  function calls (core hackers).

- Supporting Valgrind on MacOS X 10.9 (Mavericks) and 10.10 (Yosemite)
  (valgrind developers and users).

- The AArch64 ARMv8 port (valgrind developers and users).

- Valgrind and Wine (valgrind developers and users).

- Helgrind - basic design, problems and opportunities (core and tools).

- Get feedback on what what kinds of new functionality would
  be useful. Which tools users would like to see and/or which new
  features for the existing tools. (valgrind developers and users).

  - Modify memcheck to report the last leaked pointer to a block
    integrate "omega" as a memcheck option or omega as a separate tool.

  - Better support compiled and JITted code.
    allowing the JIT compiler to indicate the link between
    the JITted code and the source code.

  - Valgrind and transactional memory.

- How to add simple features (adding syscalls for a platform or VEX
  instructions for a architecture port). (new core developers).

- Making Valgrind really multi-threaded, parallelising Memcheck
  parallelising the rest of the framework, and tools (for core hackers).

- Should we continue to support MacOS? What about Valgrind on
  MS-Windows? Solaris? (attracting new hackers).

- Redo the JIT framework to reduce baseline overheads? (core hackers).

- Make Callgrind work sanely on ARM (core hackers).

- Discuss release/bugfixing strategy/policy (core hackers, packagers).

- Packaging valgrind for distros, handling patches, suppressions, etc.
  (packagers).

- Valgrind/GDB integration (cross project).

- Valgrind vs the compiler. Compilers like GCC and clang now have
  "valgrind like" features, eg -fsanitize=address|thread|undefined.
  How does valgrind complement or improve on these features?

- Eclipse and other visualisation tools for valgrind (cross project).

- Practical examples of using Valgrind in (big) system automatic
  regression testing (users).

Use the FOSDEM 'pentabarf' tool to submit your proposal.
https://penta.fosdem.org/submission/FOSDEM15/

- If necessary, create a Pentabarf account and activate 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 "Valgrind 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

Julian, Philippe and Mark will review the proposals and organize the
schedule for the day.  Please feel free to suggest or discuss any ideas
for the devroom on the Valgrind developer mailinglist before creating a
proposal: val...@li...

Recording of talks

This year 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:    Monday    1 Dec 2014
  Devroom Schedule announcement:          Monday   15 Dec 2014
  Devroom day:                            Saturday 31 Jan 2015

Hope to see you all at FOSDEM 2015 in the Valgrind devroom.
Brussels (Belgium), Saturday 31 January 2015.
https://fosdem.org/2015/schedule/track/valgrind/