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
--- 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 Makefile
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
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=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 #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=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
Bug ID: 472402
Summary: memcheck "make tests" build fails: filter_sized_delete
missing
Classification: Developer tools
Product: valgrind
Version: unspecified
Platform:
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=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
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=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
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:
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=416436
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #1 from John
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 being
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=368923
John Reiser changed:
What|Removed |Added
CC||jrei...@bitwagon.com
--- Comment #4 from John
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=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 replicat
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
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 #3 from John Reiser ---
Created attachment 115241
--> https://bugs.kde.org/attachment.cgi?id=115241=edit
console output with --trace-flags
valgrind --trace-flags=1001 --trace-notbelow=108 ./foo 2>&1 | more
--
You are
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=edit
console output of plain memcheck
Note parameter --smc-check=all as an attempt to check carefully for non-static
code.
--
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=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=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
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=edit
.rodata*: aggregate multiple adjacent sections after alignment
Revise (and obsolete) the previous patch because of the interven
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=344802
John Reiser changed:
What|Removed |Added
Attachment #101694|0 |1
is obsolete
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=396001
John Reiser changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
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
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=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=393023
Bug ID: 393023
Summary: callgrind_control risks using the wrong vgdb
Product: valgrind
Version: 3.13 SVN
Platform: unspecified
OS: Linux
Status: UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=384230
John Reiser <jrei...@bitwagon.com> changed:
What|Removed |Added
CC||jrei...@bitwag
https://bugs.kde.org/show_bug.cgi?id=353802
--- Comment #12 from John Reiser <jrei...@bitwagon.com> ---
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 watchi
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 #11 from John Reiser <jrei...@bitwagon.com> ---
Created attachment 110638
--> https://bugs.kde.org/attachment.cgi?id=110638=edit
proposed workaround patch: read_elf_debug_info accepts contiguous .rodata*
This patch
https://bugs.kde.org/show_bug.cgi?id=353802
--- Comment #10 from John Reiser <jrei...@bitwagon.com> ---
This problem has re-appeared using GCC 8.x on Solaris 11.3 under valgrind git
tip:
commit dcb83cf846b529104cd528cd749b61f35deda476
Author: Rhys Kidd <rhysk...@gmail.com>
https://bugs.kde.org/show_bug.cgi?id=388664
--- Comment #1 from John Reiser <jrei...@bitwagon.com> ---
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-
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
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
https://bugs.kde.org/show_bug.cgi?id=385868
John Reiser <jrei...@bitwagon.com> changed:
What|Removed |Added
CC||jrei...@bitwag
https://bugs.kde.org/show_bug.cgi?id=384729
--- Comment #1 from John Reiser <jrei...@bitwagon.com> ---
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 tha
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
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=384442
--- Comment #3 from John Reiser <jrei...@bitwagon.com> ---
Here is the output from "--trace-flags=1000", condensed and commented:
=
(arm) 0x49BD90C: mov r12, r13
(arm) 0x49BD910: stmdb r13!, {0xDFF0}
https://bugs.kde.org/show_bug.cgi?id=384442
--- Comment #2 from John Reiser <jrei...@bitwagon.com> ---
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:
https://bugs.kde.org/show_bug.cgi?id=384442
--- Comment #1 from John Reiser <jrei...@bitwagon.com> ---
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
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=383723
--- Comment #9 from John Reiser <jrei...@bitwagon.com> ---
> #if DARWIN_VERS >= DARWIN_10_11
> // NYI kevent_qos // 374
> #endif /* DARWIN_VERS >= DARWIN_10_11 */
Yes, that looks like a promisin
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #7 from John Reiser <jrei...@bitwagon.com> ---
> 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"/wh
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #5 from John Reiser <jrei...@bitwagon.com> ---
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-o
https://bugs.kde.org/show_bug.cgi?id=383723
--- Comment #3 from John Reiser <jrei...@bitwagon.com> ---
On 09/01/2017 09:18 AM, Andy wrote:
> https://bugs.kde.org/show_bug.cgi?id=383723
>
> --- Comment #2 from Andy <imol00+...@gmail.com> ---
> Is there anything el
https://bugs.kde.org/show_bug.cgi?id=383723
John Reiser <jrei...@bitwagon.com> changed:
What|Removed |Added
CC||jrei...@bitwag
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #10 from John Reiser <jrei...@bitwagon.com> ---
(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
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #9 from John Reiser <jrei...@bitwagon.com> ---
(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
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #8 from John Reiser <jrei...@bitwagon.com> ---
(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 ma
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #7 from John Reiser <jrei...@bitwagon.com> ---
(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_b
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:
https://bugs.kde.org/show_bug.cgi?id=381304
--- Comment #5 from John Reiser <jrei...@bitwagon.com> ---
(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 implementation
https://bugs.kde.org/show_bug.cgi?id=381304
--- Comment #4 from John Reiser <jrei...@bitwagon.com> ---
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
https://bugs.kde.org/show_bug.cgi?id=381304
--- Comment #3 from John Reiser <jrei...@bitwagon.com> ---
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
https://bugs.kde.org/show_bug.cgi?id=381304
--- Comment #2 from John Reiser <jrei...@bitwagon.com> ---
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(),
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #4 from John Reiser <jrei...@bitwagon.com> ---
(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 "cros
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #3 from John Reiser <jrei...@bitwagon.com> ---
(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?
https://bugs.kde.org/show_bug.cgi?id=381326
--- Comment #1 from John Reiser <jrei...@bitwagon.com> ---
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
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=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:
https://bugs.kde.org/show_bug.cgi?id=381299
John Reiser <jrei...@bitwagon.com> changed:
What|Removed |Added
Status|UNCONFIRMED |RE
https://bugs.kde.org/show_bug.cgi?id=381299
--- Comment #2 from John Reiser <jrei...@bitwagon.com> ---
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
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
https://bugs.kde.org/show_bug.cgi?id=377966
--- Comment #3 from John Reiser <jrei...@bitwagon.com> ---
(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, d
https://bugs.kde.org/show_bug.cgi?id=377966
John Reiser <jrei...@bitwagon.com> changed:
What|Removed |Added
Summary|disInstr(arm64): unhandled |disInstr(arm64): unh
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
https://bugs.kde.org/show_bug.cgi?id=377006
--- Comment #9 from John Reiser <jrei...@bitwagon.com> ---
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
https://bugs.kde.org/show_bug.cgi?id=377006
John Reiser <jrei...@bitwagon.com> changed:
What|Removed |Added
CC||jrei...@bitwag
https://bugs.kde.org/show_bug.cgi?id=360752
--- Comment #5 from John Reiser <jrei...@bitwagon.com> ---
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 th
https://bugs.kde.org/show_bug.cgi?id=360752
John Reiser <jrei...@bitwagon.com> changed:
What|Removed |Added
CC||jrei...@bitwag
80 matches
Mail list logo
