https://bugs.kde.org/show_bug.cgi?id=418756
Bug ID: 418756
Summary: MAP_FIXED_NOREPLACE mmap flag unsupported
Product: valgrind
Version: 3.15 SVN
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
https://bugs.kde.org/show_bug.cgi?id=398445
Bug ID: 398445
Summary: uninitialized memory false reports on shared memory
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=398445
Stas Sergeev changed:
What|Removed |Added
Version|unspecified |3.13.0
--
You are receiving this mail because
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #2 from Stas Sergeev ---
Created attachment 114889
--> https://bugs.kde.org/attachment.cgi?id=114889&action=edit
2-process test-case
Hi, thanks for your reply.
Here is the test-case that does the same
thing but with 2 processes
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #4 from Stas Sergeev ---
Created attachment 114906
--> https://bugs.kde.org/attachment.cgi?id=114906&action=edit
2 processes and VALGRIND_MAKE_MEM_DEFINED
(In reply to Philippe Waroquiers from comment #3)
> It is not very c
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #5 from Stas Sergeev ---
Think of the following use-case.
Consider a very silly shm IPC that
uses just one large struct with many
input and output fields. Client fills
in the output fields and copies the
entire struct to the shm buffer
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #8 from Stas Sergeev ---
(In reply to Philippe Waroquiers from comment #7)
> If mmap would necessarily zero out memory, then
> that would create major difficulties to use
> shared memory.
> I think that what the kernel guaran
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #9 from Stas Sergeev ---
(In reply to Ivo Raisr from comment #6)
> Yes, indeed. That's why we have syscall and ioctl wrappers in Valgrind.
> They describe what the other side (kernel) expects from the buffers sent
> there
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #11 from Stas Sergeev ---
(In reply to Philippe Waroquiers from comment #10)
> If you declare the memory initialised before forking,
> using VALGRIND_MAKE_MEM_DEFINED()
... which is what my latest test-case already
does. Please sugge
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #13 from Stas Sergeev ---
Will it help to print an additional warning when
the uninitialized mem is copied to the shared region?
The chances are very high this will result in a false-positives
later, so maybe catching it at that stage would
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #15 from Stas Sergeev ---
(In reply to Philippe Waroquiers from comment #14)
> So, IMO, the easiest is to use the client requests
Which ones?
I did all the modifications you asked for, they
all in my latest test-case.
> (the downs
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #17 from Stas Sergeev ---
(In reply to Philippe Waroquiers from comment #16)
> That might not be straightforward to do, in particular if you have
> multiple threads (you probably need a critical section around the
> write opera
https://bugs.kde.org/show_bug.cgi?id=253657
--- Comment #16 from Stas Sergeev ---
Created attachment 97737
--> https://bugs.kde.org/attachment.cgi?id=97737&action=edit
a test case
Sorry for delay.
Here's the segregs test case.
--
You are receiving this mail because:
You are watc
13 matches
Mail list logo
