On Fri, 2015-05-01 at 23:45 +0200, Jon wrote:
Since none of these functions were called by the program above, I wonder
if this how the output is supposed to look. Were are these function
calls coming from then? Or could there be something wrong with the way I
installed Valgrind?
This is all
On Tue, 2015-05-12 at 17:01 +0530, Austin Einter wrote:
On debugging found that epoll out events does not come for client
sockets.
Is it a known valgrind issue?
To my knowledge, there is no problem with epoll and Valgrind.
What version are you using ? On which platform ?
To
On Wed, 2015-04-15 at 16:35 -0400, Atalay Ozgovde wrote:
Upon tracing valgrind upon suggestions above I found two offending
system calls in my code: sys_newstat and sys_statfs. I also verified
deadlock lines by running valgrind with vgdb set and stepping
through the code.
Following patch is
On Thu, 2015-04-16 at 13:24 +0100, João M. S. Silva wrote:
I defined a gdb-macro for this:
define get_vbits
printf # mon get_vbits 0x%lx 0x%lx\n , $arg0 , sizeof($arg0)
eval mon get_vbits 0x%lx 0x%lx , $arg0 , sizeof($arg0)
end
Then I can run:
(gdb) get_vbits i_Cond
# mon
On Tue, 2015-04-14 at 19:26 +0100, João M. S. Silva wrote:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x060bdb6d in decode_rs_char (p=0x201aac50, data=0xffefff500 ,
eras_pos=0xffefff480, no_eras=22) at decode_rs.h:118
118 tmp = INDEX_OF[lambda[j - 1]];
I
On Tue, 2015-04-14 at 22:03 +0100, João M. S. Silva wrote:
Yes, but in some cases the sizeof indicates the size of the pointer (not
the size of the allocated memory). So I had to browse the code to get
the size of the allocations/structs involved.
or use
(gdb) monitor v.info location addr
On Tue, 2015-04-14 at 19:26 +0100, João M. S. Silva wrote:
What you can further do is to use the memcheck monitor commands to
examine the definedness of the variables used on the line where the
error is detected.
See manual for more info
On Mon, 2015-04-13 at 16:28 +, Lerner, Dave wrote:
I noticed what looks like a typo in the code for the powerpc altivec register
set save/restore logic. I found the bug in both 3.10.1 and 3.9.
A suggested patch is shown below.
Thanks for the analysis and the patch.
I think it is better
On Fri, 2015-04-10 at 20:04 +, Zhu, Yanwen wrote:
Has anyone seen this error when running valgrind 3.10.1 in a MIPS64
platform?
==1769== Valgrind's memory management: out of memory:
==1769==newSuperblock's request for 4194304 bytes failed.
==1769==22536192
On Fri, 2015-04-10 at 20:27 +, Zhu, Yanwen wrote:
Also, I just looked at online:
https://www.mail-archive.com/valgrind-users@lists.sourceforge.net/msg02027.html
Is it a permission problem?
It does not look like.
But in any case, it looks like you are running Valgrind as root.
This is very
On Fri, 2015-04-10 at 20:48 +, Zhu, Yanwen wrote:
From: Maurice van Swaaij [mailto:maur...@blueskystudios.com]
Sent: Friday, April 10, 2015 4:45 PM
To: Zhu, Yanwen
Cc: valgrind-users@lists.sourceforge.net; Philippe Waroquiers
Subject: Re: [Valgrind-users] valgrind out of memory error
On Thu, 2015-04-09 at 14:08 -0400, Atalay Ozgovde wrote:
This is essentially the same bug
as:https://bugs.kde.org/show_bug.cgi?id=278057
A patch was applied for this bug in version 3.7 and it is considered
fixed.
I am using version 3.10, I confirmed in the source code that the patch
is
On Fri, 2015-04-10 at 21:24 +, Zhu, Yanwen wrote:
Philippe,
Please see the attached file for
strace -f valgrind -v -v -v -d -d -d
output
The trace confirms that the mmap syscall is failing:
n64_write(--1953:1:main Starting the dynamic memory manager
) = 54
On Fri, 2015-04-10 at 21:39 +, Zhu, Yanwen wrote:
What argument should I give to strace in order to get syscall args?
No idea.
On my linux box, a normal strace gives the mmap args.
Try to look at
strace --help
or
man strace
Philippe
On Tue, 2015-04-07 at 23:10 +0100, João M. S. Silva wrote:
--db-attach=yes is deprecated in 3.10
and will be removed (sooner or later).
Better use the Valgrind gdbserver.
See
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
for more information.
On Sun, 2015-06-07 at 12:03 +, Andrei F wrote:
Hi guys,
I cannot connect to svn.valgrind.org. It just refuses connections.
Should it be still accessible?
For me, it works.
Philippe
--
On Thu, 2015-06-11 at 12:14 +0200, Julian Seward wrote:
I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
of 'mismatched free/delete' type messages all coming from std::string
shipped with GCC 4.8.3.
Do you see these 'mismatches free/delete' only with Valgrind
On Wed, 2015-06-10 at 19:09 +0100, David Carter wrote:
Hi,
I've recently switched over to Valgrind 3.10.1 and I'm now see vast
numbers of 'mismatched free/delete' type messages all coming from
std::string shipped with GCC 4.8.3.
I really don't believe what Valgrind is saying but I'd
On Wed, 2015-06-10 at 19:17 +0800, 王阳 wrote:
My answer is that helgrind really need more than 6 times or even more
memory than before ,is that true?
or helgrind have a bug?
The memory needed by helgrind might depend on what your program does.
Typically, it needs twice the original, but it might
On Wed, 2015-06-17 at 20:25 +0800, 王阳 wrote:
Before fixing the above, what you can do then is to capture
the statistics before it crashes, using from a shell:
vgdb v.info stats
and post the resulting output
(do the above when your application has already consumed a
significant
memory,
On Fri, 2015-06-12 at 07:23 +, Mayank Kumar (mayankum) wrote:
Hi Users
I am running valgrind on windriver and trying to use
RUNNING_ON_VALGRIND macro to figure out if my process is running under
valgrind.
While compiling I get the error :-
error: missing binary operator before token
What this message says is:
Thread 13 is freeing a piece of memory (0x09440060 of size 15).
This free operation can cause a race condition with some operation
done on the same memory by thread 12.
Drd then gives an approximate idea of where the conflicting operation
in thread 12 was. The
On Mon, 2015-05-25 at 12:41 +0100, Tom Hughes wrote:
On 25/05/15 12:26, Jack wrote:
so i wrote an test program on pc to test valgrind ability of program
internal memory breaking
but somehow it seems can't fetch program internal over-writing and
under-writing global or local valuable??
On Fri, 2015-08-07 at 10:36 -0400, Rich Prohaska wrote:
Hello,
I have observed that helgrind will report erroneous data races on a
variable if checking on that variable is disable and enabled by a
concurrent thread. Can someone explain what is going on?
VALGRIND_HG_ENABLE_CHECKING
On Wed, 2015-10-14 at 15:30 +0100, Adam Porteous wrote
> 1. I don't see any output on the console at all and can see that
> valgrind is nearly 100% CPU with the output from using top
> (hardware has 2 cores which explains the 48%):
> 6210 6190 root R16004 13% 0
On Thu, 2015-09-10 at 09:40 +0100, Mark Chimley wrote:
> Folks,
>
> This is hopefully a question with an easy answer. I've got a program
> which seems to cause heap corruption so I thought valgrind would be able
> to tell me where this occurs. The trouble is the program uses data files
> from the
On Sun, 2015-11-29 at 11:06 -0800, John Reiser wrote:
> > [[snip]]
> > * with valgrind 3.11 and gdb 7.10, gdb will automatically discover
> >the executable being debugged.
>
> gdb is likely to become confused if there is more than one candidate.
> Running two sessions side-by-side for A-B
On Sat, 2015-11-28 at 18:42 +0100, Maurice van der Pot wrote:
> Unfortunately the removal of --db-attach seems to make things less
> convenient.
Yes, for simple examination of the error context of one single thread,
--db-attach=yes was easy.
I am not completely sure how straightforward it would
On Mon, 2015-12-07 at 00:08 +0800, yoma sophian wrote:
> I attach the pic, massif_test.png I got from massif-visualizer, and in
> the pic, the heap allocated by main will decreased to 0.
> But f and g these 2 functions will not.
> What makes me curious is I cannot find the free information in the
On Tue, 2015-12-08 at 14:39 -0800, Nikolaus Rath wrote:
> $ valgrind --version
> valgrind-3.8.1
This is more than 3 years old.
Would be (much) better to upgrade to the last version (3.11).
In any case, if the problem is related to inlining, you need
a recent valgrind version to see it (inlining
On Tue, 2015-12-08 at 09:08 -0800, Nikolaus Rath wrote:
> Hello,
>
> I'm having a problem using massif. When looking at the ms_print output, I'm
> getting entries like this:
>
> ->10.77% (11,146,544B) 0xF4AC9C: H5FL_reg_calloc (in
>
On Mon, 2015-12-07 at 11:49 +0800, yoma sophian wrote:
> I use vgdb and try to create snapshop with command, "monitor
> detailed_snapshot xxx"
> No matter I create snapshop before mmap or after mmap, I hightlight in
> the below program, there is still no mmap information in the detail
> snapshop
On Wed, 2015-12-09 at 10:32 -0800, Nikolaus Rath wrote:
> On 12/09/2015 10:00 AM, Nikolaus Rath wrote:
> Interestingly enough, but stacktraces are incorrect: gdb is missing the call
> to taehdf5_mp_h5append_data_double_0d_,
> and valgrind is missing the call to h5dump_attr_int.
The missing
On Wed, 2015-12-09 at 13:41 -0800, Nikolaus Rath wrote:
> I believe this is the relevant objdump output - but again I don't understand
> it. Does it tell you anything?
>
> <1>: Abbrev Number: 42 (DW_TAG_subprogram)
>DW_AT_decl_line : 1916
>DW_AT_decl_file : 1
>
On Wed, 2015-12-09 at 22:59 +0100, Philippe Waroquiers wrote:
> If this is not recorded, then it is the valgrind dwarf reader that likely has
> a problem.
> Otherwise, it is the unwinder which does not properly use the inline info.
What you can also do is to use
(gdb) monitor v.info
On Wed, 2015-12-09 at 10:32 -0800, Nikolaus Rath wrote:
> (gdb) bt
> #0 0x01010750 in H5FL_reg_calloc ()
> #1 0x00fa64ea in H5A_create ()
> #2 0x00fa0611 in H5Acreate2 ()
> #3 0x00f8f3be in h5acreate_c_ ()
> #4 0x00f897b7 in h5a_mp_h5acreate_f_ ()
> #5
On Thu, 2015-12-10 at 11:06 -0800, Nikolaus Rath wrote:
> On 12/10/2015 10:20 AM, Matthias Schwarzott wrote:
> > Am 09.12.2015 um 22:10 schrieb Nikolaus Rath:
> >>
> >> Yes. But that makes it even more confusing to me: apparently gdb picks
> >> up the debug information about the inlined function
On Thu, 2015-12-10 at 13:20 -0800, Nikolaus Rath wrote:
> So the answer is then that massif simply does not support inlined calls?
Effectively, today, massif does not support outputting inlined calls.
pp_snapshot_SXPt in ms_main.c has to be modified to print inlined
function calls.
Philippe
On Sun, 2015-12-13 at 20:43 +0800, yoma sophian wrote:
> hi Philippe:
> I compile the trunk valgrind with ur patch, but I still cannot see the
> location of mmap I put in the c file, even I set the --threshold=0.0.
> (I attach the c file and mass output as well)
--threshold indicates the
On Mon, 2015-12-07 at 00:05 +0100, Philippe Waroquiers wrote:
> I think there is a bug in the massif logic to make a peak detailed
> snapshot at the moment of munmap: it should try to produce a peak
> snapshot when releasing the first page of munmap, not when releasing
> the last pa
On Fri, 2016-01-08 at 15:35 -0700, Jon Stephens wrote:
> Hello all,
> I am a student at the University of Arizona doing research with Dr.
> Debray relating to computer security. We have been discussing a way to
> automatically generate taint propagation policies for a given x86
> instruction. This
On Mon, 2015-11-23 at 23:18 +0800, yoma sophian wrote:
> hi all:
> I have some questions about massif:
> 1. from massif.out file, I cannot tell where the free is called
> I compile the sample code in the document page as below and get
> the massif output. From the log, there are messages about
On Wed, 2015-11-25 at 13:32 +0800, yoma sophian wrote:
> hi philippe
>
> > massif does not provide information about where memory was freed.
> > It shows the memory used by your program, and where it was allocated.
> >
> > For what reason do you want to know where some memory was freed ?
> if
On Wed, 2016-06-01 at 10:19 -0700, John Reiser wrote:
> On 06/01/2016, Marshall Lochbaum wrote:
> >>From my perspective I have attempted to use Valgrind as intended, and it
> > fails to provide the single most important piece of information for
> > diagnosing a use-after-free error. I'm having
In general, there should be no problem to use Valgrind on
code/executable produced by clang (or whatever other compiler).
Yes, the problem below seems to be related to the fact that you are
using at the same time valgrind and ASan.
If you want to use valgrind, then you should compile without
On Thu, 2016-02-04 at 08:54 +0100, Florian Krohm wrote:
> On 03.02.2016 21:50, Philippe Waroquiers wrote:
> >
> > The assert might be caused by the debuginfo containing a string bigger
> > than SEGINFO_STRPOOLSIZE (64Kb).
>
> Why exactly are we having yet another fix
On Fri, 2016-02-05 at 11:20 +0100, David Hallas wrote:
> thanks for the reply. I tried increasing the SEGINFO_STRPOOLSIZE as
> you requested, and for me the magic number is 268*1024 then the assert
> goes away :) I also tried to add the print to the ML_(addStr) function
> in storage.c but for
On Thu, 2016-01-28 at 02:19 +0900, ISHIKAWA,chiaki wrote:
> c++11 runtime seems to use |new| operation to create some data in a very
> primitive internal string handling function, and these string data are
> "free"ed by many other functions that my application (mozilla
> thunderbird) use. So
On Wed, 2016-02-03 at 20:45 +0100, David Hallas wrote:
> valgrind: m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion
> 'eltSzB <= ddpa->poolSzB' failed.
> I am running on a 64bit Linux system, and the binary is compiled using
> clang-3.7.
> Can anyone give some pointers as to what might
On Mon, 2016-02-22 at 22:16 -0500, Jim wrote:
> 2. run with --leak-check=no
> do we still see a SEGV ?
>
> Yes, problem still persists. Still a SEGV with the same error stack
> track from memcheck.
So, this indicates that what you see is not related to the bug 353891
which was solved with
On Mon, 2016-02-22 at 13:26 -0500, Jim wrote:
> I'd appreciate any input on helping me track this error down. Is this
> a problem with valgrind, or with my program? Please let me know if
> there's more information I should post.
Can you do the following 4 trials and attach the resulting logs
to
Hello!
You have a new message, please read <http://calldoctorcare.com/display.php?dl27>
Philippe Waroquiers
--
Find and fix application performance issues faster with Applications Manager
Applications M
On Fri, 2016-07-08 at 14:38 +0300, Stepan Zakharov wrote:
> Thanks. I will look into that option.
Yes, callgrind and kcachegrind are very easy to use/very precise/...,
but the price to pay is the slowness.
Other profilers having much less overhead might be good enough.
> But I can also split my
On Mon, 2016-08-29 at 07:28 -0700, Mark Roberts wrote:
> The C/C++ front end to our tool Daikon includes most of Valgrind’s
> memcheck code. We monitor the execution of a user’s program and
> record the values seen for various program variables. As we follow
> pointer variables, we need to make
On Fri, 2016-09-16 at 15:37 +, 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,
>
On Wed, 2016-09-07 at 10:23 +0200, Julian Seward wrote:
> Yes, I have seen AVX-512 looming on the horizon for a while. Yes, we
> should support it. Dealing with AVX/AVX2 was a lot of work, and there is
> not much AVX-512 available hardware out there, which may explain the
> relative lack of
On Thu, 2016-11-03 at 15:36 -0700, Patrick J. LoPresti wrote:
> Right now, if I have code like this:
> int a; /* invalid value */
> int b = a + 1; /* operation on invalid value */
> ...memcheck does not produce a warning for the addition. It just
> taints b as invalid and only generates a
On Fri, 2016-11-04 at 16:16 +0100, Julian Seward wrote:
> On 04/11/16 16:04, Nicholas Lamb wrote:
> > Does anyone know the maximum verbosity level supported by Valgrind?
>
> 2 or 3. Not sure now. You can also get tons of internal debugging info
> with -d or -d -d etc.
Note you can put a lot of
On Mon, 2016-10-24 at 12:50 +0800, p4759521 wrote:
> I want to check my program with valgrind, but my program nerver exit
> by self. so how to check the program memory leak?
>
>From another shell, you can use vgdb to (a.o.) trigger a leak search.
For example, to output all detailed info about
On Wed, 2016-11-02 at 09:12 +0800, 雨若冰 wrote:
> Hi!
> I'm trying to use valgrind to test memory leak.When I use "valgrind
> --leak-check=full ./**(my project name)",there will occur the
> question.-->setrlimit error ,errcode= 1.The program stops here and
> circles the error.
> If I # the
On Wed, 2016-12-07 at 15:17 +0800, Datong Li wrote:
> So I guess this error maybe cause by hugepage when use valgrind.
> Does anybody know something about this?
Which version of valgrind are you using ?
Which platform (OS, distro, ...) ?
Support of huge page is supposed to work since valgrind
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 Wed, 2017-01-04 at 13:43 +0100, frank_w...@web.de wrote:
> Happy new year!
>
>
> Am 08.12.2016 14:34 schrieb John Reiser:
> > [...]
> > Most of the time? Then run valgrind under gdb, get the traceback
> > at the time of the SIGSEGV, and file a bug report against valgrind.
> > $ gdb
No sign of any tilegx user or developer activity since something like
one year.
No reply received for question in
https://sourceforge.net/p/valgrind/mailman/message/35566192/
Is there any tilegx user or developer still active ?
Should we consider this platform as dead ?
Philippe
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
On Thu, 2017-01-05 at 10:44 +0100, Gabriel Gritsch wrote:
> I am unable to compile on Mac OS X 10.11.6
Problem was already reported on this list the 23 of December,
a bypass/solution was given by John Reiser.
Here is a copy:
> Undefined symbols for architecture x86_64:
>
> "___bzero",
On Thu, 2016-12-22 at 12:22 +0100, David Faure wrote:
> Any idea why this is happening?
>
> gcc (SUSE Linux) 4.8.5
> valgrind-3.13.0.SVN
> glibc-2.22-3.7.x86_64
> `uname -a` = Linux 4.4.36-8-default #1 SMP Fri Dec 9 16:18:38 UTC 2016
> (3ec5648) x86_64 x86_64 x86_64 GNU/Linux
> OpenSuSE Leap
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
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
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
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 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.
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 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.
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
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?
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
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
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
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
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-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 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 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:
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
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:
>
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 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
> 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 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)
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
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
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
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 &
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
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
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
>
201 - 300 of 365 matches
Mail list logo
