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
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 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 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 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 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
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 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 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-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 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 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 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-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
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 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,
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 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
--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 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
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 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 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
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 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
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 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-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
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
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
>
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
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 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:
> > >
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 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:
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
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
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
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
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
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
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
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
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
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.
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).
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 ...
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
>
> > 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-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 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, 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
301 - 365 of 365 matches
Mail list logo
