https://bugs.kde.org/show_bug.cgi?id=455168
Bug ID: 455168
Summary: want/need more 'const' in Valgrind source code
Product: valgrind
Version: 3.20 GIT
Platform: Other
OS: Linux
Status: REPORTED
Severity: n
https://bugs.kde.org/show_bug.cgi?id=455168
--- Comment #2 from John Reiser ---
(In reply to Paul Floyd from comment #1)
> I get quite a few new warnings (there were perhaps 5 before, mostly void
> abuse and for x86)
Please specify the compiler name and version, and the command-line para
https://bugs.kde.org/show_bug.cgi?id=455168
--- Comment #4 from John Reiser ---
(In reply to Paul Floyd from comment #1)
> I get quite a few new warnings (there were perhaps 5 before, mostly void
> abuse and for x86)
When I process those warning lines using the shell pipeline
sort |
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #11 from John Reiser ---
This comment is to confirm that the bug still exists today 2024-06-24,
7 years after original filing.
Actually there are two bugs:
1) In the True branch after a test for Equality (==) then the Defined bits
https://bugs.kde.org/show_bug.cgi?id=487862
Bug ID: 487862
Summary: memcheck does not believe that bytes on new pages are
Defined by brk() system call
Classification: Developer tools
Product: valgrind
Version: 3.23.0
Pl
https://bugs.kde.org/show_bug.cgi?id=487862
--- Comment #2 from John Reiser ---
(In reply to Paul Floyd from comment #1)
> brk() is fairly old, removed from posix accordingly to the Linux manpage.
> Increasingly I see it getting removed from platforms.
In this case "old"
https://bugs.kde.org/show_bug.cgi?id=487862
--- Comment #5 from John Reiser ---
(In reply to Mark Wielaard from comment #4)
> So it seems reasonable for memcheck to assume the area exposed by brk() is
> undefined.
That assumption is incorrect for new pages on Linux, and there are applic
https://bugs.kde.org/show_bug.cgi?id=487862
--- Comment #8 from John Reiser ---
(In reply to Mark Wielaard from comment #6)
> BTW it seems this whole discussion is duplicated in the comments of
> memcheck/mc_main.c mc_post_clo_init ()
>// - The current inaccuracy has caused
https://bugs.kde.org/show_bug.cgi?id=384729
--- Comment #9 from John Reiser ---
Yes, the patch works, just like the handling of __gnu_cxx::__freeres(). Tested
on armv7hl.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=472402
--- Comment #6 from John Reiser ---
(In reply to Paul Floyd from comment #5)
> I always run autogen.sh whenever a Makefile.am changes
So the Makefile has two missing dependencies:
all: Makefile
Makefile: Makefile.am
./autogen.sh
and t
https://bugs.kde.org/show_bug.cgi?id=472402
--- Comment #8 from John Reiser ---
(In reply to Paul Floyd from comment #7)
> Here is what GCC's Makefile contains
Yes, valgrind should use essentially the same setup. In ancient times (pre-git)
there was a conceptual barrier that Makefil
https://bugs.kde.org/show_bug.cgi?id=476277
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #1 from John
https://bugs.kde.org/show_bug.cgi?id=472402
Bug ID: 472402
Summary: memcheck "make tests" build fails: filter_sized_delete
missing
Classification: Developer tools
Product: valgrind
Version: unspecified
Platform: Compile
https://bugs.kde.org/show_bug.cgi?id=472405
Bug ID: 472405
Summary: RFE: give Note about instructions on current hardware
that are not supported by VEX
Classification: Developer tools
Product: valgrind
Version: unspecified
https://bugs.kde.org/show_bug.cgi?id=472402
--- Comment #2 from John Reiser ---
Yes, this is part of a persistent local git clone, and I did run "./autogen.sh"
when I did the original clone. I have run several successful "git pull; make
-j4" since then, over a span of seve
https://bugs.kde.org/show_bug.cgi?id=472402
--- Comment #3 from John Reiser ---
The problem no longer appears in:
commit cb684b50e7d4d845b56abea72fd9b9925fed644e (HEAD -> master,
origin/master, origin/HEAD)
Date: Mon May 22 19:49:08 2023 +0200
after explicit "./autogen.sh"
https://bugs.kde.org/show_bug.cgi?id=472402
--- Comment #4 from John Reiser ---
(In reply to John Reiser from comment #3)
> The problem no longer appears in:
>commit cb684b50e7d4d845b56abea72fd9b9925fed644e (HEAD -> master,
> origin/master, origin/HEAD)
>Date: Mon May 2
https://bugs.kde.org/show_bug.cgi?id=461855
Bug ID: 461855
Summary: (wine xsavec64) vex amd64->IR: unhandled instruction
bytes: 0x48 0xF 0xC7 0xA1 0xC0 0x0 0x0 0x0 0x48 0xF
Classification: Developer tools
Product: valgrind
Versio
https://bugs.kde.org/show_bug.cgi?id=461855
--- Comment #2 from John Reiser ---
Further investigation reveals that this bug may be invalid. Also, the original
poster on the [valgrind-developers] mailing list omitted or did not emphasize
important details.
First, the OP used valgrind-3.15.0
https://bugs.kde.org/show_bug.cgi?id=384729
--- Comment #3 from John Reiser ---
I hit this again today using valgrind-3.15.0 when the default libc on the
target platform is glibc-2.29-12.fc30.aarch64 but the actual libc in the target
application is from Android 28.
__libc_freeres is not defined
https://bugs.kde.org/show_bug.cgi?id=377006
--- Comment #12 from John Reiser ---
Please run "uname -a" then copy+paste the entire output, and label with the
circumstances (3 cases: normal user, logged-in root, su from normal user to
root).
It's not obvious which kernels are b
https://bugs.kde.org/show_bug.cgi?id=406349
Bug ID: 406349
Summary: Android runtime linker ignores DF_1_INTERPOSE in
vgpreload_core-*
Product: valgrind
Version: 3.14.0
Platform: Android
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=368923
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #4 from John
https://bugs.kde.org/show_bug.cgi?id=416436
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #1 from John
https://bugs.kde.org/show_bug.cgi?id=396001
Bug ID: 396001
Summary: unhandled instruction: 0xEC51 0x0F1E; ARMv7 libcrypto
'mrrc'
Product: valgrind
Version: 3.13.0
Platform: Fedora RPMs
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=344802
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #15 from John
https://bugs.kde.org/show_bug.cgi?id=396001
John Reiser changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=344802
--- Comment #16 from John Reiser ---
(In reply to Matt Cowell from comment #13)
> Created attachment 101694 [details]
> Add decode for CNTVCT, CNTPCT, and CNTFRQ
Today the patch now lives at https://bugsfiles.kde.org/attachment.cgi?id=101694
an
https://bugs.kde.org/show_bug.cgi?id=344802
John Reiser changed:
What|Removed |Added
Attachment #101694|0 |1
is obsolete
https://bugs.kde.org/show_bug.cgi?id=344802
John Reiser changed:
What|Removed |Added
Attachment #113695|0 |1
is obsolete
https://bugs.kde.org/show_bug.cgi?id=390871
--- Comment #4 from John Reiser ---
Created attachment 113979
--> https://bugs.kde.org/attachment.cgi?id=113979&action=edit
.rodata*: aggregate multiple adjacent sections after alignment
Revise (and obsolete) the previous patch because
https://bugs.kde.org/show_bug.cgi?id=390871
--- Comment #6 from John Reiser ---
I believe that this bug and revised patch still are valid. The intervening
https://bugs.kde.org/show_bug.cgi?id=395682#c9 is a distinct issue regarding
.rodata for multiple segments. That bug does not address the
https://bugs.kde.org/show_bug.cgi?id=384230
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #10 from John
https://bugs.kde.org/show_bug.cgi?id=388084
Bug ID: 388084
Summary: armv7l Unrecognised instruction "bkpt" 0xE1200070
Product: valgrind
Version: 3.13.0
Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
S
https://bugs.kde.org/show_bug.cgi?id=388664
Bug ID: 388664
Summary: unhandled arm64-linux syscall: 117 (ptrace)
Product: valgrind
Version: 3.13.0
Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
Severi
https://bugs.kde.org/show_bug.cgi?id=388664
--- Comment #1 from John Reiser ---
THe complete complaint is
=
(gdb) run
Starting program: /usr/bin/date
--2479-- WARNING: unhandled arm64-linux syscall: 117
--2479-- You may be able to write your own handler.
--2479-- Read the file
https://bugs.kde.org/show_bug.cgi?id=393023
Bug ID: 393023
Summary: callgrind_control risks using the wrong vgdb
Product: valgrind
Version: 3.13 SVN
Platform: unspecified
OS: Linux
Status: UNCONFIRMED
Seve
https://bugs.kde.org/show_bug.cgi?id=353802
--- Comment #10 from John Reiser ---
This problem has re-appeared using GCC 8.x on Solaris 11.3 under valgrind git
tip:
commit dcb83cf846b529104cd528cd749b61f35deda476
Author: Rhys Kidd
Date: Sun Feb 11 17:16:38 2018 -0500
The re-appearance
https://bugs.kde.org/show_bug.cgi?id=353802
--- Comment #11 from John Reiser ---
Created attachment 110638
--> https://bugs.kde.org/attachment.cgi?id=110638&action=edit
proposed workaround patch: read_elf_debug_info accepts contiguous .rodata*
This patch compiles but is UNTESTED.
--
https://bugs.kde.org/show_bug.cgi?id=390871
Bug ID: 390871
Summary: ELF debug info reader confused with multiple .rodata*
sections
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=353802
--- Comment #12 from John Reiser ---
The re-appearance has been entered as separate bug report
https://bugs.kde.org/show_bug.cgi?id=390871 at the request of Ivo Raisr.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=399087
--- Comment #1 from John Reiser ---
Created attachment 115239
--> https://bugs.kde.org/attachment.cgi?id=115239&action=edit
target program, compressed by upx
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=399087
--- Comment #2 from John Reiser ---
Created attachment 115240
--> https://bugs.kde.org/attachment.cgi?id=115240&action=edit
console output of plain memcheck
Note parameter --smc-check=all as an attempt to check carefully for non-stat
https://bugs.kde.org/show_bug.cgi?id=399087
--- Comment #3 from John Reiser ---
Created attachment 115241
--> https://bugs.kde.org/attachment.cgi?id=115241&action=edit
console output with --trace-flags
valgrind --trace-flags=1001 --trace-notbelow=108 ./foo 2>&1 | mor
https://bugs.kde.org/show_bug.cgi?id=399087
Bug ID: 399087
Summary: memcheck escape from user code into memcheck itself
via computed goto
Product: valgrind
Version: 3.13.0
Platform: Fedora RPMs
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=399087
--- Comment #4 from John Reiser ---
Executions were on Fedora 29 beta using valgrind-3.13.0-28.fc29.armv7hl.rpm.
The same result was obtained using Fedora 28 (released, prior version of OS)
with the same valgrind rpm.
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=399087
--- Comment #7 from John Reiser ---
The root cause is a symlink vulnerability! coregrind fails to do the right
thing when the target executes
int fd_i_am = open("/proc/self/exe", O_RDONLY);
upx uses mmap(fd_i_am,) to replicate porti
https://bugs.kde.org/show_bug.cgi?id=395434
Bug ID: 395434
Summary: valgrind XML output should setlinebuf() to facilitate
online use
Product: valgrind
Version: 3.14 SVN
Platform: unspecified
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=377006
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #5 from John
https://bugs.kde.org/show_bug.cgi?id=385868
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #4 from John
https://bugs.kde.org/show_bug.cgi?id=384681
Bug ID: 384681
Summary: PUT(pc, ) should specialize to help
debugging
Product: valgrind
Version: 3.13 SVN
Platform: Compiled Sources
OS: Linux
Status:
https://bugs.kde.org/show_bug.cgi?id=384729
Bug ID: 384729
Summary: __libc_freeres inhibits cross-platform valgrind
Product: valgrind
Version: 3.13.0
Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
Sev
https://bugs.kde.org/show_bug.cgi?id=384729
--- Comment #1 from John Reiser ---
If __libc_freeres is used by some library function that is invoked by
vgpreload_core-arm-linux.so then vgpreload should implement such a function
itself, with an implementation that does the explicit lookup and
https://bugs.kde.org/show_bug.cgi?id=377006
--- Comment #9 from John Reiser ---
It looks to me like some part of the problem arises when memcheck is working on
the driver for the video graphics card. This suggests a cause for
non-determinism, and also a reason for different behavior on
https://bugs.kde.org/show_bug.cgi?id=377966
Bug ID: 377966
Summary: disInstr(arm64): unhandled instruction 0xD50B7425
Product: valgrind
Version: 3.12.0
Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
S
https://bugs.kde.org/show_bug.cgi?id=377966
John Reiser changed:
What|Removed |Added
Summary|disInstr(arm64): unhandled |disInstr(arm64): unhandled
https://bugs.kde.org/show_bug.cgi?id=377966
--- Comment #3 from John Reiser ---
(In reply to Julian Seward from comment #1)
> The main difficulty is to know how big the cache line is.
The value (and validity) is reported by the instruction "mrs reg, dczid_el0".
So valgrind coul
https://bugs.kde.org/show_bug.cgi?id=383723
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #1 from John
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #3 from John Reiser ---
On 09/01/2017 09:18 AM, Andy wrote:
> https://bugs.kde.org/show_bug.cgi?id=383723
>
> --- Comment #2 from Andy ---
> Is there anything else I can provide to help with this? I'm afraid actually
>
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #5 from John Reiser ---
The crash looks very similar to the 'ud2' diagnosed in the original
Description. In particular, the offset 0xb50 is the same. This probably
indicates that valgrind has more-or-less completely missed s
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #7 from John Reiser ---
> dtrace: system integrity protection is on, some features will not be
> available
You must disable that system integrity protection (that's why the
spawn/"execve"/whatever failed.) It'
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #9 from John Reiser ---
> #if DARWIN_VERS >= DARWIN_10_11
> // NYI kevent_qos // 374
> #endif /* DARWIN_VERS >= DARWIN_10_11 */
Yes, that looks like a promising clue.
You have now reached the p
https://bugs.kde.org/show_bug.cgi?id=384442
Bug ID: 384442
Summary: ARM: bad pc in complaint if instruction changes pc
Product: valgrind
Version: 3.13 SVN
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=384442
--- Comment #1 from John Reiser ---
Both problems can be solved by a special case for 'ldmdb' (LoaD Multiple
registers, Decrementing the address Before each fetch). If either r15(==pc) or
r13(==sp) is to be loaded, then assign the new
https://bugs.kde.org/show_bug.cgi?id=384442
--- Comment #2 from John Reiser ---
Context: [valgrind-users] by Kacper Kowalski on 2017-08-31 and replies through
the following week.
*
processor: 0
model name: ARMv7 Processor rev 10 (v7l)
BogoMIPS: 132.00
Features: half thumb
https://bugs.kde.org/show_bug.cgi?id=384442
--- Comment #3 from John Reiser ---
Here is the output from "--trace-flags=1000", condensed and commented:
=
(arm) 0x49BD90C: mov r12, r13
(arm) 0x49BD910: stmdb r13!, {0xDFF0}
(arm) 0x49BD914: sub r11,
https://bugs.kde.org/show_bug.cgi?id=381299
Bug ID: 381299
Summary: false uninit on new page via sbrk(n)
Product: valgrind
Version: 3.13 SVN
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Severit
https://bugs.kde.org/show_bug.cgi?id=381299
--- Comment #2 from John Reiser ---
I believe that the test case takes appropriate care so that the memory read
access via "*(int *)p2" is to a new page. The "rounded up", and always
incrementing the brk(), and never decrementi
https://bugs.kde.org/show_bug.cgi?id=381299
John Reiser changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=381304
Bug ID: 381304
Summary: RFE: --track-origins=yes identifies system call source
of Uninitialized value
Product: valgrind
Version: 3.13 SVN
Platform: Other
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=381326
Bug ID: 381326
Summary: recognize re-convergent fanout before complaining
about Uninitialized
Product: valgrind
Version: 3.13 SVN
Platform: Other
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #1 from John Reiser ---
Using reasoning that is similar to that the NOT_EQUAL operator (not_equal in
any bit position that is initialized, implies not_equal in the whole word,
regardless of uninit bits in other positions), then the "
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #3 from John Reiser ---
(In reply to Julian Seward from comment #2)
> for (z=p; n; n--, z++) if (*z) *z=0;
>
> What is the point of this? Why not just assign zeroes unconditionally?
> Is this some game w
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #4 from John Reiser ---
(In reply to John Reiser from comment #1)
More generally, when memcheck complains about uninit in a test for equality
between variables, then the Valid bits should "cross-pollinate":
if (a == b) { //
https://bugs.kde.org/show_bug.cgi?id=381304
--- Comment #2 from John Reiser ---
The system routines in musl libc (https://www.musl-libc.org/) are coded with
the system call instruction as a common tail.
The system call which produces uninit values is brk()/sbrk(), which libmusl
invokes from
https://bugs.kde.org/show_bug.cgi?id=381304
--- Comment #3 from John Reiser ---
Another syscall that produces uninit is readlink(). The portion of the result
buffer that is beyond the returned length, should be regarded as Uninit. There
is no guarantee that the kernel avoids writing into any
https://bugs.kde.org/show_bug.cgi?id=381304
--- Comment #4 from John Reiser ---
read_length = read(fd, buf, buflen) should regard buf[read_length, buflen) as
Uninit when there is no error. When there is an error, then ALL of buf[0,
buflen) should be regarded as Uninit. This is particularly
https://bugs.kde.org/show_bug.cgi?id=381304
--- Comment #5 from John Reiser ---
(In reply to John Reiser from comment #3)
> There is no guarantee that the kernel avoids writing into any
> portion of the whole buffer, although all known implementations write only
> an initial st
https://bugs.kde.org/show_bug.cgi?id=382099
Bug ID: 382099
Summary: valgrind release archive is not maintained
Product: valgrind
Version: 3.13 SVN
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: no
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #7 from John Reiser ---
(In reply to Julian Seward from comment #6)
> In particular I am trying to figure out if this can somehow be used to avoid
> the problems shown at
> https://bugs.llvm.org//show_bug.cgi?id=12319
>
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #8 from John Reiser ---
(In reply to Julian Seward from comment #5)
> What's the underlying insight
> here? In particular, why is it the case that knowing the two operands are
> equal allows us to mark the operands as mor
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #9 from John Reiser ---
(In reply to John Reiser from comment #8)
> The underlying principle is that it can be useful to view "a bit is
> initialized" as equivalent to "the cardinality of the set of possible
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #10 from John Reiser ---
(In reply to John Reiser from comment #8)
> The underlying principle is that it can be useful to view "a bit is
> initialized" as equivalent to "the cardinality of the set of possible
https://bugs.kde.org/show_bug.cgi?id=483711
--- Comment #7 from John Reiser ---
Current state with fixed the shell script, re-configure, and re-build:
export CC=$HOME/bin/my_gcc_32_or_64
export CXX=$HOME/bin/my_g++_32_or_64
./configure --prefix=$HOME/local
= my_gcc_32_or_64
#! /bin/bash
https://bugs.kde.org/show_bug.cgi?id=483711
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #6 from John
https://bugs.kde.org/show_bug.cgi?id=500979
Bug ID: 500979
Summary: botch of 'notrack' prefix for i386
Classification: Developer tools
Product: valgrind
Version: 3.24.0
Platform: Other
OS: Linux
Status: REPORTED
https://bugs.kde.org/show_bug.cgi?id=360752
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #3 from John
https://bugs.kde.org/show_bug.cgi?id=360752
--- Comment #5 from John Reiser ---
For psinfo, I see that it changes, so I guess that needs a permanent fd.
For cmdline and auxv, it still looks to me as if the separate fd could be
avoided nearly all the time, because the vast majority of processes
88 matches
Mail list logo
