valgrind-users — General discussion list for Valgrind users

[Valgrind-users] .gcda files are not generated when run on valgrind

[Ravi K. <rav...@gm...>]

Hi,

We have a huge code base which requires a lot of time to check the runtime
errors and code coverage (using lcov tool) separately

We have built  the components with coverage flags and are now trying to run
on valgrind for .gcda files to find coverage. but, .gcda files are not
generated sometimes when run on valgrind. But the same components when run
with coverage flags without valgrind generate .gcda files

We are doing this to reduce the execution time of the test case . Can we
rely on this method or shall we avoid running on valgrind with coverage
flags to get coverage

Has anyone tried like this before ? appreciate any help on this .

Thanks in advance,

Regards,
Ravi

[Valgrind-users] Call for Participation at FOSDEM 2017

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

A gentle reminder to all Valgrind folks:
we call for your participation at FOSDEM 2017, see below.
The deadline for abstract submissions is in less than two weeks.
Let us know if you have something in works and need slightly
more time.

See you all there,
I.

-----------------------------------
Valgrind developer room at FOSDEM 2017 (Brussels, Belgium, February 4th).

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 2017 will take place during the weekend of Saturday, February 4th
and Sunday February 5th 2017.  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.

For the third time there will be a dedicated Valgrind devroom.
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
Thursday December 1st 2016, 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 new MacOS X versions
  (valgrind developers and users).

- Status of current ports and possible future ports to other architectures
(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 an 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 OS X? What about Valgrind on
  MS-Windows? Solaris? *BSD? (attracting new hackers).

- Redo the JIT framework to reduce baseline overheads? (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/FOSDEM17

- 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 "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, Mark and Ivosh 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: valgrind-developers at lists.sourceforge.net

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:    Thursday    1 Dec 2016
  Devroom Schedule announcement:        Thursday   15 Dec 2016
  Devroom day:                                          Saturday   4 Feb
2017

Hope to see you all at FOSDEM 2017 in the Valgrind devroom.
Brussels (Belgium), Saturday February 4th 2017.
https://fosdem.org/2017/schedule/track/valgrind/

[Valgrind-users] OSX dSYM Error

[Isaac A <iar...@gm...>]

I'm repeatedly bumping into an error with regards to dSYM files on OSX.
I've posted about the incident in detail here http://stackoverflow.com/
questions/40703954/how-can-i-get-meaningful-function-names-
in-callgrind-output-on-osx-from-the-comm .

Short Version: I'm not sure why, but (I think?) the valgrind search for
dSYM files is being thrown off. I'm not entirely sure if this is the case
or I'm barking up the wrong tree here. I've mostly been looking at the find
function (find_separate_debug_file (const HChar *executable_name)) to see
if this is the case but I'm still a bit of a noobie and may just have
goofed on my environment somehow.

I would be grateful for any help that could be provided.

Re: [Valgrind-users] Extending memcheck's validity bit propagation

[Patrick J. L. <lop...@gm...>]

Thank you, John and Phillippe, for your replies.

First, to John:

Valgrind actually does know that a conditional move is a functional
operation and not a conditional branch. So if you can convince your
compiler to emit conditional moves, Valgrind will simply "taint" the output
instead of emitting a diagnostic. (Actually, my original example is so
simple that a modern compiler will see that it invokes undefined behavior,
and then the compiler might optimize away the entire program. Of course my
real-life case is not so simple; in reality, the undefined value is coming
from outside the function.)

Also, even with optimization disabled, or with a compiler that does not
emit CMOV instructions, I can get the behavior I want by rewriting like so:

    int a; /* undefined */
    int b = a & (-(a > 0));

It is always possible to rewrite pure functions to avoid branches; anyone
who writes vectorized code is probably familiar with this sort of trick.
However, the computational overhead can become prohibitive. My second
example is the sort of case that would be (very) painful to "fix" in this
way.

To both of you:

I do not necessarily want Valgrind to figure all of this out
automatically... I am willing to annotate my code with VG_ macros to
achieve the effect I want. As I mentioned in the original Email, I believe
I can mostly do this with the GET_VBITS() and SET_VBITS() macros. But I
fear I will lose the origin tracking, which in my case is extremely useful.

And yes, this is creating a huge number of false positives for me. (My use
case is a bit of a long story; I am hoping you will trust me when I say I
cannot easily fix this in some other way.) I could add suppression rules,
of course, but then I might miss real bugs... I really do want simply to
propagate the invalidity bits and only see the warning if the value is
later used.

Thank you again for your replies.

 - Pat

Re: [Valgrind-users] Extending memcheck's validity bit propagation

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

> I am not sure to understand how you will differentiate the above
>     if (a > 0)
>       b = a;
>     else
>       b = 0;
>
> from
>     if (a > 0) {
>       b = a;
>       launch_all_missiles();
>     } else
>       b = 0;

Because the first paragraph is equivalent to "b = max(0, a);"
which has relatively simple semantics, but the second paragraph is not.

As I pointed out to the list 2 days ago, if the x86* code is:
	mov $0, r_b
	cmp $0, r_a
	cmovg r_a, r_b  # conditional move if > 0; r_a to r_b
then it is somewhat easy to convince VEX to set state(b) = state(a)
without complaint (when condition code bits indicate > 0.)

If the compiled code uses explicit branching, then probably it's hard.
Quite a few analysis tools (covering either software or hardware!)
have [have had] difficulty with re-convergent fan out.

Re: [Valgrind-users] Extending memcheck's validity bit propagation

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

On Thu, 2016-11-03 at 15:36 -0700, Patrick J. LoPresti wrote:
> Right now, if I have code like this:
>   int a; /* invalid value */
>   int b = a + 1; /* operation on invalid value */
> ...memcheck does not produce a warning for the addition. It just
> taints b as invalid and only generates a warning if I try to use b in
> a behavior-changing way. This is good, and it is exactly what I want.
> 
> 
> However, if instead I have this code:
>   int a; /* invalid value */
>   int b;
>   if (a > 0) /* conditional on invalid value */
>     b = a;
>   else
>     b = 0;
> ...memcheck produces a warning on the conditional branch. But if you
> look at what this code actually computes, it is just "b = max(a,0)",
> which is not so different from "b = a + 1". (That is, b is just some
> simple function of a.) I want to teach memcheck to treat this second
> example like the first; that is, just taint b as invalid if a is
> invalid.
I am not sure to understand how you will differentiate the above
    if (a > 0)
      b = a;
    else
      b = 0;

from
    if (a > 0) {
      b = a;
      launch_all_missiles();
    } else
      b = 0;

What we want is an error when the 'outside visible behaviour' of the
program depends on uninit values.
When a jump is processed, how do we know that the jump is jumping
to a location that will have no outside visible effect ?

For sure, we need/must have a valgrind error for the above case,
otherwise we risk a nuclear 3rd world war :).

Or maybe the idea is to do that only for very specific
way to compile
   if (a > 0)
when the then/else branches are only assignment to b ?

This case seems very specialised to me, probably depending
a lot from the compiler and compiler optimisation options.

Is such code creating many false positive ?

Philippe

Re: [Valgrind-users] Verbosity levels

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

On Fri, 2016-11-04 at 16:16 +0100, Julian Seward wrote:
> On 04/11/16 16:04, Nicholas Lamb wrote:
> > Does anyone know the maximum verbosity level supported by Valgrind?
> 
> 2 or 3.  Not sure now.  You can also get tons of internal debugging info
> with -d or -d -d etc.
Note you can put a lot of -v, and that will increase the verbosity
value (e.g. adding 6 -v args  will increase the default verbosity from 1
to 7).
But as far as I can see, the code does nowhere something like >= 4,
the 'highest' I have seen is >= 3.

Philippe

Re: [Valgrind-users] Verbosity levels

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

On 04/11/16 16:04, Nicholas Lamb wrote:
> Does anyone know the maximum verbosity level supported by Valgrind?

2 or 3.  Not sure now.  You can also get tons of internal debugging info
with -d or -d -d etc.

J

[Valgrind-users] Verbosity levels

[Nicholas L. <nl...@bl...>]

Hi,

Does anyone know the maximum verbosity level supported by Valgrind? Is it tool-specific? In the user manual, for the -v or -verbose option, it states: "Repeating the option increases the verbosity level". But it doesn't mention how many -v's can be used.

Thanks,

Nicholas.

Re: [Valgrind-users] Extending memcheck's validity bit propagation

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

>   int a; /* invalid value */
>   int b;
>   if (a > 0) /* conditional on invalid value */
>     b = a;
>   else
>     b = 0;
>
> ...memcheck produces a warning on the conditional branch. But if you look at what this code actually computes, it is just "b = max(a,0)", which is not so different from "b = a + 1". (That is, b is just some simple function of a.) I want to teach memcheck to treat this second example like the first;
> that is, just taint b as invalid if a is invalid.

Teaching VEX about the x86 opcode CMOVG (conditional move if Greater)
might not be so difficult.  Teaching VEX about branch-and-reconverge
control flow involving multiple instructions, probably is harder.

>
> Another example:
>
>   extern unsigned char lookup[256]; // assume this is initialized
>
>   unsigned char x;
>   unsigned char y = lookup[x];
>
> Here, I have some 8-bit function implemented using a lookup table. Again, memcheck issues a diagnostic for using x as part of computing an address. But I want to think of y as a simple function of x, and tell memcheck to just let y inherit x's invalidity.
>

The key here is range analysis on the subscripting operation "lookup[x]".
If the bounds on 'x' propagate, and if 'lookup' has effective bounds,
then probably it is not so hard.

-- 

[Valgrind-users] Extending memcheck's validity bit propagation

[Patrick J. L. <lop...@gm...>]

Right now, if I have code like this:

  int a; /* invalid value */
  int b = a + 1; /* operation on invalid value */

...memcheck does not produce a warning for the addition. It just taints b
as invalid and only generates a warning if I try to use b in a
behavior-changing way. This is good, and it is exactly what I want.

However, if instead I have this code:

  int a; /* invalid value */
  int b;
  if (a > 0) /* conditional on invalid value */
    b = a;
  else
    b = 0;

...memcheck produces a warning on the conditional branch. But if you look
at what this code actually computes, it is just "b = max(a,0)", which is
not so different from "b = a + 1". (That is, b is just some simple function
of a.) I want to teach memcheck to treat this second example like the
first; that is, just taint b as invalid if a is invalid.

Another example:

  extern unsigned char lookup[256]; // assume this is initialized

  unsigned char x;
  unsigned char y = lookup[x];

Here, I have some 8-bit function implemented using a lookup table. Again,
memcheck issues a diagnostic for using x as part of computing an address.
But I want to think of y as a simple function of x, and tell memcheck to
just let y inherit x's invalidity.

I believe I can cobble together what I want from VALGRIND_GET_VBITS() and
VALGRIND_SET_VBITS(). But I have two questions.

1) Is this the right way to do this, or is there some other mechanism more
suitable for this purpose?
2) If I do use SET/GET_VBITS(), how can I arrange for --track-origins=yes
to work if there is a later use of the uninitialized data?

Thanks.

 - Pat

Re: [Valgrind-users] setrlimit error question

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

On Wed, 2016-11-02 at 09:12 +0800, 雨若冰 wrote:
> Hi!
>  I'm trying to use valgrind to test memory leak.When I use "valgrind
> --leak-check=full ./**(my project name)",there will occur the
> question.-->setrlimit error ,errcode= 1.The program stops here and
> circles the error.
>  If I # the question, the mainly part I want to test also skips.Is
> there any way to solve the question?
>  It's a server program I try to test.
Which valgrind version ? which OS ?

What are the arguments of the setrlimit syscall which is failing ?

A first thing to try is to run with
   --trace-syscalls=yes
so as to see what syscall fails when.

Philippe

[Valgrind-users] setrlimit error question

[雨. <904...@qq...>]

Hi!
 I'm trying to use valgrind to test memory leak.When I use  "valgrind --leak-check=full ./**(my project name)",there will occur the  question.-->setrlimit error ,errcode= 1.The program stops here and  circles the error.
 If I # the question, the mainly part I want to test also skips.Is there any way to solve the question?
 It's a server program I try to test.
 Thanks a lot !

[Valgrind-users] ARM64 Invalid Instruction

[<kyl...@L-...>]

Here is a copy of a crash I get when running valgrind on an ODROID-C2 (Cortex-A53).
==1028== Memcheck, a memory error detector
==1028== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1028== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1028== Command: python grc_tests/becdl.py
==1028==
==1028== Invalid read of size 4
==1028==    at 0x48EC0D0: PyObject_Free (in /usr/lib/libpython2.7.so.1.0)
==1028==  Address 0x4d0c020 is 224 bytes inside a block of size 2,731 free'd
==1028==    at 0x484511C: free (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==1028==  Block was alloc'd at
==1028==    at 0x4843F84: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==1028==
==1028==
==1028== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- n
==1028== Conditional jump or move depends on uninitialised value(s)
==1028==    at 0x48EC0DC: PyObject_Free (in /usr/lib/libpython2.7.so.1.0)
==1028==
==1028==
==1028== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- n
==1028== Use of uninitialised value of size 8
==1028==    at 0x48EC108: PyObject_Free (in /usr/lib/libpython2.7.so.1.0)
==1028==
==1028==
==1028== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- n
==1028== Invalid read of size 4
==1028==    at 0x48EC614: PyObject_Realloc (in /usr/lib/libpython2.7.so.1.0)
==1028==  Address 0x4f96020 is 384 bytes inside a block of size 1,120 free'd
==1028==    at 0x4846050: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==1028==  Block was alloc'd at
==1028==    at 0x4846050: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==1028==
==1028==
==1028== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- n
==1028== Conditional jump or move depends on uninitialised value(s)
==1028==    at 0x48EC61C: PyObject_Realloc (in /usr/lib/libpython2.7.so.1.0)
==1028==
==1028==
==1028== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- n
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0x69410014
disInstr(arm64): 0110'1001 0100'0001 0000'0000 0001'0100
==1028== valgrind: Unrecognised instruction at address 0x5a32024.
==1028==    at 0x5A32024: ??? (in /usr/lib/python2.7/site-packages/PyQt4/QtCore.so)
==1028== Your program just tried to execute an instruction that Valgrind
==1028== did not recognise.  There are two possible reasons for this.
==1028== 1. Your program has a bug and erroneously jumped to a non-code
==1028==    location.  If you are running Memcheck and you just saw a
==1028==    warning about a bad jump, it's probably your program's fault.
==1028== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1028==    i.e. it's Valgrind's fault.  If you think this is the case or
==1028==    you are not sure, please let us know and we'll try to fix it.
==1028== Either way, Valgrind will now raise a SIGILL signal which will
==1028== probably kill your program.
==1028==
==1028== Process terminating with default action of signal 4 (SIGILL)
==1028==  Illegal opcode at address 0x5A32024
==1028==    at 0x5A32024: ??? (in /usr/lib/python2.7/site-packages/PyQt4/QtCore.so)
==1028==
==1028== HEAP SUMMARY:
==1028==     in use at exit: 2,729,906 bytes in 2,488 blocks
==1028==   total heap usage: 12,592 allocs, 10,104 frees, 6,005,354 bytes allocated
==1028==
==1028== 8,512 bytes in 14 blocks are possibly lost in loss record 2 of 5
==1028==    at 0x4843F84: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==1028==
==1028==
==1028== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----




W. Kyle Unice
Staff Engineer
MS F1H03
322 North 2200 West Dock 3
Salt Lake City, Utah 84116-0850

Voice: 801-594-2687

[Valgrind-users] Val grind on OS X 10.11.2

[Castellana M. <mic...@cu...>]

Dear all,
I am having troubles building Valgrind on OS X 10.11.2 El capitan. I am aware that valgrind does not fully support this OS, but I was wondering if any of you found a way to fix this specific problem. After downloading valgrind-3.12.0.tar.bz2 from http://valgrind.org/downloads/current.html and unzipping the file in a folder, I successfully ran './autogen.sh' and './configure'. However, when I run ‘make' I get the usual error

m_syscall.c:708:1: error: unknown type name ‘__private_extern__’

which I fixed by adding '#define __private_extern__ extern’ to 'coregrind/m_syscall.c’, 'coregrind/m_syswrap/syswrap-darwin.c’ and to 'coregrind/vg_preloaded.c’ as indicated in http://superuser.com/questions/630674/valgrind-installation-errors-on-osx-10-8 .

When I run make again, I get the error

Undefined symbols for architecture i386:
  "___ctzdi2", referenced from:
      _doRegisterAllocation in libvex-x86-darwin.a(libvex_x86_darwin_a-host_generic_reg_alloc2.o)
ld: symbol(s) not found for architecture i386
make[3]: *** [memcheck-x86-darwin] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Do you know how to fix this?

Thank you.
Best,
Michele

Re: [Valgrind-users] Valgrind-3.12.0 is available

[Mark R. <ma...@cs...>]

The Daikon tool set uses Valgrind to deal with C/C++ codes.  We told our
user base in April of this year that we will no longer support 32bit codes.

Mark Roberts
 

> -----Original Message-----
> From: Dallman, John [mailto:joh...@si...]
> Sent: Monday, October 24, 2016 8:54 AM
> To: valgrind-users
> Subject: Re: [Valgrind-users] Valgrind-3.12.0 is available
> 
> > Whilst 3.12.0 continues to support the 32-bit x86 instruction set, we
> > would prefer users to migrate to 64-bit x86 (a.k.a amd64 or x86_64)
where
> possible.
> 
> Sound move. I was able to give up shipping 32-bit x86 Mac and Linux
> software earlier this year, and our customers tend to be quite
conservative
> about this.
> 
> --
> John Dallman
> 
> 
> -----------------
> Siemens Industry Software Limited is a limited company registered in
England
> and Wales.
> Registered number: 3476850.
> Registered office: Faraday House, Sir William Siemens Square, Frimley,
> Surrey, GU16 8QD.
> 
>
----------------------------------------------------------------------------
--
> 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] Valgrind-3.12.0 is available

[Dallman, J. <joh...@si...>]

> Whilst 3.12.0 continues to support the 32-bit x86 instruction set, we would
> prefer users to migrate to 64-bit x86 (a.k.a amd64 or x86_64) where possible.

Sound move. I was able to give up shipping 32-bit x86 Mac and Linux software
earlier this year, and our customers tend to be quite conservative about this.

--
John Dallman


-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

[Valgrind-users] Valgrind-3.12.0 is available

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

We are pleased to announce a new release of Valgrind, version 3.12.0,
available from http://www.valgrind.org.

3.12.0 is a feature release with many improvements and the usual
collection of bug fixes.  This release adds support for POWER ISA 3.0,
improves instruction set support on ARM32, ARM64 and MIPS, and
provides support for the latest common components (kernel, gcc, glibc).
There are many smaller refinements and new features.  The release notes
below give more details.

NOTE! FOSDEM 2017: we will have a Valgrind developer room at FOSDEM
in Brussels, Belgium, on Sat 4 February 2017.  The Call for Participation
is at https://lists.fosdem.org/pipermail/fosdem/2016-October/002467.html.
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.

Our thanks to all those who contribute to Valgrind's development.
This release represents a great deal of time, energy and effort on the
part of many people.

Happy and productive debugging and profiling,

-- The Valgrind Developers



Release 3.12.0 (20 October 2016)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.12.0 is a feature release with many improvements and the usual
collection of bug fixes.

This release supports X86/Linux, AMD64/Linux, ARM32/Linux,
ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux,
MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android,
MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, X86/MacOSX
10.10 and AMD64/MacOSX 10.10.  There is also preliminary support for
X86/MacOSX 10.11/12, AMD64/MacOSX 10.11/12 and TILEGX/Linux.

* ================== PLATFORM CHANGES =================

* POWER: Support for ISA 3.0 has been added

* mips: support for O32 FPXX ABI has been added.
* mips: improved recognition of different processors
* mips: determination of page size now done at run time

* amd64: Partial support for AMD FMA4 instructions.

* arm, arm64: Support for v8 crypto and CRC instructions.

* Improvements and robustification of the Solaris port.

* Preliminary support for MacOS 10.12 (Sierra) has been added.

Whilst 3.12.0 continues to support the 32-bit x86 instruction set, we
would prefer users to migrate to 64-bit x86 (a.k.a amd64 or x86_64)
where possible.  Valgrind's support for 32-bit x86 has stagnated in
recent years and has fallen far behind that for 64-bit x86
instructions.  By contrast 64-bit x86 is well supported, up to and
including AVX2.

* ==================== TOOL CHANGES ====================

* Memcheck:

  - Added meta mempool support for describing a custom allocator which:
     - Auto-frees all chunks assuming that destroying a pool destroys all
       objects in the pool
     - Uses itself to allocate other memory blocks

  - New flag --ignore-range-below-sp to ignore memory accesses below
    the stack pointer, if you really have to.  The related flag
    --workaround-gcc296-bugs=yes is now deprecated.  Use
    --ignore-range-below-sp=1024-1 as a replacement.

* DRD:

  - Improved thread startup time significantly on non-Linux platforms.

* DHAT

  - Added collection of the metric "tot-blocks-allocd"

* ==================== OTHER CHANGES ====================

* Replacement/wrapping of malloc/new related functions is now done not just
  for system libraries by default, but for any globally defined malloc/new
  related function (both in shared libraries and statically linked alternative
  malloc implementations).  The dynamic (runtime) linker is excluded, though.
  To only intercept malloc/new related functions in
  system libraries use --soname-synonyms=somalloc=nouserintercepts (where
  "nouserintercepts" can be any non-existing library name).
  This new functionality is not implemented for MacOS X.

* The maximum number of callers in a suppression entry is now equal to
  the maximum size for --num-callers (500).
  Note that --gen-suppressions=yes|all similarly generates suppressions
  containing up to --num-callers frames.

* New and modified GDB server monitor features:

  - Valgrind's gdbserver now accepts the command 'catch syscall'.
    Note that you must have GDB >= 7.11 to use 'catch syscall' with
    gdbserver.

* New option --run-cxx-freeres=<yes|no> can be used to change whether
  __gnu_cxx::__freeres() cleanup function is called or not. Default is
  'yes'.

* Valgrind is able to read compressed debuginfo sections in two formats:
  - zlib ELF gABI format with SHF_COMPRESSED flag (gcc option -gz=zlib)
  - zlib GNU format with .zdebug sections (gcc option -gz=zlib-gnu)

* Modest JIT-cost improvements: the cost of instrumenting code blocks
  for the most common use case (x86_64-linux, Memcheck) has been
  reduced by 10%-15%.

* Improved performance for programs that do a lot of discarding of
  instruction address ranges of 8KB or less.

* The C++ symbol demangler has been updated.

* More robustness against invalid syscall parameters on Linux.

* ==================== FIXED BUGS ====================

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.

191069  Exiting due to signal not reported in XML output
199468  Suppressions: stack size limited to 25
        while --num-callers allows more frames
212352  vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC (FCOM)
278744  cvtps2pd with redundant RexW
303877  valgrind doesn't support compressed debuginfo sections.
345307  Warning about "still reachable" memory when using libstdc++ from gcc 5
348345  Assertion fails for negative lineno
351282  V 3.10.1 MIPS softfloat build broken with GCC 4.9.3 / binutils 2.25.1
351692  Dumps created by valgrind are not readable by gdb (mips32 specific)
351804  Crash on generating suppressions for "printf" call on OS X 10.10
352197  mips: mmap2() not wrapped correctly for page size > 4096
353083  arm64 doesn't implement various xattr system calls
353084  arm64 doesn't support sigpending system call
353137  www: update info for Supported Platforms
353138  www: update "The Valgrind Developers" page
353370  don't advertise RDRAND in cpuid for Core-i7-4910-like avx2 machine
        == 365325
        == 357873
353384  amd64->IR: 0x66 0xF 0x3A 0x62 0xD1 0x62 (pcmpXstrX $0x62)
353398  WARNING: unhandled amd64-solaris syscall: 207
353660  XML in auxwhat tag not escaping reserved symbols properly
353680  s390x: Crash with certain glibc versions due to non-implemented TBEGIN
353727  amd64->IR: 0x66 0xF 0x3A 0x62 0xD1 0x72 (pcmpXstrX $0x72)
353802  ELF debug info reader confused with multiple .rodata sections
353891  Assert 'bad_scanned_addr < VG_ROUNDDN(start+len, sizeof(Addr))' failed
353917  unhandled amd64-solaris syscall fchdir(120)
353920  unhandled amd64-solaris syscall: 170
354274  arm: unhandled instruction: 0xEBAD 0x0AC1 (sub.w sl, sp, r1, lsl #3)
354392  unhandled amd64-solaris syscall: 171
354797  Vbit test does not include Iops for Power 8 instruction support
354883  tst->os_state.pthread - magic_delta assertion failure on OSX 10.11
        == 361351
        == 362920
        == 366222
354933  Fix documentation of --kernel-variant=android-no-hw-tls option
355188  valgrind should intercept all malloc related global functions
355454  do not intercept malloc related symbols from the runtime linker
355455  stderr.exp of test cases wrapmalloc and wrapmallocstatic overconstrained
356044  Dwarf line info reader misinterprets is_stmt register
356112  mips: replace addi with addiu
356393  valgrind (vex) crashes because isZeroU happened
        == 363497
        == 364497
356676  arm64-linux: unhandled syscalls 125, 126 (sched_get_priority_max/min)
356678  arm64-linux: unhandled syscall 232 (mincore)
356817  valgrind.h triggers compiler errors on MSVC when defining NVALGRIND
356823  Unsupported ARM instruction: stlex
357059  x86/amd64: SSE cvtpi2ps with memory source does transition to MMX state
357338  Unhandled instruction for SHA instructions libcrypto Boring SSL
357673  crash if I try to run valgrind with a binary link with libcurl
357833  Setting RLIMIT_DATA to zero breaks with linux 4.5+
357871  pthread_spin_destroy not properly wrapped
357887  Calls to VG_(fclose) do not close the file descriptor
357932  amd64->IR: accept redundant REX prefixes for {minsd,maxsd} m128, xmm.
358030  support direct socket calls on x86 32bit (new in linux 4.3)
358478  drd/tests/std_thread.cpp doesn't build with GCC6
359133  Assertion 'eltSzB <= ddpa->poolSzB' failed
359181  Buffer Overflow during Demangling
359201  futex syscall "skips" argument 5 if op is FUTEX_WAIT_BITSET
359289  s390x: popcnt (B9E1) not implemented
359472  The Power PC vsubuqm instruction doesn't always give the correct result
359503  Add missing syscalls for aarch64 (arm64)
359645  "You need libc6-dbg" help message could be more helpful
359703  s390: wire up separate socketcalls system calls
359724  getsockname might crash - deref_UInt should call safe_to_deref
359733  amd64 implement ld.so strchr/index override like x86
359767  Valgrind does not support the IBM POWER ISA 3.0 instructions, part 1/5
359829  Power PC test suite none/tests/ppc64/test_isa_2_07.c uses
        uninitialized data
359838  arm64: Unhandled instruction 0xD5033F5F (clrex)
359871  Incorrect mask handling in ppoll
359952  Unrecognised PCMPESTRM variants (0x70, 0x19)
360008  Contents of Power vr registers contents is not printed correctly when
        the --vgdb-shadow-registers=yes option is used
360035  POWER PC instruction bcdadd and bcdsubtract generate result with
        non-zero shadow bits
360378  arm64: Unhandled instruction 0x5E280844 (sha1h  s4, s2)
360425  arm64 unsupported instruction ldpsw
        == 364435
360519  none/tests/arm64/memory.vgtest might fail with newer gcc
360571  Error about the Android Runtime reading below the stack pointer on ARM
360574  Wrong parameter type for an ashmem ioctl() call on Android and ARM64
360749  kludge for multiple .rodata sections on Solaris no longer needed
360752  raise the number of reserved fds in m_main.c from 10 to 12
361207  Valgrind does not support the IBM POWER ISA 3.0 instructions, part 2/5
361226  s390x: risbgn (EC59) not implemented
361253  [s390x] ex_clone.c:42: undefined reference to `pthread_create'
361354  ppc64[le]: wire up separate socketcalls system calls
361615  Inconsistent termination for multithreaded process terminated by signal
361926  Unhandled Solaris syscall: sysfs(84)
362009  V dumps core on unimplemented functionality before threads are created
362329  Valgrind does not support the IBM POWER ISA 3.0 instructions, part 3/5
362894  missing (broken) support for wbit field on mtfsfi instruction (ppc64)
362935  [AsusWRT] Assertion 'sizeof(TTEntryC) <= 88' failed
362953  Request for an update to the Valgrind Developers page
363680  add renameat2() support
363705  arm64 missing syscall name_to_handle_at and open_by_handle_at
363714  ppc64 missing syscalls sync, waitid and name_to/open_by_handle_at
363858  Valgrind does not support the IBM POWER ISA 3.0 instructions, part 4/5
364058  clarify in manual limitations of array overruns detections
364413  pselect sycallwrapper mishandles NULL sigmask
364728  Power PC, missing support for several HW registers in
        get_otrack_shadow_offset_wrk()
364948  Valgrind does not support the IBM POWER ISA 3.0 instructions, part 5/5
365273  Invalid write to stack location reported after signal handler runs
365912  ppc64BE segfault during jm-insns test (RELRO)
366079  FPXX Support for MIPS32 Valgrind
366138  Fix configure errors out when using Xcode 8 (clang 8.0.0)
366344  Multiple unhandled instruction for Aarch64
        (0x0EE0E020, 0x1AC15800, 0x4E284801, 0x5E040023, 0x5E056060)
367995  Integration of memcheck with custom memory allocator
368120  x86_linux asm _start functions do not keep 16-byte aligned stack pointer
368412  False positive result for altivec capability check
368416  Add tc06_two_races_xml.exp output for ppc64
368419  Perf Events ioctls not implemented
368461  mmapunmap test fails on ppc64
368823  run_a_thread_NORETURN assembly code typo for VGP_arm64_linux target
369000  AMD64 fma4 instructions unsupported.
369169  ppc64 fails jm_int_isa_2_07 test
369175  jm_vec_isa_2_07 test crashes on ppc64
369209  valgrind loops and eats up all memory if cwd doesn't exist.
369356  pre_mem_read_sockaddr syscall wrapper can crash with bad sockaddr
369359  msghdr_foreachfield can crash when handling bad iovec
369360  Bad sigprocmask old or new sets can crash valgrind
369361  vmsplice syscall wrapper crashes on bad iovec
369362  Bad sigaction arguments crash valgrind
369383  x86 sys_modify_ldt wrapper crashes on bad ptr
369402  Bad set/get_thread_area pointer crashes valgrind
369441  bad lvec argument crashes process_vm_readv/writev syscall wrappers
369446  valgrind crashes on unknown fcntl command
369439  S390x: Unhandled insns RISBLG/RISBHG and LDE/LDER
369468  Remove quadratic metapool algorithm using VG_(HT_remove_at_Iter)
370265  ISA 3.0 HW cap stuff needs updating
371128  BCD add and subtract instructions on Power BE in 32-bit mode do not work
n-i-bz  Fix incorrect (or infinite loop) unwind on RHEL7 x86 and amd64
n-i-bz  massif --pages-as-heap=yes does not report peak caused by mmap+munmap
n-i-bz  false positive leaks due to aspacemgr merging heap & non heap segments
n-i-bz  Fix ppoll_alarm exclusion on OS X
n-i-bz  Document brk segment limitation, reference manual in limit reached msg.
n-i-bz  Fix clobber list in none/tests/amd64/xacq_xrel.c [valgrind r15737]
n-i-bz  Bump allowed shift value for "add.w reg, sp, reg, lsl #N" [vex r3206]
n-i-bz  amd64: memcheck false positive with shr %edx
n-i-bz  arm3: Allow early writeback of SP base register in "strd rD, [sp, #-16]"
n-i-bz  ppc: Fix two cases of PPCAvFpOp vs PPCFpOp enum confusion
n-i-bz  arm: Fix incorrect register-number constraint check for LDAEX{,B,H,D}
n-i-bz  DHAT: added collection of the metric "tot-blocks-allocd"

(3.12.0.RC1:  20 October 2016, vex r3282, valgrind r16094)
(3.12.0.RC2:  20 October 2016, vex r3282, valgrind r16096)
(3.12.0:      21 October 2016, vex r3282, valgrind r16098)

Re: [Valgrind-users] can some one help me?

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

On Mon, 2016-10-24 at 12:50 +0800, p4759521 wrote:
> I want to check my program with valgrind, but my program nerver exit
> by self. so how to check the program memory leak?
> 

>From another shell, you can use vgdb to (a.o.) trigger a leak search.

For example, to output all detailed info about all blocks, do:
  vgdb leak kinds all any unlimited

Philippe

[Valgrind-users] can some one help me?

[p4759521 <p47...@16...>]

I want to check my program with valgrind, but my program nerver exit by self. so how to check the program memory leak?



p4759521

Re: [Valgrind-users] Sparc port status

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

2016-10-19 22:56 GMT+02:00 Ivo Raisr <iv...@iv...>:

>
>
> 2016-10-19 19:41 GMT+02:00 Rob Boehne <ro...@da...>:
>
>> Hello Ivo,
>>
>> I attempted a fresh hg checkout and build of valgrind-solaris, ran “bash
>> autogen.sh” ./configure CC=“gcc –m64” CXX=“g++ -m64” and gmake, but it died
>> down in VEX in assembly:
>>
>> gcc -m64 -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub
>> -I../VEX/pub -DVGA_sparcv9=1 -DVGO_solaris=1 -DVGP_sparcv9_solaris=1
>> -DVGPV_sparcv9_solaris_vanilla=1 -Ipriv  -m64 -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  -mcpu=niagara -Wbad-function-cast
>> -fstrict-aliasing  -MT priv/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.o
>> -MD -MP -MF priv/.deps/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.Tpo
>> -c -o priv/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.o `test
>> -f 'priv/guest_sparcv9_helpers_crypto.c' || echo
>> './'`priv/guest_sparcv9_helpers_crypto.c
>>
>> /usr/bin/as: "/var/tmp//ccyxaWLp.s", line 14: error: cannot use SPARC4
>> instructions in a non-SPARC4 target binary
>>
>> gmake[3]: *** [priv/libvex_sparcv9_solaris_a
>> -guest_sparcv9_helpers_crypto.o] Error 1
>>
>
> Hello Rob,
> I was able to reproduce this problem on Solaris 11.3, sparc T5 LDOM.
> Will fix this and keep you posted.
> I.
>

Hello Rob,

The problem should be fixed by this changeset:

changeset:   2013:a14134110f2d
user:        Ivo Raisr <iv...@iv...>
date:        Thu Oct 20 23:26:49 2016 +0000
files:       VEX/priv/guest_sparcv9_helpers_crypto.c
description: Do not use OSA2011 assembly instructions directly.
...

There is one additional build problem with one of the unit tests but it
does not prevent actually using Valgrind on sparcv9/Solaris.
I will fix it in a few days anyway.
Thank you for reporting this.
I.

Re: [Valgrind-users] Sparc port status

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

2016-10-19 19:41 GMT+02:00 Rob Boehne <ro...@da...>:

> Hello Ivo,
>
> I attempted a fresh hg checkout and build of valgrind-solaris, ran “bash
> autogen.sh” ./configure CC=“gcc –m64” CXX=“g++ -m64” and gmake, but it died
> down in VEX in assembly:
>
> gcc -m64 -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub
> -I../VEX/pub -DVGA_sparcv9=1 -DVGO_solaris=1 -DVGP_sparcv9_solaris=1
> -DVGPV_sparcv9_solaris_vanilla=1 -Ipriv  -m64 -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  -mcpu=niagara -Wbad-function-cast
> -fstrict-aliasing  -MT priv/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.o
> -MD -MP -MF priv/.deps/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.Tpo
> -c -o priv/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.o `test
> -f 'priv/guest_sparcv9_helpers_crypto.c' || echo './'`priv/guest_sparcv9_
> helpers_crypto.c
>
> /usr/bin/as: "/var/tmp//ccyxaWLp.s", line 14: error: cannot use SPARC4
> instructions in a non-SPARC4 target binary
>
> gmake[3]: *** [priv/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.o]
> Error 1
>

Hello Rob,
I was able to reproduce this problem on Solaris 11.3, sparc T5 LDOM.
Will fix this and keep you posted.
I.

Re: [Valgrind-users] Sparc port status

[Rob B. <ro...@da...>]

Hello Ivo,

I attempted a fresh hg checkout and build of valgrind-solaris, ran “bash autogen.sh” ./configure CC=“gcc –m64” CXX=“g++ -m64” and gmake, but it died down in VEX in assembly:


gcc -m64 -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub -I../VEX/pub -DVGA_sparcv9=1 -DVGO_solaris=1 -DVGP_sparcv9_solaris=1 -DVGPV_sparcv9_solaris_vanilla=1 -Ipriv  -m64 -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  -mcpu=niagara -Wbad-function-cast -fstrict-aliasing  -MT priv/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.o -MD -MP -MF priv/.deps/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.Tpo -c -o priv/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.o `test -f 'priv/guest_sparcv9_helpers_crypto.c' || echo './'`priv/guest_sparcv9_helpers_crypto.c

/usr/bin/as: "/var/tmp//ccyxaWLp.s", line 14: error: cannot use SPARC4 instructions in a non-SPARC4 target binary

gmake[3]: *** [priv/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.o] Error 1

gmake[3]: Leaving directory `/devlocal/robb/valgrind-solaris/VEX'

gmake[2]: *** [all] Error 2

gmake[2]: Leaving directory `/devlocal/robb/valgrind-solaris/VEX'

gmake[1]: *** [all-recursive] Error 1

gmake[1]: Leaving directory `/devlocal/robb/valgrind-solaris'

gmake: *** [all] Error 2

robb@mars:/devlocal/robb/valgrind-solaris$head config.log

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.12.0.SVN, which was

generated by GNU Autoconf 2.68.  Invocation command line was


  $ ./configure CC=gcc -m64 CXX=g++ -m64


## --------- ##

## Platform. ##

robb@mars:/devlocal/robb/valgrind-solaris$hg status

? VEX/priv/.deps/libvex_sparcv9_solaris_a-guest_sparcv9_helpers_crypto.Tpo

robb@mars:/devlocal/robb/valgrind-solaris$gcc -v

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/lto-wrapper

Target: sparc-sun-solaris2.11

Configured with: /export/home/hudson/workspace/nightly-update/build/sparc/components/gcc48/gcc-4.8.2/configure CC=/usr/gcc/4.7/bin/gcc CXX=/usr/gcc/4.7/bin/g++ --prefix=/usr/gcc/4.8 --mandir=/usr/gcc/4.8/share/man --bindir=/usr/gcc/4.8/bin --libdir=/usr/gcc/4.8/lib --sbindir=/usr/gcc/4.8/sbin --infodir=/usr/gcc/4.8/share/info --libexecdir=/usr/gcc/4.8/lib --enable-languages=c,c++,fortran,objc --enable-shared --with-gmp-include=/usr/include/gmp --with-mpfr-include=/usr/include/mpfr --without-gnu-ld --with-ld=/usr/bin/ld --without-gnu-as --with-as=/usr/bin/as CFLAGS='-g -O2  -mtune=ultrasparc -mcpu=ultrasparc -mno-unaligned-doubles' CXXFLAGS='-g -O2 -mtune=ultrasparc -mcpu=ultrasparc -mno-unaligned-doubles'

Thread model: posix

gcc version 4.8.2 (GCC)

robb@mars:/devlocal/robb/valgrind-solaris$which gcc

/usr/bin/gcc

robb@mars:/devlocal/robb/valgrind-solaris$uname -a

SunOS mars 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise

robb@mars:/devlocal/robb/valgrind-solaris$hg identify

8917905ab492 tip

robb@mars:/devlocal/robb/valgrind-solaris$hg update

0 files updated, 0 files merged, 0 files removed, 0 files unresolved

robb@mars:/devlocal/robb/valgrind-solaris$psrinfo -v

Status of virtual processor 32 as of: 10/19/2016 12:37:28

  on-line since 07/12/2016 20:49:09.

  The sparcv9 processor operates at 2400 MHz,

        and has a sparcv9 floating point processor.

Do I need some specific architecture or code generation flags to build on Solaris 11 / SPARC or the GNU assembler ?

Thanks,

Robert Boehne


From: Ivo Raisr <iv...@iv...<mailto:iv...@iv...>>
Date: Wednesday, July 27, 2016 at 1:08 PM
To: Rob Boehne <ro...@da...<mailto:ro...@da...>>
Cc: "val...@li...<mailto:val...@li...>" <val...@li...<mailto:val...@li...>>
Subject: Re: [Valgrind-users] Sparc port status



2016-07-26 15:53 GMT+02:00 Rob Boehne <ro...@da...<mailto:ro...@da...>>:
As I’ve found valgrind quite useful on x86/Linux for many years, I was very excited to see a project to support Solaris Sparc, and I’d love to have this available, as I maintain a large, old codebase with a pool allocator (Electric Fence doesn’t deal well with it, and isn’t useful for leak checking, or the other things valgrind can do).

Where can I find information on how to build, what versions of Solaris are supported on what hardware, and what works?

I’m happy to contribute to the effort as well.


Hello Robert,

Thank you for your interest in sparcv9/Solaris port.
The port currently lives here: https://bitbucket.org/iraisr/valgrind-solaris
and is also linked from http://valgrind.org/info/platforms.html
It is under active development and still far from complete.

As with x86+amd64/Solaris, we aim at Solaris 11 and illumos (or higher).
We have no intention to spend effort on Solaris 10 as this OS is now over 10 years old and will become unsupported soon.

With sparcv9/Solaris, we obviously target 64-bit programs. Area of 32-bit programs with sparcv8+ is quite murky.
We might add sparv8+ later, when sparcv9 is largely finished.
We aim to support all sparcv9 hardware, that is starting from T1 up to currently T7, ... and their M-series equivalents.
Currently we are implementing Oracle Sparc Architecture 2015 [1] features (which correspond to T7/M7).

For instructions how to build please follow README.solaris and generic README.
We actively develop on Solaris 12, and Solaris 11 should also work ok.

Any contributions are welcome. We maintain a list of issues:
https://bitbucket.org/iraisr/valgrind-solaris/issues?status=new&status=open
and you are free to take any. The main development work is now focused on fixing last few failing tests
under none/tests (only 10 failing out of 474 total) and then we will focus on enabling memcheck.

Happy Valgrind'ing!
I.

[1] http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/sparc-servers-documentation-163529.html

Re: [Valgrind-users] Spurious Assertion from valgrind

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

Eric,

>> Thanks for any insights or clues!
> 
> I believe this is https://bugs.kde.org/show_bug.cgi?id=356457
> Sadly it is not well understood. If you could add any information to
> that bug that could help us understand better when this issue triggers
> that would be very helpful. There are some hints in that bug report how
> to get more information if possible.

To second Mark's comments -- yes -- please do add your observations
(all the information in your original email) to
https://bugs.kde.org/show_bug.cgi?id=356457

This is a difficult bug which we've been aware of for some time but have
no way to reproduce, hence no way to fix.  If you add your comments to
356457, then it may be that, if enough people do the same, we can see some
pattern or similarities between the crashes, and so make some progress.

That would be very helpful.

J

Re: [Valgrind-users] Spurious Assertion from valgrind

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

On Wed, 2016-10-19 at 09:29 -0400, Eric Chamberland wrote:
> I recently upgraded to valgrind 3.11.0 (was 3.8.1 before).
> I also upgraded Intel MKL to the 2015 version.
> 
> We use valgrind since 2011-10-27 to test our code nightly with about 
> 2200 tests.
> 
> Since this upgrade, some tests (not always the same) have the same 
> trouble (see full log in attachment):
> 
> ================================
> ...
> blockSane: fail -- redzone-hi
> 
> valgrind: m_mallocfree.c:2042 (vgPlain_arena_free): Assertion 
> 'blockSane(a, b)' failed.
> 
> host stacktrace:
> ...
> 
> ================================
> 
> I would like some help to debug this.
> 
> It is quite annoying since for the same test, the problem appear or 
> disappear from one day over another...
> 
> Today we got the problem on 6 tests (on 2200), yesterday, only 1 test 
> failed, before yesterday, none failed....
> 
> Thanks for any insights or clues!

I believe this is https://bugs.kde.org/show_bug.cgi?id=356457
Sadly it is not well understood. If you could add any information to
that bug that could help us understand better when this issue triggers
that would be very helpful. There are some hints in that bug report how
to get more information if possible.

Thanks,

Mark