valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] massif problem - Unknown option: --undef-value-errors=no

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

On Sat, 2019-02-16 at 18:08 +0200, / wrote:
> My mistake, you are right, I had aliased valgrind to use 
> --undef-value-errors=no
> 
> thanks for your help and sorry for wasting your time.
No problem.

BTW, the 'tool prefix' for arguments (e.g. --memcheck:undef-value-errors=no)
was designed so that you can do such alias, but in a way that will work
with whatever tool.

Philippe

Re: [Valgrind-users] massif problem - Unknown option: --undef-value-errors=no

[/ <is...@ya...>]

My mistake, you are right, I had aliased valgrind to use 
--undef-value-errors=no

thanks for your help and sorry for wasting your time.

andreas

On 16/02/19 17:55, Philippe Waroquiers wrote:
> On Sat, 2019-02-16 at 17:49 +0200, / via Valgrind-users wrote:
>> valgrind: Unknown option: --undef-value-errors=no
>> valgrind: Use --help for more information or consult the user manual.
> 
> valgrind --help indicates:
>   ...
>   Extra options read from ~/.valgrindrc, $VALGRIND_OPTS, ./.valgrindrc
> 
> So, I guess that you have this option --undef-value-errors=no in one of the above.
> 
> Philippe
> 

Re: [Valgrind-users] massif problem - Unknown option: --undef-value-errors=no

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

On Sat, 2019-02-16 at 17:49 +0200, / via Valgrind-users wrote:
> valgrind: Unknown option: --undef-value-errors=no
> valgrind: Use --help for more information or consult the user manual.

valgrind --help indicates:
 ...
 Extra options read from ~/.valgrindrc, $VALGRIND_OPTS, ./.valgrindrc

So, I guess that you have this option --undef-value-errors=no in one of the above.

Philippe

Re: [Valgrind-users] massif problem - Unknown option: --undef-value-errors=no

[/ <is...@ya...>]

Thanks for your reply,


On 16/02/19 17:08, Philippe Waroquiers wrote:
> --undef-value-errors is not a massif option, it is a memcheck option.
I haven't specified that option at all! I don't know where it gets it 
from. All I want is to get a memory profile of my program and the net 
all over points to

    valgrind --tool=massif executable

that's all.

> 
> So, it is completely normal that massif reports that this is an
> unknown option.
> 
> If you want to have the list of options massif understands,
> you have to do:
>    valgrind --tool=massif --help
> 
> If you do not specify a tool, then valgrind defaults to memcheck.
> 
> Note that you can also prefix options with the tool they are
> aimed at.
> So, e.g.
>    valgrind --tool=massif --memcheck:undef-value-errors=no executable
> does not complain.
sorry but that fails with same error in my system

valgrind: Unknown option: --undef-value-errors=no
valgrind: Use --help for more information or consult the user manual.


> 
> Philippe
> 
> On Sat, 2019-02-16 at 15:20 +0200, / via Valgrind-users wrote:
>> Hi people, I get the following error when I try to invoke "massif" in
>> the most simple manner:
>>
>>      valgrind: Unknown option: --undef-value-errors=no
>>      valgrind: Use --help for more information or consult the user manual.
>>
>> Command to reproduce the error:
>>
>>      valgrind --verbose --tool=massif executable
>>
>> where executable was the program i wanted to check (compiled with -g)
>>
>> even a simple
>>
>>      valgrind --verbose --tool=massif /bin/bash
>>
>> produces the same error
>>
>> ** Valgrind version:
>> valgrind-3.14.0
>>
>> Fedora, linux 4.18.19-100
>>
>> Many thanks,
>> a.
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] massif problem - Unknown option: --undef-value-errors=no

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

--undef-value-errors is not a massif option, it is a memcheck option.

So, it is completely normal that massif reports that this is an
unknown option.

If you want to have the list of options massif understands,
you have to do:
  valgrind --tool=massif --help

If you do not specify a tool, then valgrind defaults to memcheck.

Note that you can also prefix options with the tool they are
aimed at.
So, e.g. 
  valgrind --tool=massif --memcheck:undef-value-errors=no executable
does not complain.

Philippe

On Sat, 2019-02-16 at 15:20 +0200, / via Valgrind-users wrote:
> Hi people, I get the following error when I try to invoke "massif" in 
> the most simple manner:
> 
>     valgrind: Unknown option: --undef-value-errors=no
>     valgrind: Use --help for more information or consult the user manual.
> 
> Command to reproduce the error:
> 
>     valgrind --verbose --tool=massif executable
> 
> where executable was the program i wanted to check (compiled with -g)
> 
> even a simple
> 
>     valgrind --verbose --tool=massif /bin/bash
> 
> produces the same error
> 
> ** Valgrind version:
> valgrind-3.14.0
> 
> Fedora, linux 4.18.19-100
> 
> Many thanks,
> a.
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] massif problem - Unknown option: --undef-value-errors=no

[/ <is...@ya...>]

Hi people, I get the following error when I try to invoke "massif" in 
the most simple manner:

    valgrind: Unknown option: --undef-value-errors=no
    valgrind: Use --help for more information or consult the user manual.

Command to reproduce the error:

    valgrind --verbose --tool=massif executable

where executable was the program i wanted to check (compiled with -g)

even a simple

    valgrind --verbose --tool=massif /bin/bash

produces the same error

** Valgrind version:
valgrind-3.14.0

Fedora, linux 4.18.19-100

Many thanks,
a.

[Valgrind-users] [HELP] there is some unknown aarch64 fp16 instruction for valgrind 3.13 3.14

[Wuweijia <wuw...@hu...>]

The source as below:

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <arm_neon.h>


int process(){
    __fp16* zcb_hal16 = (__fp16*)malloc(100);
    zcb_hal16[0] = 0;

    float16x8_t vblkA0, vblkB0, vblkC0;
    vblkC0 = vfmaq_n_f16(vblkC0, vblkB0, vblkA0[0]);
    __asm __volatile("fmla     %[c0].8h, %[b0].8h, %[a0].h[0]" : [c0] "+w"(vblkC0) : [b0] "w"(vblkB0), [a0] "w"(vblkA0));
    return 0;
}

int main()
{
    printf("start...\n");
    process();
    printf("ok...\n");
    return 0;
}

The compile tool: clang 6
The compile args: clang ./test.cpp

The output as below:
localhost:~/workspace/neonfp16_test/jni # valgrind ./a.out
==9762== Memcheck, a memory error detector
==9762== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9762== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9762== Command: ./a.out
==9762==
start...
disInstr(arm64): unhandled instruction 0x1EE703E0
disInstr(arm64): 0001'1110 1110'0111 0000'0011 1110'0000
==9762== valgrind: Unrecognised instruction at address 0x4005f8.
==9762==    at 0x4005F8: process() (in /root/workspace/neonfp16_test/jni/a.out)
==9762==    by 0x4006C7: main (in /root/workspace/neonfp16_test/jni/a.out)

[Valgrind-users] Memcheck can't recognize (stack) allocation place of uninitialized value

[Arseny S. <she...@ya...>]

Hi,

I'm running some Postgres extension under Valgrind memcheck. It reports
the following error:

==20263== VALGRINDERROR-BEGIN
==20263== Use of uninitialised value of size 8
==20263==    at 0xC4DA9B8: fill_prel_with_partitions (relation_info.c:737)
==20263==    by 0xC4D9F94: build_pathman_relation_info (relation_info.c:464)
==20263==    by 0xC4D9A4F: get_pathman_relation_info (relation_info.c:351)
==20263==    by 0xC4D9925: has_pathman_relation_info (relation_info.c:307)
==20263==    by 0xC4E8930: add_to_pathman_config (pl_funcs.c:859)
==20263==    by 0x4400EC: ExecInterpExpr (execExprInterp.c:654)
==20263==    by 0x441D38: ExecInterpExprStillValid (execExprInterp.c:1786)
==20263==    by 0x484EF1: ExecEvalExprSwitchContext (executor.h:303)
==20263==    by 0x484F5A: ExecProject (executor.h:337)
==20263==    by 0x485139: ExecResult (nodeResult.c:136)
==20263==    by 0x455460: ExecProcNodeFirst (execProcnode.c:445)
==20263==    by 0x449CF7: ExecProcNode (executor.h:237)
==20263==    by 0x44C6FC: ExecutePlan (execMain.c:1727)
==20263==    by 0x44A30E: standard_ExecutorRun (execMain.c:365)
==20263==    by 0x44A115: ExecutorRun (execMain.c:307)
==20263==    by 0x49A9AE: _SPI_pquery (spi.c:2493)
==20263==    by 0x49A3BF: _SPI_execute_plan (spi.c:2255)
==20263==    by 0x497179: SPI_execute_plan_with_paramlist (spi.c:531)
==20263==    by 0xD940BD8: exec_run_select (pl_exec.c:5983)
==20263==    by 0xD9395F2: exec_stmt_perform (pl_exec.c:2222)
==20263==  Uninitialised value was created by a stack allocation
==20263==    at 0xC4D5D50: ??? (in /home/ars/postgres/install/ee11/lib/pg_pathman.so)
==20263==
==20263== VALGRINDERROR-END

Everything is built with debug symbols and with -O0. As you see,
Valgrind can't determine function where stack allocation took
place. Indeed, address 0xC4D5D50 is not of any function. Recalculating
it into an offset, it is 0xED50. Here is a part of nm -n output:

ars@ars-thinkpad $ nm -n /home/ars/postgres/install/ee11/lib/pg_pathman.so
000000000003d760 r __FUNCTION__.23753
000000000003d77c r __GNU_EH_FRAME_HDR
0000000000042f88 r __FRAME_END__
00000000002439e8 t __frame_dummy_init_array_entry

Does it look like a bug in Valgrind?

Moreover, looking at the code I don't actually believe there is
an uinitialized value. Here is the relevant code:

 731         switch (prel->parttype)
 732         {
 733             case PT_HASH:
 734                 child_relid = pbin->child_relid;
 735                 children = prel->children;
 736                 part_idx = pbin->part_idx;
 737                 children[part_idx] = child_relid;
 738                 break;

The only 8-byte value at line 737 is 'children'. I am pretty sure that
prel->children is initialized, and anyway line 735 is not declared as
offending.

Valgrind version is valgrind-3.12.0.SVN. Run options are

	valgrind --tool=memcheck --trace-children=yes --track-origins=yes \
		 --read-var-info=yes --num-callers=20 --leak-check=no \
		 --gen-suppressions=all --error-limit=no \
		 --suppressions="${PGSDIR}/src/tools/valgrind.supp" \
		 --error-markers=VALGRINDERROR-BEGIN,VALGRINDERROR-END \


--
Best regards,
Arseny Sher

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

[Ahmad N. <ahm...@gm...>]

Thanks, everybody. I will try your suggestions.

On Saturday, February 9, 2019, Philippe Waroquiers <
phi...@sk...> wrote:

> On Fri, 2019-02-08 at 21:02 +0330, Ahmad Nouralizadeh wrote:
> > Thanks David,
> > But heaptrack even reports a larger number: 153 MB!
> >
> > On Fri, Feb 8, 2019 at 8:09 PM David Faure <fa...@kd...> wrote:
> > > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
> > > > Hi,
> > > > I wrote a really simple Pin tool to calculate the number of
> dynamically
> > > > allocated bytes in a program. I instrumented GIMP with this tool and
> it
> > > > reported 77 MB of allocations. I did the same experiment with
> Valgrind
> > > > which reported 117 MB.
> > > > My Pin tool is similar to the example in Pin. It searches for
> malloc(),
> > > > calloc() and memalign() in each loaded image and adds instructions
> before
> > > > them to calculate the total size of the allocations.
> > > > I am really confused and need help!
>
> What I suggest is to try with much smaller executables and investigate
> when you see a difference.
>
> For example, do the following in a valgrind build:
>    valgrind --xtree-memory=full ./memcheck/tests/trivialleak
> This will output the total allocations observed by valgrind.
> It will also produce a file xtmemory.kcg.<PID>
> that gives the detailed information about the malloc/free calls
> (to visualise with kcachegrind).
>
> Compare this with what is given by the 2 other measurements.
> Try with somewhat more complex programs if you see no difference,
> till you find a difference with (let's hope) something simple
> enough that you can understand where the difference is coming from.
>
> With valgrind, you can also trace all the malloc/free calls
> using --trace-malloc=yes.
>
> Philippe
>
>
>

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

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

On Fri, 2019-02-08 at 21:02 +0330, Ahmad Nouralizadeh wrote:
> Thanks David,
> But heaptrack even reports a larger number: 153 MB!
> 
> On Fri, Feb 8, 2019 at 8:09 PM David Faure <fa...@kd...> wrote:
> > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
> > > Hi,
> > > I wrote a really simple Pin tool to calculate the number of dynamically
> > > allocated bytes in a program. I instrumented GIMP with this tool and it
> > > reported 77 MB of allocations. I did the same experiment with Valgrind
> > > which reported 117 MB.
> > > My Pin tool is similar to the example in Pin. It searches for malloc(),
> > > calloc() and memalign() in each loaded image and adds instructions before
> > > them to calculate the total size of the allocations.
> > > I am really confused and need help!

What I suggest is to try with much smaller executables and investigate
when you see a difference.

For example, do the following in a valgrind build:
   valgrind --xtree-memory=full ./memcheck/tests/trivialleak
This will output the total allocations observed by valgrind.
It will also produce a file xtmemory.kcg.<PID>
that gives the detailed information about the malloc/free calls
(to visualise with kcachegrind).

Compare this with what is given by the 2 other measurements.
Try with somewhat more complex programs if you see no difference,
till you find a difference with (let's hope) something simple
enough that you can understand where the difference is coming from.

With valgrind, you can also trace all the malloc/free calls
using --trace-malloc=yes.

Philippe

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

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

On 2/8/19 10:58 AM, Ahmad Nouralizadeh wrote:
> By image, I mean the binary code of the program to be traced and all the shared libraries accessed by that program. As soon as they are loaded, they will be searched for calls to malloc,... and some code will be added before and after each call

It would be more robust to re-write the first several instructions
of malloc itself, instead of trying to find all the calls.
In particular, a tail-merged call that jumps to the "call malloc@PLT"
instruction might not be recognized by the insertion of code
"before and after each call to malloc".
Also, malloc() can be called through a pointer:
	void *(*f)(size_t) = malloc;
	char *x = f(10);
and the "before ... and after" recognizer probably will miss some of those.

ld-linux (the PT_INTERP) might have its own malloc, separate from libc.so.6.

In some (but not all) cases mmap(0,size,prot,MAP_PRIVATE|MAP_ANONYMOUS,-1,0)
should be considered an allocation.  Do all the measurement programs agree?

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

[Ahmad N. <ahm...@gm...>]

Hi Tom,
Yes. ld.so is also an image that is looked for malloc calls.

On Fri, Feb 8, 2019 at 10:31 PM Tom Hughes <to...@co...> wrote:

> Right but how does your program get control? Does it manage to see
> all the allocations done by the dynamic linker before main is entered?
>
> Tom
>
> On 08/02/2019 18:58, Ahmad Nouralizadeh wrote:
> > By image, I mean the binary code of the program to be traced and all the
> > shared libraries accessed by that program. As soon as they are loaded,
> > they will be searched for calls to malloc,... and some code will be
> > added before and after each call. The code is used to store stats, such
> > as the allocation size. How is it possible to miss an allocation? Every
> > possible malloc,... call point is covered.
> >
> > On Fri, Feb 8, 2019 at 10:14 PM David Faure <fa...@kd...
> > <mailto:fa...@kd...>> wrote:
> >
> >     LOL that was the risk, getting a third, completely different, number
> ;)
> >
> >     Well, you mention that your tool only looks at "each loaded image",
> >     while heaptrack and valgrind look at ALL allocations.
> >
> >
> >     On vendredi 8 février 2019 18:32:01 CET Ahmad Nouralizadeh wrote:
> >      > Thanks David,
> >      > But heaptrack even reports a larger number: 153 MB!
> >      >
> >      > On Fri, Feb 8, 2019 at 8:09 PM David Faure <fa...@kd...
> >     <mailto:fa...@kd...>> wrote:
> >      > > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh
> wrote:
> >      > > > Hi,
> >      > > > I wrote a really simple Pin tool to calculate the number of
> >     dynamically
> >      > > > allocated bytes in a program. I instrumented GIMP with this
> >     tool and it
> >      > > > reported 77 MB of allocations. I did the same experiment with
> >     Valgrind
> >      > > > which reported 117 MB.
> >      > > > My Pin tool is similar to the example in Pin. It searches for
> >     malloc(),
> >      > > > calloc() and memalign() in each loaded image and adds
> >     instructions
> >      > > > before
> >      > > > them to calculate the total size of the allocations.
> >      > > > I am really confused and need help!
> >      > >
> >      > > If you're on Linux, I recommend using heaptrack for this :-)
> >      > > https://github.com/KDAB/heaptrack
> >      > >
> >      > > This doesn't really answer your question, sorry about that, but
> >     you might
> >      > > want
> >      > > to see which of those tools heaptrack agrees with, it might
> >     help finding
> >      > > out
> >      > > who is wrong...
> >      > >
> >      > > --
> >      > > David Faure, fa...@kd... <mailto:fa...@kd...>,
> >     http://www.davidfaure.fr
> >      > > Working on KDE Frameworks 5
> >
> >
> >     --
> >     David Faure, fa...@kd... <mailto:fa...@kd...>,
> >     http://www.davidfaure.fr
> >     Working on KDE Frameworks 5
> >
> >
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

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

Right but how does your program get control? Does it manage to see
all the allocations done by the dynamic linker before main is entered?

Tom

On 08/02/2019 18:58, Ahmad Nouralizadeh wrote:
> By image, I mean the binary code of the program to be traced and all the 
> shared libraries accessed by that program. As soon as they are loaded, 
> they will be searched for calls to malloc,... and some code will be 
> added before and after each call. The code is used to store stats, such 
> as the allocation size. How is it possible to miss an allocation? Every 
> possible malloc,... call point is covered.
> 
> On Fri, Feb 8, 2019 at 10:14 PM David Faure <fa...@kd... 
> <mailto:fa...@kd...>> wrote:
> 
>     LOL that was the risk, getting a third, completely different, number ;)
> 
>     Well, you mention that your tool only looks at "each loaded image",
>     while heaptrack and valgrind look at ALL allocations.
> 
> 
>     On vendredi 8 février 2019 18:32:01 CET Ahmad Nouralizadeh wrote:
>      > Thanks David,
>      > But heaptrack even reports a larger number: 153 MB!
>      >
>      > On Fri, Feb 8, 2019 at 8:09 PM David Faure <fa...@kd...
>     <mailto:fa...@kd...>> wrote:
>      > > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
>      > > > Hi,
>      > > > I wrote a really simple Pin tool to calculate the number of
>     dynamically
>      > > > allocated bytes in a program. I instrumented GIMP with this
>     tool and it
>      > > > reported 77 MB of allocations. I did the same experiment with
>     Valgrind
>      > > > which reported 117 MB.
>      > > > My Pin tool is similar to the example in Pin. It searches for
>     malloc(),
>      > > > calloc() and memalign() in each loaded image and adds
>     instructions
>      > > > before
>      > > > them to calculate the total size of the allocations.
>      > > > I am really confused and need help!
>      > >
>      > > If you're on Linux, I recommend using heaptrack for this :-)
>      > > https://github.com/KDAB/heaptrack
>      > >
>      > > This doesn't really answer your question, sorry about that, but
>     you might
>      > > want
>      > > to see which of those tools heaptrack agrees with, it might
>     help finding
>      > > out
>      > > who is wrong...
>      > >
>      > > --
>      > > David Faure, fa...@kd... <mailto:fa...@kd...>,
>     http://www.davidfaure.fr
>      > > Working on KDE Frameworks 5
> 
> 
>     -- 
>     David Faure, fa...@kd... <mailto:fa...@kd...>,
>     http://www.davidfaure.fr
>     Working on KDE Frameworks 5
> 
> 
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 


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

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

[Ahmad N. <ahm...@gm...>]

By image, I mean the binary code of the program to be traced and all the
shared libraries accessed by that program. As soon as they are loaded, they
will be searched for calls to malloc,... and some code will be added before
and after each call. The code is used to store stats, such as the
allocation size. How is it possible to miss an allocation? Every possible
malloc,... call point is covered.

On Fri, Feb 8, 2019 at 10:14 PM David Faure <fa...@kd...> wrote:

> LOL that was the risk, getting a third, completely different, number ;)
>
> Well, you mention that your tool only looks at "each loaded image",
> while heaptrack and valgrind look at ALL allocations.
>
>
> On vendredi 8 février 2019 18:32:01 CET Ahmad Nouralizadeh wrote:
> > Thanks David,
> > But heaptrack even reports a larger number: 153 MB!
> >
> > On Fri, Feb 8, 2019 at 8:09 PM David Faure <fa...@kd...> wrote:
> > > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
> > > > Hi,
> > > > I wrote a really simple Pin tool to calculate the number of
> dynamically
> > > > allocated bytes in a program. I instrumented GIMP with this tool and
> it
> > > > reported 77 MB of allocations. I did the same experiment with
> Valgrind
> > > > which reported 117 MB.
> > > > My Pin tool is similar to the example in Pin. It searches for
> malloc(),
> > > > calloc() and memalign() in each loaded image and adds instructions
> > > > before
> > > > them to calculate the total size of the allocations.
> > > > I am really confused and need help!
> > >
> > > If you're on Linux, I recommend using heaptrack for this :-)
> > > https://github.com/KDAB/heaptrack
> > >
> > > This doesn't really answer your question, sorry about that, but you
> might
> > > want
> > > to see which of those tools heaptrack agrees with, it might help
> finding
> > > out
> > > who is wrong...
> > >
> > > --
> > > David Faure, fa...@kd..., http://www.davidfaure.fr
> > > Working on KDE Frameworks 5
>
>
> --
> David Faure, fa...@kd..., http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

[David F. <fa...@kd...>]

LOL that was the risk, getting a third, completely different, number ;)

Well, you mention that your tool only looks at "each loaded image",
while heaptrack and valgrind look at ALL allocations.


On vendredi 8 février 2019 18:32:01 CET Ahmad Nouralizadeh wrote:
> Thanks David,
> But heaptrack even reports a larger number: 153 MB!
> 
> On Fri, Feb 8, 2019 at 8:09 PM David Faure <fa...@kd...> wrote:
> > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
> > > Hi,
> > > I wrote a really simple Pin tool to calculate the number of dynamically
> > > allocated bytes in a program. I instrumented GIMP with this tool and it
> > > reported 77 MB of allocations. I did the same experiment with Valgrind
> > > which reported 117 MB.
> > > My Pin tool is similar to the example in Pin. It searches for malloc(),
> > > calloc() and memalign() in each loaded image and adds instructions
> > > before
> > > them to calculate the total size of the allocations.
> > > I am really confused and need help!
> > 
> > If you're on Linux, I recommend using heaptrack for this :-)
> > https://github.com/KDAB/heaptrack
> > 
> > This doesn't really answer your question, sorry about that, but you might
> > want
> > to see which of those tools heaptrack agrees with, it might help finding
> > out
> > who is wrong...
> > 
> > --
> > David Faure, fa...@kd..., http://www.davidfaure.fr
> > Working on KDE Frameworks 5


-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

[Ahmad N. <ahm...@gm...>]

Thanks David,
But heaptrack even reports a larger number: 153 MB!

On Fri, Feb 8, 2019 at 8:09 PM David Faure <fa...@kd...> wrote:

> On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
> > Hi,
> > I wrote a really simple Pin tool to calculate the number of dynamically
> > allocated bytes in a program. I instrumented GIMP with this tool and it
> > reported 77 MB of allocations. I did the same experiment with Valgrind
> > which reported 117 MB.
> > My Pin tool is similar to the example in Pin. It searches for malloc(),
> > calloc() and memalign() in each loaded image and adds instructions before
> > them to calculate the total size of the allocations.
> > I am really confused and need help!
>
> If you're on Linux, I recommend using heaptrack for this :-)
> https://github.com/KDAB/heaptrack
>
> This doesn't really answer your question, sorry about that, but you might
> want
> to see which of those tools heaptrack agrees with, it might help finding
> out
> who is wrong...
>
> --
> David Faure, fa...@kd..., http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

[David F. <fa...@kd...>]

On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
> Hi,
> I wrote a really simple Pin tool to calculate the number of dynamically
> allocated bytes in a program. I instrumented GIMP with this tool and it
> reported 77 MB of allocations. I did the same experiment with Valgrind
> which reported 117 MB.
> My Pin tool is similar to the example in Pin. It searches for malloc(),
> calloc() and memalign() in each loaded image and adds instructions before
> them to calculate the total size of the allocations.
> I am really confused and need help!

If you're on Linux, I recommend using heaptrack for this :-)
https://github.com/KDAB/heaptrack

This doesn't really answer your question, sorry about that, but you might want 
to see which of those tools heaptrack agrees with, it might help finding out 
who is wrong...

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

[Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

[Ahmad N. <ahm...@gm...>]

Hi,
I wrote a really simple Pin tool to calculate the number of dynamically
allocated bytes in a program. I instrumented GIMP with this tool and it
reported 77 MB of allocations. I did the same experiment with Valgrind
which reported 117 MB.
My Pin tool is similar to the example in Pin. It searches for malloc(),
calloc() and memalign() in each loaded image and adds instructions before
them to calculate the total size of the allocations.
I am really confused and need help!
Regards.

Re: [Valgrind-users] How can valgrind prevent Segmentation fault?

[John P. <Joh...@us...>]

I had a problem like last May, though it may not have been the same problem. In my case it was the optimization settings. I typically used -O0 for valgrind, and at -O0 the program didn’t crash. At level -O1 or higher it always crashed. I can’t recall if I ran it in valgrind at -O1 or higher, but if I did then that didn’t help me find the problem, either.

In the end I combed through the code where the problem was occurring, and discovered that I had forgotten to return a value from a function that was declared to return bool. I hadn’t noticed the compiler warning in the 20 screens of Makefile messages that scrolled by.

I hope that’s somehow helpful.

john perry

> On Jan 26, 2019, at 5:12 PM, Peng Yu <pen...@gm...> wrote:
> 
> Hi,
> 
> I have an executable. If I just run on its own, there will be
> segmentation fault. But if I run it using valgrind, it finishes
> successfully. Does anybody how can this happen? How to debug such a
> program? Thanks.
> 
> -- 
> Regards,
> Peng
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How can valgrind prevent Segmentation fault?

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

On 1/26/19, Eliot Moss wrote:
> On 1/26/2019, Peng Yu wrote:
> 
>> I have an executable. If I just run on its own, there will be
>> segmentation fault. But if I run it using valgrind, it finishes
>> successfully. Does anybody how can this happen? How to debug such a
>> program? Thanks.
> 
> Maybe not the sort of answer you have in mind, but I might start
> with using gdb.  It should still segfault under those conditions.
> You can then try recompiling to -g to get debug symbols

As Eliot says, SIGSEGV is easy.  Run under gdb until the SIGSEGV occurs,
then get a backtrace of subroutine calls, and look around.  If necessary,
then re-compile with -g to get more symbols.

On modern Intel x86_64 hardware (or on a "friendly" virtual machine) and with
lots of disk space, then try "Record and Replay":  https://rr-project.org/
(The videos are excellent!)
Re-played execution is *exactly* the same every time, so in the
worst case then binary search on the number of executed instructions
is a valid technique.

'rr' can even run the program "backwards", which is extremely useful.
Stop at the error, put a breakpoint on the entry to the current subroutine,
execute backwards to that breakpoint.  Then step forward by statement
or instruction, watching control flow, values of variables, etc.

Re: [Valgrind-users] How can valgrind prevent Segmentation fault?

[Alan C. <ala...@gm...>]

A segfault is usually a bad pointer or something pointing outside
allocated space.  Why it stops segfaulting when you run it through
Valgrind I don't know.  Compile with -g for either Valgrind or gdb,
and if it still runs in Valgrind try gdb.  You can just do gdb
<executable> then you'll probably have to type run in gdb.  At least
if it segfaults in there you can do a backtrace and maybe figure out
why.  Compiling with -g will usually enable gdb to print out bits of
your code when it stops so you may recognize where it is.  Google
something like "gdb segfault tutorial", you usually have to pick a
frame I think.

hmm, umass, I used to work there until 2009.

On 1/26/19, Eliot Moss <mo...@cs...> wrote:
> On 1/26/2019 6:12 PM, Peng Yu wrote:
>
>> I have an executable. If I just run on its own, there will be
>> segmentation fault. But if I run it using valgrind, it finishes
>> successfully. Does anybody how can this happen? How to debug such a
>> program? Thanks.
>
> Maybe not the sort of answer you have in mind, but I might start
> with using gdb.  It should still segfault under those conditions.
> You can then try recompiling to -g to get debug symbols.  Doing
> that might affect whether the bug exhibits, but it would make
> debugging easier.
>
> Valgrind might be useful if you think the fault has to do with
> improper freeing or lack of initialization of pointers ...
>
> Regards - Eliot Moss
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Valgrind-users] How can valgrind prevent Segmentation fault?

[Eliot M. <mo...@cs...>]

On 1/26/2019 6:12 PM, Peng Yu wrote:

> I have an executable. If I just run on its own, there will be
> segmentation fault. But if I run it using valgrind, it finishes
> successfully. Does anybody how can this happen? How to debug such a
> program? Thanks.

Maybe not the sort of answer you have in mind, but I might start
with using gdb.  It should still segfault under those conditions.
You can then try recompiling to -g to get debug symbols.  Doing
that might affect whether the bug exhibits, but it would make
debugging easier.

Valgrind might be useful if you think the fault has to do with
improper freeing or lack of initialization of pointers ...

Regards - Eliot Moss

Re: [Valgrind-users] How can valgrind prevent Segmentation fault?

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

On Sat, 2019-01-26 at 17:12 -0600, Peng Yu wrote:
> Hi,
> 
> I have an executable. If I just run on its own, there will be
> segmentation fault. But if I run it using valgrind, it finishes
> successfully. Does anybody how can this happen? How to debug such a
> program? Thanks.
Is valgrind reporting some errors ?
If yes, which kind of errors ?
Philippe

[Valgrind-users] How can valgrind prevent Segmentation fault?

[Peng Yu <pen...@gm...>]

Hi,

I have an executable. If I just run on its own, there will be
segmentation fault. But if I run it using valgrind, it finishes
successfully. Does anybody how can this happen? How to debug such a
program? Thanks.

-- 
Regards,
Peng

Re: [Valgrind-users] What is the memory ( RAM ) requirement for running valgrind

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

The memory requirement for Valgrind is “several times as much memory as the application you’re testing needs without Valgrind.”

How much memory does your application use normally?

--
John Dallman

From: Padala Dileep [mailto:pad...@gm...]
Sent: 25 January 2019 10:00
To: val...@li...
Subject: [Valgrind-users] What is the memory ( RAM ) requirement for running valgrind

Hi

My system has 4GB memory ( arm-linux ) . But when I try to run the valgrind,  the process becomes very slow, and it  gets rebooted with a message "valgrind: the 'impossible' happened'

How much RAM is expected to be present in the system  to run valgrind for  15-20 mins atleast.


If i stop the process, before 100% memory gets over, it dumps the evaluation till that point.
But it is only for 5 mins of Run. and it has not hit all the threads as the process is running slowly.


==1382== Memcheck, a memory error detector
==1382== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1382== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==1382== Command: Frm20xd
==1382==
--1382-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--1382-- si_code=1;  Faulting address: 0xFFFF0FE3;  sp: 0x426987b0

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==1382==    at 0x58184470: getUIntLittleEndianly (guest_arm_toIR.c:196)
==1382==    by 0x58184470: disInstr_ARM_WRK.isra.36 (guest_arm_toIR.c:16118)
==1382==    by 0x5818E2B3: disInstr_ARM (guest_arm_toIR.c:23690)
==1382==    by 0x581501D3: bb_to_IR (guest_generic_bb_to_IR.c:365)
==1382==    by 0x581328AF: LibVEX_FrontEnd (main_main.c:560)
==1382==    by 0x58133043: LibVEX_Translate (main_main.c:1185)
==1382==    by 0x58059CBB: vgPlain_translate (m_translate.c:1813)
==1382==    by 0x58095F53: handle_chain_me (scheduler.c:1134)
==1382==    by 0x58097FFF: vgPlain_scheduler (scheduler.c:1483)
==1382==    by 0x580F0F27: thread_wrapper (syswrap-linux.c:103)
==1382==    by 0x580F0F27: run_a_thread_NORETURN (syswrap-linux.c:156)
==1382==    by 0xFFFFFFFF: ???

Once  I stop the process before it gets exited like above, It is dumping the evaluation it was doing.

=
==1375== Process terminating with default action of signal 2 (SIGINT)
==1375==    at 0x53B90E8: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /lib/libstdc++.so.6.0.17)
==1375==    by 0x7DD155E7: ???
==1375==
==1375== HEAP SUMMARY:
==1375==     in use at exit: 16,558 bytes in 292 blocks
==1375==   total heap usage: 1,449 allocs, 1,157 frees, 53,262 bytes allocated
==1375==
==1375== LEAK SUMMARY:
==1375==    definitely lost: 0 bytes in 0 blocks
==1375==    indirectly lost: 0 bytes in 0 blocks
==1375==      possibly lost: 0 bytes in 0 blocks
==1375==    still reachable: 16,558 bytes in 292 blocks
==1375==                       of which reachable via heuristic:
==1375==                         stdstring          : 5,178 bytes in 194 blocks
==1375==         suppressed: 0 bytes in 0 blocks
==1375== Rerun with --leak-check=full to see details of leaked memory
==1375==
==1375== For counts of detected and suppressed errors, rerun with: -v
==1375== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


Thanks & Regards,
Dileep Padala

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