https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #19 from Philippe Waroquiers ---
(In reply to Philippe Waroquiers from comment #18)
> When a 'usage of undefined' bit is detected,
> it is not known anymore that this undefined
> value came from (or through) shared memory,
Which made me thin
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #18 from Philippe Waroquiers ---
(In reply to Stas Sergeev from comment #17)
> (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
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 operations) or proc
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #16 from Philippe Waroquiers ---
(In reply to Stas Sergeev from comment #15)
> (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
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 downside of th
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #14 from Philippe Waroquiers ---
(In reply to Stas Sergeev from comment #13)
> 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-p
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
Philippe Waroquiers changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
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 suggest how
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #10 from Philippe Waroquiers ---
(In reply to Stas Sergeev from comment #8)
> > Initialising yourself the memory via one ptr
> > but accessing it via another mapping
> > is not the same as declaring the memory
> > defined after *each* mmap.
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
> and in what shap
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 guarantees is that
> t
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #7 from Philippe Waroquiers ---
(In reply to Stas Sergeev from comment #4)
> Created attachment 114906 [details]
> 2 processes and VALGRIND_MAKE_MEM_DEFINED
>
> (In reply to Philippe Waroquiers from comment #3)
> > It is not very clear to
https://bugs.kde.org/show_bug.cgi?id=398445
Ivo Raisr changed:
What|Removed |Added
CC||iv...@ivosh.net
--- Comment #6 from Ivo Raisr ---
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. Serv
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 clear to me wha
https://bugs.kde.org/show_bug.cgi?id=398445
--- Comment #3 from Philippe Waroquiers ---
(In reply to Stas Sergeev from comment #2)
> Created attachment 114889 [details]
> 2-process test-case
>
> Hi, thanks for your reply.
> Here is the test-case that does the same
> thing but with 2 processes sc
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 scheme.
Sa
https://bugs.kde.org/show_bug.cgi?id=398445
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
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:
20 matches
Mail list logo