On Fri, 2023-02-24 at 10:42 -0700, User 10482 wrote:
> Dear All,
>
> I am looking to fix dangling pointer issue and was pleasantly surprised to
> find the
> `who-points-at` functionality in valgrind which tells the stack variable
> names (assuming
> --read-var-info=yes) and any addresses on
If you are envisaging to modify valgrind, you could take some inspiration from
the way
callgrind can dynamically activate/de-activate tracing.
See callgrind manual command line options and client requests for more details
Philippe
On Wed, 2023-02-08 at 17:47 +1100, Eliot Moss wrote:
> On
On Sat, 2022-11-12 at 12:21 +0100, Paul Floyd wrote:
> Philiipe wrote:
> > Possibly --sim-hints=no-nptl-pthread-stackcache might help (if I
> > re-read the manual entry for this sim-hint).
>
>
> As the manpage says, the pthread stackcache stuff is mainly for Helgrind.
>
> I don't see
On Fri, 2022-11-11 at 18:13 +0100, Paul Floyd wrote:
>
> On 11/11/22 17:47, Domenico Panella wrote:
> > Hi,
> >
> > I am getting a memory leak in my program about timer_delete function.
> >
> > According valgrind output,
> >
> > It seems that the timer_delete function doesn't release the
On Sun, 2022-10-23 at 00:11 +0200, Mark Wielaard wrote:
> Hi Philippe,
>
> On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote:
> > I have started running valgrind on valgrind (outer/inner setup).
> > Results should be available tomorrow evening or so ...
I have started running valgrind on valgrind (outer/inner setup).
Results should be available tomorrow evening or so ...
For the first few tests, seems ok.
Just one strange thing:
The outer valgrind crashes on the below test (while the native run of this test
is ok).
(this is on gcc farm gcc186).
As a wild guess: looks like your application is doing fork and exec.
You might try to add then --trace-children=yes
(and possibly if needed you should use --trace-children-skip=.. if tracing
all children is too much).
Otherwise, try first with a very simple standalone program
e.g.
Valgrind does not check out of bound write in arrays, unless these arrays are
malloc-ed
(and so valgrind can detect the write out of the limit of the malloc-ed block).
Valgrind used to contain an experimental tool (sgcheck) that did such stack
array checks,
but it had several limitations and
On Sun, 2022-09-04 at 00:14 +0200, Tomas Vondra wrote:
>
> Clearly, this is not an issue valgrind is meant to detect (like invalid
> memory access, etc.) but an application issue. I've tried reproducing it
> without valgrind, but it only ever happens with valgrind - my theory is
> it's some
On Wed, 2022-08-31 at 17:42 +, Bresalier, Rob (Nokia - US/Murray Hill)
wrote:
> > When running memcheck on a massive monolith embedded executable
> > (237MB stripped, 1.8GiB unstripped), after I stop the executable under
> > valgrind I see the "HEAP SUMMARY" but then valgrind dies before any
>
> > Is there anything that can be done with memcheck to make it consume less
> > memory?
>
> No.
In fact, Yes :).
Or more precisely, yes, memory can be somewhat reduced :).
See my other mail.
Philippe
___
Valgrind-users mailing list
On Fri, 2022-08-05 at 15:34 +, Bresalier, Rob (Nokia - US/Murray Hill)
wrote:
> > If finding memory leaks is the only goal (for instance, if you are
> > satisfied that
> > memcheck has found all the overrun blocks, uninitialized reads, etc.) then
> > https://github.com/KDE/heaptrack is the
If you are not using the last release of valgrind, you might try with the last
release.
Wondering if the problem also happens with other tools (e.g. --tool=none).
Otherwise, you could try to debug your application when running under valgrind
when it encounters the problem.
Eg. use arguments
You can do that by using the interactive leak search available via valgrind +
gdb + vgdb.
See e.g.
https://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
in particular the "monitor block_list" command.
Philippe
On Thu, 2022-01-27 at 15:06 -0600, Corey Minyard wrote:
> Is
If you use xml output, the used suppressions are only output when
you give the option --show-error-list=yes.
With xml, increasing the verbosity will not show the used suppressions.
Likewise, when xml output is selected, no ERROR SUMMARY is output
(and probably some other textual output is
On Mon, 2021-05-24 at 10:31 -0700, Martin Licht via Valgrind-users wrote:
> Hello,
>
> I think the Valgrind stack tracer is pretty great and I would like to use it
> as a substitute for `backtrace` in my C++ debug builds.
>
> A blog post by Nicholas Nethercote (Using Valgrind to get stack
It is a very long time I did not compile valgrind for android
(and when I did it years ago, I used an android emulator), so likely
I will not be able to help much.
Did you read and follow the README.android instructions ?
(sounds a little bit unexpected that the below error message seems
to
Looks a little bit difficult to tell anything precise based on the info you
provide.
As general guidelines:
* If the server segfaults, you should have a core dump to debug and see what
went wrong.
If core dump is disabled (e.g. check ulimit -a), you might also just
attach with gdb and
Hello,
No, valgrind/memcheck leak search is not impacted by the fact that one thread
allocates
some memory and that the release/free is done by another thread.
That should not lead to a definite leak.
So, if Valgrind tells that there are definite leaks, that is likely real leaks
to be
Hello
Support for AIX was removed I believe in 2011.
Philippe
On Thu, 2020-12-17 at 12:31 +, SHAIKH Mohammadshaeeque wrote:
> Hello Valgrind Team,
>
> I am interested to use Valgrind tool to detect memory leak issue on AIX for
> C++ programs,
> I want to know whether Valgrind tools
048576
>
> Thread 2: status = VgTs_WaitSys syscall 285 (lwpid 1560)
> (...)
> Thread 3: status = VgTs_WaitSys syscall 285 (lwpid 1561)
> (...)
>
>
> Thank you for helping me!
>
> Best regards,
> Łukasz Bolda
>
>
> -Original Message-
> F
Which version of valgrind are you using ?
You much better should use the last released version (or a more recent GIT
version).
Have you compiled your application with -g ?
In case you debug your native executable with gdb and put a break on malloc,
is gdb backtrace command giving a good stack
On Fri, 2020-09-11 at 12:38 +0200, Milian Wolff wrote:
> And finally, with heaptrack it is also not yet easily doable to get a diff
> between two time stamps. Also a feature I've long thought about implementing,
> but never got around to...
Note that valgrind allows to report a "delta/diff"
On Thu, 2020-09-10 at 15:26 +0200, folkert wrote:
> Hi,
>
> How can I obtain the number of mallocs per type in a time-frame using
> massif? I'm NOT interested in the total in use, I would like to know how
> often type x is allocated between t+1 and t+2.
You could run your application under
On Tue, 2020-09-08 at 14:09 +0200, Mario Emmenlauer wrote:
> On 08.09.20 12:25, Mario Emmenlauer wrote:
> > On 08.09.20 12:04, Mario Emmenlauer wrote:
> > > The error I get most frequently is (full output attached in log.txt)
> > > ==32== Valgrind's memory management: out of memory:
> > >
Valgrind has a lot of heuristics to optimise the speed of the JIT-ted code.
One of these heuristics is to chase jumps/calls to known destination.
This is somewhat similar to inlining performed by the compiler,
but performed by valgrind at runtime, when it encounters a new call/jump.
In this
On Fri, 2020-08-14 at 19:16 +0200, Mark Wielaard wrote:
> Hi Shachar,
>
> On Fri, Aug 14, 2020 at 06:35:14PM +0300, Shachar Shemesh wrote:
> > I am writing my own C++ microthreading library. At the very first switch, I
> > get the following message from Valgrind:
> >
> > ==15122== Warning:
On Fri, 2020-05-22 at 15:22 +0300, Michael Widenius wrote:
> Hi!
> I have searched documentation, internet and header files like
> memcheck.h, but not found a solution:
>
> When running the MariaDB test suite under valgrind, we sometimes may
> get a core dump. In this case, the leaked memory
You might find some inspiration by reading the function final_tidyup
in coregrind/m_main.c.
final_tidyup is calling some client code part of malloc library.
Philippe
On Thu, 2020-03-05 at 11:27 -0500, Derrick McKee wrote:
> My intent is to write a tool that waits for another process to write
>
ootup again, the valgrind log file seems do
> have some info there...
>
> I will check the link below to see if I can trigger memory leak search
> without killing the process.
Ok.
Note that the given links document the last released version of valgrind.
Philippe
>
> Thanks
On Thu, 2019-12-19 at 00:19 +, Rachel Chen (rychen) via Valgrind-users
wrote:
> Hello,
>
> I am using Valgrind to debug a memory leak. Somehow when I try to kill the
> process to get the log file with memory leak, it crash the system. I am using
> the following command to get the pid and
On Tue, 2019-11-12 at 20:18 -0800, Karthik Jayaraman wrote:
>
> Thread 47: status = VgTs_Runnable (lwpid 1861)
> ==1747==at 0x4C2922D: free (vg_replace_malloc.c:540)
> ==1747==by 0x9A7CB7B: __libc_freeres (in /usr/lib64/libc-2.17.so)
> ==1747==by 0x4A24739: _vgnU_freeres
On Wed, 2019-08-21 at 14:44 +0200, Philippe Waroquiers wrote:
> On Mon, 2019-08-12 at 15:15 +0300, Michael Widenius wrote:
> > Something like the following would be very useful:
> > VALGRIND_IGNORE_LEAKS(VALGRIND_LEAK_INDIRECT | VALGRIND_LEAK_DEFINITE...)
> See patch
On Mon, 2019-08-12 at 15:15 +0300, Michael Widenius wrote:
> Something like the following would be very useful:
> VALGRIND_IGNORE_LEAKS(VALGRIND_LEAK_INDIRECT | VALGRIND_LEAK_DEFINITE...)
See patch attached to https://bugs.kde.org/show_bug.cgi?id=411134
This patch allows to change various command
On Tue, 2019-08-13 at 16:54 +0300, Michael Widenius wrote:
> I can try that at once. Thanks.
> Testing...
> hm.. It would be good to describe in README_DEVELOPERS how to generate the
> autoconfigure scripts. Now it says one to run 'make dist', which will
> not work out of the box.
README has a
On Mon, 2019-08-12 at 13:49 +0100, Tom Hughes wrote:
> On 12/08/2019 13:15, Michael Widenius wrote:
>
> > The request I would like you to consider is to do one of the following:
> > - Ensure that sending a sigkill works and in this case there should
> > not be any valgrind leak report.
What
On Thu, 2019-06-20 at 11:04 +0530, subhasish Karmakar wrote:
> Hi,
>
> I have an application running on embedded linux.
> After running for hours my application causes out of memory issue.
> How can I get memory leak report periodically when the application is running?
> It's a process with
First http://www.valgrind.org/docs/manual/QuickStart.html
Then http://www.valgrind.org/docs/manual/manual.html
(or the same doc in the valgrind you compiled)
Philippe
On Thu, 2019-05-30 at 21:36 +0530, subhasish Karmakar wrote:
> Hi,
>
> I have compiled valgrind for ARM64 based target using
On Fri, 2019-04-05 at 20:53 +0200, Paulo Matos via Valgrind-users wrote:
> disInstr(arm64): unhandled instruction 0xD538
...
> Could this really be a problem with valgrind, or am I missing something?
>
> If I should raise a bug or add more info please let me know.
Searching on
On Thu, 2019-03-21 at 23:30 +0100, Yuri D'Elia wrote:
> On Thu, Mar 21 2019, Philippe Waroquiers wrote:
> > Strange.
> > The only thing I see that can cause this failure is VexTransOutputFull.
> >
> > So, the next trial is to bump x10
> > m_translate.c N_TMPBUF
&g
On Fri, 2019-03-22 at 10:21 +0100, Matthias Apitz wrote:
> El día Thursday, March 21, 2019 a las 10:44:54PM +0100, Philippe Waroquiers
> escribió:
>
> > On Thu, 2019-03-21 at 20:00 +0100, Matthias Apitz wrote:
> > > Hello,
> > >
> > > Why are only
On Thu, 2019-03-21 at 20:00 +0100, Matthias Apitz wrote:
> Hello,
>
> Why are only the '???' marks printed for the localtion of the stack
> allocation? This is with 3.18.0 on Linux x64:
3.18.0 ?
Last release is 3.14.
>
> ==24390== Conditional jump or move depends on uninitialised value(s)
>
On Wed, 2019-03-20 at 23:20 +0100, Yuri D'Elia wrote:
> On Wed, Mar 20 2019, Philippe Waroquiers wrote:
> > Easiest thing to try initially is to recompile with a bigger size.
>
> After bumping buffers 10x, I get this:
>
> ==14645== Memcheck, a memory error detector
> ==14
On Wed, 2019-03-20 at 00:01 +0100, Yuri D'Elia wrote:
> On Tue, Mar 19 2019, Philippe Waroquiers wrote:
> > > ==19253==by 0x580A524B: ??? (in
> > > /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> > > ==19253==by 0x580A71EF: ??? (in
> >
On Tue, 2019-03-19 at 19:05 +0100, Yuri D'Elia wrote:
> Hi everyone. It looks like the impossible happened. I was attempting to
> blindly run valgrind on debian unstable against slic3r-pe (mostly c++,
> which itself uses wxWidgets 3.1), both freshly compiled using gcc 8.3
> and got the following:
Some more info is needed to guess what the problem
could be.
Debug your program when running under valgrind using
gdb + vgdb.
Compare the behaviour e.g. with gdb+vgdb between the non working
system and a working system
and/or compare the -v -v -v -d -d -d traces.
Philippe
On Tue,
You should upgrade to a recent valgrind version (e.g. compile
the last official release 3.14, or even the git version).
See bug https://bugs.kde.org/show_bug.cgi?id=362935
Philippe
commit 7a8129795c5c4e0465ac48989dc6cd755b5d0a66
Author: Julian Seward
AuthorDate: Thu Jul 21 12:47:51 2016
On Sun, 2019-02-17 at 20:51 -0600, Peng Yu wrote:
> Hi,
>
> I have the follow flex code using Boehm garbage collector.
> http://www.hboehm.info/gc/gcinterface.html
>
> The program is compiled with the following commands.
>
> $ flex -o main.l.c main.l
> $ clang -I. -DGC_DEBUG -Wall -pedantic -g
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
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
--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
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 wrote:
> > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
> > > Hi,
> > > I wrote a really simple
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
On Wed, 2018-12-26 at 10:15 +, Kumara, Asanka wrote:
> Hi,
> Is there a way to detect ALL dangling pointers (at exit) in valgrind ?
>
> e.g.
>
> char* globalVar;
>
> void main()
> {
> char* z1 = new char[10];
> char* z2 = z1;
> globalVar = z2;
>
> delete[] z1;
>
> }
>
>
On Tue, 2018-11-20 at 10:35 +0100, Ivo Raisr wrote:
> Il giorno lun 19 nov 2018 alle ore 16:53 David Faure ha
> scritto:
> >
> > When using vgdb (e.g. `valgrind --vgdb-error=0 myprog`)
> > and there's a valgrind warning for an uninitialized read, on a line like
> > if (a || b)
> >
> > The
On Mon, 2018-11-05 at 15:30 -0500, Shahbaz Youssefi wrote:
> Looks like I was slightly too quick to ask this question. The issue
> seems to be coming from the way LLD produces debugging information,
> and adding --no-resegment to LLD fixes the issue:
>
>
If you try to build the RC2 but from the git repository,
does that work better ?
If the same git version builds/runs ok, then it is probably
just a tar ball packaging problem ...
Philippe
On Thu, 2018-10-04 at 14:41 -0700, Jonathan Leffler wrote:
> Hi,
>
> What is the intended support status
On Mon, 2018-09-17 at 22:14 +0200, Alexander Brock wrote:
> On 9/17/18 7:26 PM, Julian Seward wrote:
> > > valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
> > > Assertion 'cfsi_fits' failed.
> >
> > Is that really still failing? I thought that got comprehensively fixed
> >
On Mon, 2018-08-20 at 17:44 +0800, shuai xi wrote:
> Hi@all,
>
> I add some hooks in the vgpreload*.so and get some information from it. The
> vgpreload*.so is a dynamically library loaded in the guest code.
>
> I want to get this information to do some analysis. But i don't know how to
>
The below wrapping functions must be in code which is part
of the guest code. That can be either directly in the guest
program/libraries, or alternatively in a valgrind preloaded
lib.
The assert below indicates that the address of the provided
wrapping function is not a valid guest address
Yo
On Thu, 2018-06-28 at 14:50 +0100, EML wrote:
> The program below creates two threads, in a detached state, and waits for
> them to complete with 'pthread_exit'. Compile and run as:
>
> > gcc -lpthread test.c
> > valgrind --leak-check=full a.out
>
> valgrind-3.13.0 (compiled from source)
On Tue, 2018-05-29 at 08:49 +, Zwinkau Andreas (CC-AD/EYF1) wrote:
> Hi
>
> We have a bunch of memory arrays which are used as communication queues
> between components. I want to count how much those queues are actually used
> by the components by counting the memory accesses. This should
On Sun, 2018-05-20 at 14:49 -0400, Jeffrey Walton wrote:
> I'm working on Fedora 27 x86_64 from Master trying to sidestep
> https://bugs.kde.org/show_bug.cgi?id=387773.
>
> I configured Valgrind with the following:
>
> PKGCONFIG: /usr/local/lib64/pkgconfig
> CPPFLAGS:
On Thu, 2018-04-19 at 00:39 +, Wuweijia wrote:
> memcheck expensive sanity: distinguished_secondaries have changed
>
> valgrind: external/valgrind/coregrind/m_scheduler/scheduler.c:2240
> (vgPlain_sanity_check_general): Assertion
> 'VG_TDICT_CALL(tool_expensive_sanity_check)' failed.
>
>
On Sat, 2018-04-14 at 13:37 -0400, IMoL wrote:
> Thank you Philippe.
>
> That patch allows valgrind to compile on macOS.
thanks for the feedback, patch committed as
06cb991bcd9966b614cd672a7d6e26785f60f851
>
> Still doesn't work for me, mind you, but at least it compiles again :-)
Someone with
On Fri, 2018-04-13 at 05:56 -0400, IMoL wrote:
> git-1f08787cf (of 11 April) fails to build on macOS:
>
> m_syswrap/syswrap-generic.c:1797:26: error: variable has incomplete type
> 'struct vki_semid64_ds'
> struct vki_semid64_ds buf;
> ^
>
On Fri, 2018-04-13 at 18:27 +, Rachel Chen (rychen) wrote:
> Index:
> third-party/src/valgrind/valgrind-3.4.1/coregrind/m_syswrap/syswrap-x86-linux.c
The release 3.4.1 is from 2009.
I suggest to upgrade to the last release (3.13.0), as it is unlikely
someone will be willing/able to provide
On Mon, 2018-03-19 at 22:31 +0100, Paul Floyd wrote:
> Hi
>
> I’ve been using Massif recently and I gave the xtree output a go (using the
> callgrind format output).
>
> Am I right in saying that, by default, the stats given are for the entire run?
Yes.
> This means that the total
To further investigate, some more info might be useful, and some
actions below might help.
General info:
Which version of valgrind are you using ? On which platform ?
The function setup_client_env in initimg-linux.c is responsible
to modify LD_PRELOAD (as valgrind needs to add some values
check-amd64-linux] Error 1
>
> Is there an alternative to create more space for the program?
>
> Thanks.
>
> João M. S. Silva
>
> > -Original Message-
> > From: Silva João
> > Sent: 10 de dezembro de 2017 21:10
> > To: Philippe Waroquiers &
On Wed, 2018-02-07 at 15:25 -0600, Adam Scott wrote:
> Even with the patches from that bug the error still occurred.
Ouch. Bad luck.
As I understand from the stack trace, the valgrind crash happens
somewhere inside google breakpad, which is itself a crash reporter ?
If this is correct, it might
Have you tried with --fair-sched=yes, as suggested in an earlier mail ?
What were/are the results ?
Philippe
On Wed, 2018-02-07 at 07:52 +, Wuweijia wrote:
> Hi:
> There are some news about this question. The new code as below, I
> change from __sync_fetch_and_add to
It might be worth trying with --fair-sched=yes, just in case what you see
is due to the unfairness of thread scheduling.
Philippe
On Fri, 2018-01-26 at 06:57 +, Wuweijia wrote:
> Hi:
>
> How large is 'm_nStep'? [Are you sure?]
>
> The source as below, all are the integer. Do you care
The compiler warning messages look somewhat fishy:
* they speak about a variable (e.g. tokens_saveptr)
but pointing at a line in a function where there is no such variable
(e.g. the 'for (p = s' loop).
* Maybe this is because the compiler does not understand strtok_r. Here is
an
On Tue, 2018-01-09 at 14:15 +0100, Jacek M. Holeczek wrote:
> Dear Sirs,
> this is CentOS Linux release 7.4.1708 (Core) /
> 3.10.0-693.11.6.el7.x86_64 kernel / gcc (GCC) 4.8.5 20150623 (Red Hat
> 4.8.5-16).
> I tried to use two recent versions of valgrind, the most current GIT (as
> of today)
Does it help to run with
--expensive-definedness-checks=yes
?
You might also try 3.14 GIT version, as some work was recently done
in the area of definedness checking and the above option was also
extended with a 3rd value (auto), which is less expensive.
Philippe
On Wed, 2017-12-20 at
On Thu, 2017-12-07 at 12:39 +, Silva João wrote:
> > If you have 39 tasks in Runnable state, I guess that they are not all
> > blocked in libc read ?
> > So, you might investigate which task(s) are really still doing something
> > by doing e.g.
> >thread apply all bt
> > and/or put
On Tue, 2017-12-05 at 15:41 +, Silva João wrote:
> > > ==44156== Thread 2 FDP_MRP_Recover_:
> > > ==44156== Invalid write of size 4
> > > ==44156==at 0x78BB33: system__stack_usage__fill_stack (in
> >
> > /u/wh/rel/ifaplrel/pw_fwp_engine.eab)
> > > ==44156==by 0x75C49B:
Before doing any such bug reproducer, it would be better to
first upgrade to the last release 3.13. Quite a lot of bugs
were solved since 3.10.0 (which dates from 2014).
Philippe
For sure, quite a lot of bugs and missing instructions
On Tue, 2017-10-31 at 17:43 +, Jeff Hammond wrote:
>
> I dont understand the change in behaviour due to valgrind. Is this a
> known issue or a bug?
This is a bug in the strspn replacement, used a.o. by memcheck,
helgrind, ...
I fixed it in commit c1eace647ca4f670ef9bec0d0fe72cdd25a96394
Now, your small test case works similarly with or without
On Thu, 2017-10-19 at 12:06 -0400, Zack Weinberg wrote:
> I can work around this by forcibly adjusting valgrind's state for the
> "data" object (compile with -DDO_MAKE_MEM_WRITABLE to see) but I
> would
> like to understand *why* this memory has become unwritable, why the
>
On Thu, 2017-09-07 at 09:03 +0200, Frederic DUMOULIN wrote:
> Hi,
>
> I'm using valgrind + massif tool to observe the heap usage.
>
> I have an application binary using a shared library which does the
> memory allocations.
> There are few functions in the API but they are called many times. So
On Wed, 2017-08-30 at 11:16 +0200, Dominik Straßer wrote:
> As there are many different BN_* functions causing these errors I would
> like to use a global suppression. I tried:
> {
>crypto2
>Memcheck:Cond
>obj: */libcrypto.so.1.0.0
> }
> and
> {
>crypto2
>Memcheck:Cond
>...
On Thu, 2017-08-03 at 19:21 -0400, Serhei Makarov wrote:
> Hello all,
>
> I'm working on a project based on Valgrind and I have a question about
> Valgrind's debuginfo interface. Namely, is there any functionality to
> obtain the offset of a variable, given its name?
>
> The Valgrind
On Tue, 2017-07-04 at 10:48 +, Wuweijia wrote:
> Hi:
> There are some bug in the sub-tool for valgrind. I want to
> debug it via printing log, but there is a lot of log and run slowly I
> can not stand it .
> And is there any tools like gdb , I can the debug the sub-tool for
>
This looks like a bug related to running libc free resource hooks.
You can bypass the problem by giving the parameters:
--run-libc-freeres=no --run-cxx-freeres=no
Please file a bug on bugzilla.
Thanks
Philippe
On Sat, 2017-06-24 at 09:35 +, Wuweijia wrote:
> Any guy focus on this bug?
Helgrind maintains a unique thread nr by intercepting pthread_create,
as e.g. helgrind needs to speak about terminated threads
and so, cannot use the tid, as the tid is re-used : a new thread uses
the lowest free tid value.
See hg_main.c evh__pre_thread_ll_create, hooked up with
On Wed, 2017-06-21 at 19:17 +, Mike Lui wrote:
> I posted this on the valgrind-dev mailing list a while back but didn't
> receive a response. Hopefully some users have some input.
>
>
> I'm working on a project that leverages Callgrind to generate VEX IR
> traces. I'm using Valgrind 3.12.0.
Thanks, fixed as revision 16444
On Thu, 2017-06-08 at 12:11 -0500, Andy Goth wrote:
> As of today, http://valgrind.org/docs/manual/cg-manual.html includes
> the following example:
>
> enum E { A, B, C };
> enum E e;
> enum E table[] = { 1, 2, 3 };
> int i;
> ...
> i += table[e];
>
> I'm pretty
On Wed, 2017-05-31 at 23:54 +0200, Philippe Waroquiers wrote:
> If the problem is effectively linked to re-creation of
> another mutex at the same addr, then i think a small
> reproducer should be easy to write.
The below small program reproduces the behaviour
you have seen: a race
n.
Philippe
>
>
>
> ______
> From: Philippe Waroquiers <philippe.waroqui...@skynet.be>
> Sent: Monday, May 29, 2017 5:20 PM
> To: William Good
> Cc: valgrind-users@lists.sourceforge.net
> Subject: Re: [Valgrind-users] Helgrind detects r
You might have been unlucky and have a lock that was freed and then
re-used.
See extract of mk_LockP_from_LockN comments:
So we check that each LockN is a member of the admin_locks double
linked list of all Lock structures. That stops us prodding around
in potentially freed-up Lock
This looks like a bug.
The best is to file a bug on bugzilla, and attach (preferrably) a small
reproducer.
Alternatively, it might be good enough to just attach the callgrind
output file and the source file to run the callgrind_annotate command.
Note that in the meantime, you might try
On Tue, 2017-04-18 at 02:33 +, Wuweijia wrote:
> Hi Philippe:
> This is the android project.
>
> No matter the LD_PRELOAD , the valgrind always failed. The output is the
> same.
>
> I do not want to set it , I just try it when run the massif failed with
> --pages-as-heap and no
On Mon, 2017-04-17 at 06:36 +, Wuweijia wrote:
>
>
> The output as below:
...
> localhost:/system/bin # LD_PRELOAD=/system/bin/linker64 ./valgrind
> --tool=massif -v --pages-as-heap=yes ./mcfPQ
> --gtest_filter=*DISTANCE_001_001*
...
> CANNOT LINK EXECUTABLE "./mcfPQ": can't read file
With the below command, valgrind will only analyse the shell sh.
If you want to analyse what is launched by the shell, then you have
to give the option --trace-children=yes
Philippe
On Wed, 2017-04-05 at 01:08 +, Wuweijia wrote:
> no, I ran the valgrind on sh, but sh call applicant
bar_bad test was reworked in 3.13SVN
I think it is supposed to work deterministically now.
Philippe
On Wed, 2017-03-22 at 12:38 -0700, Mark Roberts wrote:
> Running CentOS 7.3.1611 on amd64 box. Valgrind release 3.12.0 with no
> mods.
>
>
>
> Builds without error and runs all regtests
Jan 13, 2017 at 11:41 AM, Ivo Raisr <iv...@ivosh.net> wrote:
> >>
> >>
> >> 2017-01-12 20:36 GMT+01:00 Philippe Waroquiers
> >> <philippe.waroqui...@skynet.be>:
> >>>
> >>> On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz w
On Thu, 2017-01-12 at 13:37 +0100, Roland Mainz wrote:
> On Thu, Jan 12, 2017 at 1:31 PM, Petar Jovanovic <mips3...@gmail.com> wrote:
> > On Wed, Jan 4, 2017 at 3:21 PM, Philippe Waroquiers
> > <philippe.waroqui...@skynet.be> wrote:
> >> No sign of any til
On Thu, 2017-01-05 at 13:21 +0100, Gabriel Gritsch wrote:
> thank you for the quick answer - it worked.
>
> I was unable to search the mailing list because the mentioned urls seem to be
> down:
> http://news.gmane.org/gmane.comp.debugging.valgrind
> http://search.gmane.org
Yes, the gmane
1 - 100 of 365 matches
Mail list logo
