On Sat, Aug 15, 2020 at 10:59 AM John Reiser wrote:
>
> The fact that you write '0xc018786f' here, but '3222829167' in the code,
> shows that you are not sufficiently paranoid. First, if the bit pattern
is important
> then you should write hex. If you insist on decimal, then you should
write '32
> If I run strings against the valgrind binary, I see the full pathname to
> valgrinds library …/output/debug/valgrind/install/lib/valgrind which of
> course is not right, it needs to be /lib/valgrind.
FWIW, I have had no problem relocating a Valgrind installation tree
and then setting the VALGR
I believe Helgrind does not understand modern GCC implementations of the
Meyers Singleton. You will see similar warnings for any non-trivial static
object.
See e.g. https://stackoverflow.com/q/44698412/
I vaguely recall this was discussed here before and deemed "hard to fix".
But I cannot seem to
Thank you, John and Phillippe, for your replies.
First, to John:
Valgrind actually does know that a conditional move is a functional
operation and not a conditional branch. So if you can convince your
compiler to emit conditional moves, Valgrind will simply "taint" the output
instead of emitting
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 warning if I try to use b in a
behavior-changing way. This is good, and it
On Thu, Oct 6, 2016 at 8:53 AM, Alex Bligh wrote:
>
>
> > On 6 Oct 2016, at 16:06, Mateusz Jemielity
wrote:
> >
> > The effects are equivalent to pthread_rwlock_init, thus in my opinion
they
> > require pthread_rwlock_destroy.
>
> However, I'm not sure why you'd need to call pthread_*_destroy on
On Thu, Aug 13, 2015 at 10:28 AM, Jeffrey Walton wrote:
>
> And converting the file-scoped globals into locals with accessors
> suffers the same problem on the destructor side.
Not true. The C++ spec guarantees destructors will run in the opposite
order of constructors in most cases. The Meyers S
On Mon, Sep 15, 2014 at 4:52 PM, Tom Hughes wrote:
>
> So I think the original diagnosis stands, that the C library is too old to
> know about this flag.
Fair enough. In which case Valgrind's conditional should perhaps be on
__GLIBC__ / __GLIBC_MINOR__ rather than VGA_s390x?
I can confirm PTRACE
PTRACE_GETSIGINFO definitely exists on SLES10 SP3 64-bit:
suse10$ cat /etc/issue
Welcome to SUSE Linux Enterprise Server 10 SP3 (x86_64) - Kernel \r (\l).
suse10$ find /usr/include -type f | xargs grep PTRACE_GETSIGINFO
/usr/include/linux/ptrace.h:#define PTRACE_GETSIGINFO 0x4202
sus
On Mon, Jun 9, 2014 at 12:53 AM, Bart Van Assche wrote:
>
> I think g++ will have to be modified to allow Helgrind and DRD to
> recognize thread-safe statics on architectures that do not have relaxed
> memory consistency. From the gcc source file gcc/cp/decl.c I derived
> that on architectures wit
On Wed, Jan 22, 2014 at 1:36 PM, Philippe Waroquiers
wrote:
>
> The gcc documentation says for -mfpmath=sse:
>
> The resulting code should be considerably faster in the majority of
> cases and avoid the numerical instability problems of 387 code, but
> may break some existing code that expec
On Tue, Jan 14, 2014 at 7:18 AM, Samuel Quiring
wrote:
>
> Will valgrind evaluate the shell script or my app or both?
The script, and as others have said, "--trace-children=yes" will do
what you want. However...
...you can also change your script to "exec" your app. That is better
style anyway (
On Fri, Aug 16, 2013 at 8:33 AM, cleca wrote:
> == PASTE of parts of the complaints ==
> Invalid read of size 8
> ==19525==at 0x6E6E2CA: ??? (in
> /home/cap/workspace/kademlia2/libs/libc.so.6)
You will get better backtraces if you install the "glibc-debuginfo"
package. (Assuming you are us
On Mon, May 13, 2013 at 6:46 AM, Gonzalo wrote:
> ==8527== Process terminating with default action of signal 11 (SIGSEGV)
> ==8527== Access not within mapped region at address 0xBEF3EDA4
> ==8527==at 0x8091CD0: WriteFiasco(std::string const&) (fiasco_finder.h:28)
> ==8527==by 0x43F810D:
On Thu, Mar 14, 2013 at 1:58 PM, Philippe Waroquiers
wrote:
> On Thu, 2013-03-14 at 19:21 +, Phil Longstaff wrote:
>> How hard would it be for memcheck to not report a block as being
>> potentially lost if the internal pointer could be a pointer to a base
>> class? Is there sufficient info in
On Mon, Dec 31, 2012 at 4:48 AM, Philippe Waroquiers
wrote:
>
> It is even not ok to use an atomic instruction : first tests have
> shown that having one atomic instruction on this path makes a
> multi-threaded Valgrind slower than a serialised Valgrind.
You mean a multi-threaded Valgrind is slow
On Wed, Dec 5, 2012 at 10:29 AM, Leif Walsh wrote:
> Here are the threads I have:
>
> {
> pthread_rwlock_rdlock();
> x = 1;
> pthread_rwlock_rdunlock();
> }
>
> {
> pthread_rwlock_wrlock();
> if (x) {
> x = 0;
> } else {
> foo();
> }
> pthread_rwlock_wrunlock();
> }
I am g
On Tue, Dec 4, 2012 at 7:24 AM, Leif Walsh wrote:
>
> I'm ashamed to say I don't quite understand
The first step to enlightenment
> what can fail here but I'm not worried until I start supporting such
> architectures. Thanks for the warning though.
It is not only about future architectures; it
On Tue, Oct 2, 2012 at 9:16 AM, John Reiser wrote:
>
> Not necessarily.
Yes, necessarily.
> In *your* favorite "modern" CPU, a transfer of control
> to a non-local destination can cost 15 times as much as a local test-and-
> skip-over, depending on branch prediction and Icache misses.
True but
On Tue, Oct 2, 2012 at 5:55 AM, jody wrote:
>
>
> -
> void CellGrid::destroyGrid() {
>
> if (m_apCells != NULL) {
> for (coord j = 0; j < m_iNumCells; j++) {
> if (m_apCells[j] != NULL) {
> delete m_apCells[j];
>
On Sun, Aug 26, 2012 at 2:06 AM, David Faure wrote:
>
> Marc Mutz said "
> The standard says it's racy, but the implementation of
> std::atomic::load(memory_order_acquire) won't look different. Simple reads
> and writes on x86 are already sequentially consistent.
I do not think this is true. Loa
On Mon, Aug 13, 2012 at 8:54 AM, John Reiser wrote:
>
> In the case at hand, we are interested in string operations, not floating
> point.
> Suppose that stpncpy contributes 0.25% (1/400) of the normal running time.
> Then
> instruction-by-instruction emulation of stpncpy by memcheck is about 20
On Mon, Aug 13, 2012 at 1:07 AM, Julian Seward wrote:
>
> I lose track of what is actually required. Is it to implement, for
> vector loads, the same thing that you did for scalar loads? That is,
> don't complain about naturally aligned word size loads that partially
> overlap the end of a bloc
On Sun, Aug 12, 2012 at 7:10 PM, John Reiser wrote:
> On 08/12/2012 06:44 PM, Patrick J. LoPresti wrote:
>
> > Or, you know, we could instead spend effort fixing Valgrind's machine
> emulator to match the memory model of real machines.
>
> Your idea of "real m
On Sun, Aug 12, 2012 at 1:44 PM, John Reiser wrote:
>
> memcheck implements intercepting re-directs for both strcpy and strncpy.
> The re-directs remove the possibility of any false positive complaints,
> and also are significantly faster than emulating instructions.
> Therefore, I suggest that t
On Sun, Aug 12, 2012 at 11:03 AM, Philippe Waroquiers <
philippe.waroqui...@skynet.be> wrote:
> On Sun, 2012-08-12 at 19:15 +0200, Francis Giraldeau wrote:
>
>
> The best is to file a bug on bugzilla,
> with the test program to reproduce the false positive
> and additional details such as gcc vers
On Fri, Jul 27, 2012 at 8:13 AM, Florian Krohm wrote:
>
> The shared lib has no debug info. That's why you don't get a file name
> and line number. If math.so is your own shared object read this:
> http://valgrind.org/docs/manual/faq.html#faq.unhelpful
>
> If it is a system lib you need to instal
On Thu, Jul 26, 2012 at 11:12 AM, Sean McBride wrote:
>
> I think it's definitely worth a bug report. If nothing else, the man page
> should discuss whether a zero size is undefined behaviour or not.
The POSIX spec makes it pretty clear that this is not undefined behavior:
http://pubs.opengrou
On Wed, Jul 11, 2012 at 10:13 PM, Tanmay Mohapatra wrote:
> Thanks Pat.
> Here's the output of "otool -v -t check"
> Is this what is required?
> Do let me know if I need to disassemble in some other way.
Looks like the offending code is in a shared library (?)
Maybe try "gdb ./check", and then "
On Sun, Jul 8, 2012 at 11:00 PM, John Reiser wrote:
> In particular, there is a long and convoluted
> history of "word at a time" idioms (instead of simple "character at a time"
> code) for computing strlen() and strchr().
Also memcpy(), memcmp(), etc.
To elaborate a bit: An aligned load cannot
On Sat, Jul 7, 2012 at 9:58 PM, Tanmay Mohapatra wrote:
> Thanks John and Pat.
>
> So what I understand is I can ignore the warning in this case.
> But, I still get the warning even with --partial-loads-ok=yes. Why so?
Because this is an SSE-optimized routine.
The evidence is here:
> ==67529==
On Fri, Jul 6, 2012 at 11:45 AM, John Reiser wrote:
>
> The compiler has decided to generate inline code for memcpy.
> This is hard for memcheck to recognize as memcpy.
But memcheck does not have to recognize it at all if you use
"--partial-loads-ok=yes".
The problem is that the default memory m
On Thu, Jun 14, 2012 at 1:10 PM, Kevyn-Alexandre Paré
wrote:
>
> valgrind --leak-check=full --partial-loads-ok=yes ./test
>
> Adding the flag didn't remove the error?
Are you _sure_ it is exactly the same error? Your original report
said this was the error:
==21719== Invalid read of size 4
==2
John Reiser writes:
> It seems to me that there may be at least one set of cases where
> the memcheck complaint might be correct, namely if there is no '\0'
> in an allocated block whose length is not a multiple of 16.
If there is no `\0` in your string and you call strlen(), I agree we
need to i
Hello again, Valgrind community. I have filed the following bug report:
https://bugs.kde.org/show_bug.cgi?id=294285
(By the way, "3.8.0SVN" is not presently an option for the "Version"
drop-down when filing a bug.)
Background: I am using Valgrind on optimized SSE4.2 output from the
Intel C Comp
Hello. I downloaded the development version of valgrind from
Subversion today. It configured and built fine, but while trying to
run it on my application, I got this error during the run:
vex amd64->IR: unhandled instruction bytes: 0xC2 0x0 0x0 0x66 0x66
0x66 0x90 0x66
==10739== valgrind: Unreco
36 matches
Mail list logo
