valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Spurious Assertion from valgrind

[Eric C. <Eri...@gi...>]

Hi,

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!

Eric

[Valgrind-users] Call for Participation: Valgrind at FOSDEM 2017

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

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

- Tuning Valgrind for large workloads (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 Ivos 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/

Re: [Valgrind-users] -m32

[Shiva <shi...@gm...>]

Hi Tom,
I am using 3.11.0 version under Ubuntu machine.

I used the following steps to build and install as metioned in the valgrind
website.

  cd valgrind
  ./autogen.sh
  ./configure --prefix=...
  make
  make install


Regards,

Shiva


On Fri, Oct 14, 2016 at 10:45 PM, paulf [via Valgrind] <
ml-...@n7...> wrote:

> Shiva wrote:
>
> > Hi Tom,
> > I am trying to run valgrind on my executable which is of 32-bit. I am
> > getting the following error:
> > valgrind  <executable>
> > valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
> > valgrind: <executable>: cannot execute binary file
> >
> > Couple of other logs which are useful:
> >
> > file <executable>
> > <executable>: ELF 32-bit MSB  executable, PowerPC or cisco 4500, version
> 1
> > (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16,
> > BuildID[sha1]=570302117aa12728043bc5263352ce95f637db35, not stripped
> >
> > valgrind -d <executable>
> > --6455:1:debuglog DebugLog system started by Stage 1, level 1 logging
> > requested
> > --6455:1:launcher no tool requested, defaulting to 'memcheck'
> > --6455:1:launcher no platform detected, defaulting platform to
> 'amd64-linux'
> > --6455:1:launcher launching <path>/memcheck-amd64-linux
> > --6455:1:debuglog DebugLog system started by Stage 2 (main), level 1
> logging
> > requested
> >
> > Looks like valgrind launcher is automatically starts 64bit execution,
> and
> > hence throwing the above error.
> > Is there a way I can run valgrind for my 32-bit image? However valgrind
> > executable are built to support both 32-bit and 64 bit version.
> > Thanks,
> > Shivakumar
> >
>
> Hi Shiva
>
> Which version of Valgrind are you using? And which OS and platform?
>
> Did you install it with your package manager or build it from source?
>
> Regards
> Paul
>
>
> ------------------------------------------------------------------------------
>
> 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
> [hidden email] <http:///user/SendEmail.jtp?type=node&node=56884&i=0>
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://valgrind.10908.n7.nabble.com/m32-tp36165p56884.html
> To unsubscribe from -m32, click here
> <http://valgrind.10908.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=36165&code=c2hpdmFrdW1hcmcubXNnQGdtYWlsLmNvbXwzNjE2NXwtNjE4NTI2MTA2>
> .
> NAML
> <http://valgrind.10908.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://valgrind.10908.n7.nabble.com/m32-tp36165p56889.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] -m32

[Paul F. <pa...@fr...>]

Shiva wrote:
> Hi Tom,
> I am trying to run valgrind on my executable which is of 32-bit. I am
> getting the following error:
> valgrind  <executable>
> valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
> valgrind: <executable>: cannot execute binary file
>
> Couple of other logs which are useful:
>
> file <executable>
> <executable>: ELF 32-bit MSB  executable, PowerPC or cisco 4500, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16,
> BuildID[sha1]=570302117aa12728043bc5263352ce95f637db35, not stripped
>
> valgrind -d <executable>
> --6455:1:debuglog DebugLog system started by Stage 1, level 1 logging
> requested
> --6455:1:launcher no tool requested, defaulting to 'memcheck'
> --6455:1:launcher no platform detected, defaulting platform to 'amd64-linux'
> --6455:1:launcher launching <path>/memcheck-amd64-linux
> --6455:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging
> requested
>
> Looks like valgrind launcher is automatically starts 64bit execution, and
> hence throwing the above error.
> Is there a way I can run valgrind for my 32-bit image? However valgrind
> executable are built to support both 32-bit and 64 bit version.
> Thanks,
> Shivakumar
>

Hi Shiva

Which version of Valgrind are you using? And which OS and platform?

Did you install it with your package manager or build it from source?

Regards
Paul

Re: [Valgrind-users] -m32

[Shiva <shi...@gm...>]

Hi Tom,
I am trying to run valgrind on my executable which is of 32-bit. I am
getting the following error:
valgrind  <executable>
valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
valgrind: <executable>: cannot execute binary file

Couple of other logs which are useful:
 
file <executable>
<executable>: ELF 32-bit MSB  executable, PowerPC or cisco 4500, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16,
BuildID[sha1]=570302117aa12728043bc5263352ce95f637db35, not stripped
 
valgrind -d <executable>
--6455:1:debuglog DebugLog system started by Stage 1, level 1 logging
requested
--6455:1:launcher no tool requested, defaulting to 'memcheck'
--6455:1:launcher no platform detected, defaulting platform to 'amd64-linux'
--6455:1:launcher launching <path>/memcheck-amd64-linux
--6455:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging
requested

Looks like valgrind launcher is automatically starts 64bit execution, and
hence throwing the above error.
Is there a way I can run valgrind for my 32-bit image? However valgrind
executable are built to support both 32-bit and 64 bit version.
Thanks,
Shivakumar



--
View this message in context: http://valgrind.10908.n7.nabble.com/m32-tp36165p56883.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

[Valgrind-users] (no subject)

[Shivakumar G <shi...@gm...>]

Hi,
I am trying to run valgrind on my executable which is of 32-bit. I am
getting the following error:

*valgrind  <executable>*

valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)

valgrind: <executable>: cannot execute binary file


Couple of other logs which are useful:



*file <executable>*

<executable>: ELF 32-bit MSB  executable, PowerPC or cisco 4500, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16,
BuildID[sha1]=570302117aa12728043bc5263352ce95f637db35, not stripped



*valgrind -d <executable>*

--6455:1:debuglog DebugLog system started by Stage 1, level 1 logging
requested

--6455:1:launcher no tool requested, defaulting to 'memcheck'

--6455:1:launcher no platform detected, defaulting platform to 'amd64-linux'

--6455:1:launcher launching <path>/memcheck-amd64-linux

--6455:1:debuglog DebugLog system started by Stage 2 (main), level 1
logging requested


Looks like valgrind launcher is automatically start 64bit execution, and
hence throwing the above error.

Is there a way I can run valgrind for my 32-bit image? However valgrind
executable are built to support both 32-bit and 64 bit version.


Regards,

Shivakumar

Re: [Valgrind-users] helgrind, PTHREAD_RWLOCK_INITIALIZER and pthread_rwlock_destroy

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

2016-10-06 22:27 GMT+02:00 Patrick J. LoPresti <lop...@gm...>:

> On Thu, Oct 6, 2016 at 8:53 AM, Alex Bligh <al...@al...> wrote:
> >
> >
> > > On 6 Oct 2016, at 16:06, Mateusz Jemielity <
> m.j...@is...> wrote:
> > >
> > > The effects are equivalent to pthread_rwlock_init, thus in my opinion
> they
> > > require pthread_rwlock_destroy.
> >
> > However, I'm not sure why you'd need to call pthread_*_destroy on a
> statically
> > initialised object, given that presumably you destroy it when the program
> > is about to exit and the resources would be given back to the OS anyway.
>
> In this example it is in main(), but there is no reason the same sequence
> could not appear in the middle of a long-running program, in which case
> failing to call pthread_rwlock_destroy() could potentially leak resources.
>
> I agree with Mateusz. POSIX clearly requires a call to
> pthread_rwlock_destroy() on RW locks initialized via PTHREAD_RW_INITIALIZER
> to ensure proper freeing of resources.
>

Indeed, POSIX [1] explicitly says that PTHREAD_RWLOCK_INITIALIZER shall be
equivalent to dynamic initialization by a call to pthread_rwlock_init().
However our tools (DRD, Helgrind) cannot detect such implicitly initialized
primitive easily. Simply because there is no pthread_rwlock_init() called
for them.
For example on Solaris, PTHREAD_RWLOCK_INITIALIZER is a macro which expands
to pthread_rwlock_t with all fields set as if pthread_rwlock_init() was
called instead.
I don't see an efficient way how to fix such false positives.

I.

[1]
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_destroy.html

Re: [Valgrind-users] helgrind, PTHREAD_RWLOCK_INITIALIZER and pthread_rwlock_destroy

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

On Thu, Oct 6, 2016 at 8:53 AM, Alex Bligh <al...@al...> wrote:
>
>
> > On 6 Oct 2016, at 16:06, Mateusz Jemielity <m.j...@is...>
wrote:
> >
> > The effects are equivalent to pthread_rwlock_init, thus in my opinion
they
> > require pthread_rwlock_destroy.
>
> However, I'm not sure why you'd need to call pthread_*_destroy on a
statically
> initialised object, given that presumably you destroy it when the program
> is about to exit and the resources would be given back to the OS anyway.

In this example it is in main(), but there is no reason the same sequence
could not appear in the middle of a long-running program, in which case
failing to call pthread_rwlock_destroy() could potentially leak resources.

I agree with Mateusz. POSIX clearly requires a call to
pthread_rwlock_destroy() on RW locks initialized via PTHREAD_RW_INITIALIZER
to ensure proper freeing of resources.

 - Pat

Re: [Valgrind-users] helgrind, PTHREAD_RWLOCK_INITIALIZER and pthread_rwlock_destroy

[Alex B. <al...@al...>]

> On 6 Oct 2016, at 16:06, Mateusz Jemielity <m.j...@is...> wrote:
> 
> The effects are equivalent to pthread_rwlock_init, thus in my opinion they
> require pthread_rwlock_destroy. The internals of rwlock are opaque to me and
> I don't know what resources are used (especially on different systems and
> implementations), so I should cleanly free them just in case.
> I know it's not common usecase to do something like that. In my scenario I
> want to replace rwlock created using static initializer with another one
> that uses custom attributes.

I can't say I've used pthread_rwlock_* much but I've used pthread_mutex_*
before which has the same init/destroy/static initializer trio and that seemed
right.

However, I'm not sure why you'd need to call pthread_*_destroy on a statically
initialised object, given that presumably you destroy it when the program
is about to exit and the resources would be given back to the OS anyway.

-- 
Alex Bligh

Re: [Valgrind-users] helgrind, PTHREAD_RWLOCK_INITIALIZER and pthread_rwlock_destroy

[Mateusz J. <m.j...@is...>]

>> On 6 Oct 2016, at 13:43, Mateusz Jemielity <m.j...@is...>
wrote:
>> 
>> I'm using valgrind built from SVN, r16025. I encountered helgrind 
>> complaining about invalid argument used with pthread_rwlock_destroy, 
>> for variable initialized with PTHREAD_RWLOCK_INITIALIZER. Is this a known
thing?
>> Am I doing something wrong? I searched the mailing list archives on 
>> https://sourceforge.net/p/valgrind/mailman/valgrind-users/, but 
>> couldn't find anything. I'm asking because I think pthreads allows me 
>> to destroy rwlock initialized that way.
>> 
>> I reproduced this with minimal test case on Ubuntu 14.04:
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID:IDUbuntu
>> Description:DescriptionUbuntu 14.04.5 LTS
>> Release:Release14.04
>> Codename:Codenametrusty
>> $ cat pthread_rwlock_destroy.c
>> # define _POSIX_C_SOURCE 20161006L
>> 
>> #include <assert.h>
>> #include <pthread.h>
>> 
>> int main(void)
>> {
>>  pthread_rwlock_t l = PTHREAD_RWLOCK_INITIALIZER;
>>  assert(0 == pthread_rwlock_destroy(&l));  return 0; }
>
>According to the man page:
>
>> The pthread_rwlock_destroy() function is used to destroy a read/write
lock previously created with pthread_rwlock_init().
>
>You did not create the lock with pthread_rwload_init() - you used a static
initialisation. Therefore my understanding is that you do not need to (and
should not) call pthread_rwlock_destroy().
>
>--
>Alex Bligh
>
Docs at
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_des
troy.html say:

In cases where default read-write lock attributes are appropriate, the macro
PTHREAD_RWLOCK_INITIALIZER can be used to initialize read-write locks. The
effect shall be equivalent to dynamic initialization by a call to
pthread_rwlock_init() with the attr parameter specified as NULL, except that
no error checks are performed.


The effects are equivalent to pthread_rwlock_init, thus in my opinion they
require pthread_rwlock_destroy. The internals of rwlock are opaque to me and
I don't know what resources are used (especially on different systems and
implementations), so I should cleanly free them just in case.
I know it's not common usecase to do something like that. In my scenario I
want to replace rwlock created using static initializer with another one
that uses custom attributes.

- Mateusz

Re: [Valgrind-users] helgrind, PTHREAD_RWLOCK_INITIALIZER and pthread_rwlock_destroy

[Alex B. <al...@al...>]

> On 6 Oct 2016, at 13:43, Mateusz Jemielity <m.j...@is...> wrote:
> 
> I'm using valgrind built from SVN, r16025. I encountered helgrind
> complaining about invalid argument used with pthread_rwlock_destroy, for
> variable initialized with PTHREAD_RWLOCK_INITIALIZER. Is this a known thing?
> Am I doing something wrong? I searched the mailing list archives on
> https://sourceforge.net/p/valgrind/mailman/valgrind-users/, but couldn't
> find anything. I'm asking because I think pthreads allows me to destroy
> rwlock initialized that way.
> 
> I reproduced this with minimal test case on Ubuntu 14.04:
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID:	Ubuntu
> Description:	Ubuntu 14.04.5 LTS
> Release:	14.04
> Codename:	trusty
> $ cat pthread_rwlock_destroy.c 
> # define _POSIX_C_SOURCE 20161006L
> 
> #include <assert.h>
> #include <pthread.h>
> 
> int main(void)
> {
>  pthread_rwlock_t l = PTHREAD_RWLOCK_INITIALIZER;
>  assert(0 == pthread_rwlock_destroy(&l));
>  return 0;
> }

According to the man page:

> The pthread_rwlock_destroy() function is used to destroy a read/write lock previously created with pthread_rwlock_init().

You did not create the lock with pthread_rwload_init() - you used a static initialisation. Therefore my understanding is that you do not need to (and should not) call pthread_rwlock_destroy().

-- 
Alex Bligh

[Valgrind-users] helgrind, PTHREAD_RWLOCK_INITIALIZER and pthread_rwlock_destroy

[Mateusz J. <m.j...@is...>]

Hello,

I'm using valgrind built from SVN, r16025. I encountered helgrind
complaining about invalid argument used with pthread_rwlock_destroy, for
variable initialized with PTHREAD_RWLOCK_INITIALIZER. Is this a known thing?
Am I doing something wrong? I searched the mailing list archives on
https://sourceforge.net/p/valgrind/mailman/valgrind-users/, but couldn't
find anything. I'm asking because I think pthreads allows me to destroy
rwlock initialized that way.

I reproduced this with minimal test case on Ubuntu 14.04:
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.5 LTS
Release:	14.04
Codename:	trusty
$ cat pthread_rwlock_destroy.c 
# define _POSIX_C_SOURCE 20161006L

#include <assert.h>
#include <pthread.h>

int main(void)
{
  pthread_rwlock_t l = PTHREAD_RWLOCK_INITIALIZER;
  assert(0 == pthread_rwlock_destroy(&l));
  return 0;
}
$ gcc -Wall -Wextra -std=c99 -pedantic -O0 -ggdb pthread_rwlock_destroy.c
-pthread
$ valgrind --tool=helgrind ./a.out
==4199== Helgrind, a thread error detector
==4199== Copyright (C) 2007-2015, and GNU GPL'd, by OpenWorks LLP et al.
==4199== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
info
==4199== Command: ./a.out
==4199== 
==4199== ---Thread-Announcement------------------------------------------
==4199== 
==4199== Thread #1 is the program's root thread
==4199== 
==4199== ----------------------------------------------------------------
==4199== 
==4199== Thread #1: pthread_rwlock_destroy with invalid argument
==4199==    at 0x4C302D6: pthread_rwlock_destroy_WRK (hg_intercepts.c:2096)
==4199==    by 0x4C33018: pthread_rwlock_destroy (hg_intercepts.c:2113)
==4199==    by 0x400707: main (pthread_rwlock_destroy.c:9)
==4199== 
==4199== 
==4199== For counts of detected and suppressed errors, rerun with: -v
==4199== Use --history-level=approx or =none to gain increased speed, at
==4199== the cost of reduced accuracy of conflicting-access information
==4199== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Regards,
Mateusz

Re: [Valgrind-users] Valgrind Massif Nginx

[Joël K. <jkr...@gm...>]

Hi

May be you are interested in remote debugging:

http://valgrind.org/docs/manual/manual-core-adv.html

bests,
Joël


On Mon, Oct 3, 2016 at 11:01 AM, Muhui Jiang <jia...@gm...> wrote:

> Hi
>
> I hope this this the right mailing list for technical support.
>
> Recently, I tried to use Valgrind to analysis the popular server. I use
> the tool massif in valgrind to try to analysis the heap allocation inside
> Nginx. I use the command
>
> valgrind --tool=massif /path/to/nginx
>
> to start the massif. I noticed that massif will only profile the memory
> information for starting up nginx. I want massif to profile the related
> heap information when I make request to the servers. Does anyone have any
> ideas or comments on this? Many Thanks
>
> Regards
> Muhui
>
> ------------------------------------------------------------
> ------------------
> 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
>
>

[Valgrind-users] Valgrind Massif Nginx

[Muhui J. <jia...@gm...>]

Hi

I hope this this the right mailing list for technical support.

Recently, I tried to use Valgrind to analysis the popular server. I use the
tool massif in valgrind to try to analysis the heap allocation inside
Nginx. I use the command

valgrind --tool=massif /path/to/nginx

to start the massif. I noticed that massif will only profile the memory
information for starting up nginx. I want massif to profile the related
heap information when I make request to the servers. Does anyone have any
ideas or comments on this? Many Thanks

Regards
Muhui

Re: [Valgrind-users] Using Massif to find space leaks

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

On 16/09/16 17:37, Nicholas Lamb wrote:

> I suppose the advantage of Massif is that it reveals the breakdown
> of heap memory distribution, so you can know how much memory is taken
> by accessible but unreleased blocks. I'm using a variant of the Eclipse
> IDE that provides good visualization of Massif's output, so I guess it's
> just a matter of examining the detailed snapshots to find memory blocks
> that account for a large portion of overall used memory but haven't
> been used for a while.

You can get yet another kind of insight into your heap behaviour using
the exp-dhat tool.  This observes both heap blocks and the memory accesses
made to them, and so can tell you

* places where blocks are allocated and freed very soon afterwards --
  possible inefficiency -- maybe that data could be stack-allocated
  instead?

* blocks which are allocated and later freed but remain partially or
  entirely unused, or under-used.  From this information you can find
  sometimes surprising facts like (for example) "50% of our hash tables
  never have any entries in them", etc.

J

Re: [Valgrind-users] Valgrind can't find strcmp in ld.so

[Kirill F. <kir...@de...>]

On 09/22/2016 06:53 PM, Mikhail Baikov wrote:
> valgrind:  A must-be-redirected function
> valgrind:  whose name matches the pattern:      strcmp
> valgrind:  in an object with soname matching: ld-linux-armhf.so.3
> valgrind:  was not found whilst processing
> valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
    Look at coregrind/m_redir.c:1364

    /* If we're using memcheck, use these intercepts right from the
       start, otherwise ld.so makes a lot of noise.  In most ARM-linux
       distros, ld.so's soname is ld-linux.so.3, but Ubuntu 14.04 on
       Odroid uses ld-linux-armhf.so.3 for some reason. */

    ...

       /* strcmp */
       add_hardwired_spec(
          "ld-linux.so.3", "strcmp",
          (Addr)&VG_(arm_linux_REDIR_FOR_strcmp),
          complain_about_stripped_glibc_ldso
       );


   I think, on some machines running linux strcmp() function resides in 
ld-linux.so. But look on same for x86: just NULL passed to 
add_hardwired_spec() function. I think, you need to do the same.

[Valgrind-users] Valgrind can't find strcmp in ld.so

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

Hello.

I need some help. I want to start valgrind but get this error.

# /mnt/nfs/bin/valgrind/bin/valgrind ls
==933== Memcheck, a memory error detector
==933== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==933== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==933== Command: ls
==933==

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strcmp
valgrind:  in an object with soname matching: ld-linux-armhf.so.3
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-armhf.so.3

libc.so and ld.so aren't stripped

$ file ld-2.18-2013.10.so
ld-2.18-2013.10.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 
(SYSV), dynamically linked, not stripped
$ file libc-2.18-2013.10.so
libc-2.18-2013.10.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 
(SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for 
GNU/Linux 2.6.16, not stripped

And I do not see any mentions about strcmp in ld.so but I see it libc.so

# readelf -a /lib/libc.so.6 | grep strcmp
   2069: 00059bf1    22 FUNC    GLOBAL DEFAULT   12 strcmp@@GLIBC_2.4
# readelf -a /lib/ld-linux-armhf.so.3 | grep strcmp


How can I make valgrind work?

-- 
Sincerely
Mihail Baikov

Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry

[Knapp, R. L <ras...@in...>]

Hello,



Some of these may have been mentioned previously.

I find the following Intel published AVX-512 documents:

1. Combined Volume Set of Intel® 64 and IA-32 Architectures Software Developer’s Manuals, from http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html :

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf  -- Volume 2, chapter 2

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developers-manual.pdf  -- update/errata to above

2.  Intel® Architecture Instruction Set Extensions Programming Reference: https://software.intel.com/sites/default/files/managed/69/78/319433-025.pdf



In addition to the above, the Knights Landing manuals are:

‐    Intel® Xeon Phi™ Processor, Performance Monitoring Reference Manual – Volume 1: Registers, Revision 1.0, June 2016: https://software.intel.com/sites/default/files/managed/28/16/Intel%C2%AEXeonPhi%E2%84%A2ProcessorPerformanceMonitoringReferenceManual_Volume1_Register_rev1.0_Jun2016..pdf

‐    Intel® Xeon Phi™ Processor Performance Monitoring Reference Manual—Volume 2:  Events, Revision 1.0, June 2016: https://software.intel.com/sites/default/files/managed/db/9d/Intel%20Xeon%20Phi%E2%84%A2%20Processor%20Performance%20Monitoring%20Reference%20Manual_Vol2_rev1.0_Jun2016.pdf



Regards,



Rashawn Knapp

Software Development Engineer, Intel Corporation



-----Original Message-----
From: Mark Wielaard [mailto:mj...@re...]
Sent: Thursday, September 22, 2016 5:36 AM
To: js...@ac...
Cc: Knapp, Rashawn L <ras...@in...>; Petar Jovanovic <mip...@gm...>; val...@li...; val...@li...
Subject: Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry



On Wed, 2016-09-07 at 10:23 +0200, Julian Seward wrote:

> A good description of the instruction set is also necessary.  Is that

> publically available?



It seems Intel moves it around from time to time, because my old bookmarks don't work anymore. But I found a recent description of

avx-512 at

https://software.intel.com/sites/default/files/managed/69/78/319433-025.pdf

Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry

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

On Wed, 2016-09-07 at 10:23 +0200, Julian Seward wrote:
> A good description of the instruction set is also necessary.  Is that
> publically available?

It seems Intel moves it around from time to time, because my old
bookmarks don't work anymore. But I found a recent description of
avx-512 at 
https://software.intel.com/sites/default/files/managed/69/78/319433-025.pdf

Re: [Valgrind-users] Using Massif to find space leaks

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

On Fri, 2016-09-16 at 15:37 +0000, Nicholas Lamb wrote:
> I think Memcheck actually can say something about accessible but unreleased blocks, but by default it doesn't. 
> The show-leak-kinds option, according to the Valgrind manual, can contain the 'reachable' value. In this case, 
> Memcheck reports blocks that could have been freed but weren't.
Yes, this is correct : memcheck --show-leak-kinds=... option can show
the allocated not (yet) released memory. To find (small) increase of
reachable memory (e.g. in regression tests), you can even do a 
'delta leak search' showing the difference with the memory state at the
previous leak search.


> I suppose the advantage of Massif is that it reveals the breakdown of heap memory distribution,
>  so you can know how much memory is taken by accessible but unreleased blocks. I'm using a
>  variant of the Eclipse IDE that provides good visualization of Massif's output, so I guess
>  it's just a matter of examining the detailed snapshots to find memory blocks that account
>  for a large portion of overall used memory but haven't been used for a while.
Effectively, the main differences between massif and memcheck leak
search are:
  * massif reports the memory use in a 'tree like layout' which
   gives a better visualisation that the memcheck 'flat report' given
   per allocation stack trace. 
  * massif makes reports at regular interval to show memory usage
    evolution, and shows the peak usage.
  * memcheck delta leak search is more precise to detect small
    increase.

Note that I am busy adding an 'execution tree' module
   pub_tool_xtree.h
that generalises the way massif records and present 'numbers'.
The idea is that such an xtree can be used by various tools
(a.o. memcheck and massif). Various output format will be available
for an xtree (callgrind format, massif format, ..).

memcheck can already produce a 
'kcachegrind/callgrind memory status'.
I have just started implementing the massif output format.

I will then change massif to use this module rather than its
current 'Xpt'.
After that, probably that all tools that are tracking malloc/free
(memcheck, helgrind, ...) will be able to produce massif like
memory reports with very little additional code.

This is all (evening) work in progress, estimate time of arrival
unknown :) 

Philippe

Re: [Valgrind-users] Using Massif to find space leaks

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

I think Memcheck actually can say something about accessible but unreleased blocks, but by default it doesn't. The show-leak-kinds option, according to the Valgrind manual, can contain the 'reachable' value. In this case, Memcheck reports blocks that could have been freed but weren't.

But I guess it depends on what you mean by "only freed at the end". If you mean there's an explicit call to free() or delete, then Memcheck obviously wouldn't report these blocks. If you mean the programmer makes no such call, knowing that the OS cleans up the memory when the program exits, these blocks would qualify as 'reachable' leaks.

I suppose the advantage of Massif is that it reveals the breakdown of heap memory distribution, so you can know how much memory is taken by accessible but unreleased blocks. I'm using a variant of the Eclipse IDE that provides good visualization of Massif's output, so I guess it's just a matter of examining the detailed snapshots to find memory blocks that account for a large portion of overall used memory but haven't been used for a while.

- Nicholas.

-----Original Message-----
From: Julian Seward [mailto:js...@ac...] 
Sent: Friday, September 16, 2016 4:35 AM
To: Nicholas Lamb <nl...@bl...>; val...@li...
Subject: Re: [Valgrind-users] Using Massif to find space leaks


This is all a bit cryptic, but what it means is: Memcheck will tell you about leaks where all pointers to a block are lost, so it can never be freed.  But it doesn't say anything about a different kind of leak, in which blocks are continuously allocated over the lifetime of the program, but only ever freed at the end.  So memory use ramps up forever despite the fact that in the end, all memory is freed.

Massif can tell you about these leaks, because they show up as ever- increasing residency from some specific allocation point.

Try using Milian Wolff's excellent massif-visualizer GUI.  That makes it very easy to examine the output of Massif in detail and find such leaks.
At least on Fedora 23 you can ask the package manager to install it.
I'm guessing here, but I suspect you can take the Massif output from a run such as on a phone, move it to a host machine, and view with massif-visualizer there.

J


On 15/09/16 21:40, Nicholas Lamb wrote:
> In the Valgrind User Manual, the Massif chapter mentions:
> "certain space leaks ... aren't detected by traditional leak-checkers, such as Memcheck's.
> That's because the memory isn't ever actually lost -- a pointer 
> remains to
it --
> but it's not in use. ... Massif can help identify these leaks."
> 
> The sample program and output graph sections explain how to visually 
> interpret the output after it's run through ms_print, as well as the 
> concepts of detailed and heap snapshots, but there isn't any example 
> given of finding space leaks.
> What are the high-level steps for doing so? Would users examine the 
> detailed snapshots and analyze the breakdown of memory consumption in 
> specific
functions
> to find references that haven't been used in a while?

Re: [Valgrind-users] Using Massif to find space leaks

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

This is all a bit cryptic, but what it means is: Memcheck will tell you
about leaks where all pointers to a block are lost, so it can never be
freed.  But it doesn't say anything about a different kind of leak, in
which blocks are continuously allocated over the lifetime of the program,
but only ever freed at the end.  So memory use ramps up forever despite
the fact that in the end, all memory is freed.

Massif can tell you about these leaks, because they show up as ever-
increasing residency from some specific allocation point.

Try using Milian Wolff's excellent massif-visualizer GUI.  That makes it
very easy to examine the output of Massif in detail and find such leaks.
At least on Fedora 23 you can ask the package manager to install it.
I'm guessing here, but I suspect you can take the Massif output from a
run such as on a phone, move it to a host machine, and view with
massif-visualizer there.

J


On 15/09/16 21:40, Nicholas Lamb wrote:
> In the Valgrind User Manual, the Massif chapter mentions:
> "certain space leaks ... aren't detected by traditional leak-checkers, such as Memcheck's.
> That's because the memory isn't ever actually lost -- a pointer remains to
it --
> but it's not in use. ... Massif can help identify these leaks."
> 
> The sample program and output graph sections explain how to visually interpret
> the output after it's run through ms_print, as well as the concepts of
> detailed
> and heap snapshots, but there isn't any example given of finding space leaks.
> What are the high-level steps for doing so? Would users examine the detailed
> snapshots and analyze the breakdown of memory consumption in specific
functions
> to find references that haven't been used in a while?

Re: [Valgrind-users] Using Massif to find space leaks

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

In the Valgrind User Manual, the Massif chapter mentions:
"certain space leaks ... aren't detected by traditional leak-checkers, such as Memcheck's. That's because the memory isn't ever actually lost -- a pointer remains to it -- but it's not in use. ... Massif can help identify these leaks."

The sample program and output graph sections explain how to visually interpret the output after it's run through ms_print, as well as the concepts of detailed and heap snapshots, but there isn't any example given of finding space leaks. What are the high-level steps for doing so? Would users examine the detailed snapshots and analyze the breakdown of memory consumption in specific functions to find references that haven't been used in a while?

Thanks,

Nicholas,
QNX Software Systems Ltd.

Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry

[Knapp, R. L <ras...@in...>]

Hi all,

I am working on this idea. I will let you know more when I have more information.

Regards,

-Rashawn

-----Original Message-----
From: Jeffrey Walton [mailto:nol...@gm...] 
Sent: Wednesday, September 07, 2016 1:09 PM
To: Philippe Waroquiers <phi...@sk...>
Cc: val...@li...; js...@ac...; Petar Jovanovic <mip...@gm...>; val...@li...
Subject: Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry

>> Can you make available, reliable, administrative-hassle-free remote 
>> access to a box that supports AVX-512?
> Assuming there is an access to an AVX512 box, I can take in charge the 
> updates needed for valgrind gdbserver.
>
> Note that one admin hassle free way to provide such a box is for intel 
> to donate such a box to gcc compile farm (and maybe even better, to 
> host it).

+1. I was thinking the same thing - host a farm or donate a couple of
machines to the GCC compile farm.

Jeff

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

Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry

[Jeffrey W. <nol...@gm...>]

>> Can you make available, reliable, administrative-hassle-free
>> remote access to a box that supports AVX-512?
> Assuming there is an access to an AVX512 box, I can take in charge
> the updates needed for valgrind gdbserver.
>
> Note that one admin hassle free way to provide such a box is
> for intel to donate such a box to gcc compile farm (and maybe even
> better, to host it).

+1. I was thinking the same thing - host a farm or donate a couple of
machines to the GCC compile farm.

Jeff