Comment #9 on issue 3645 by [email protected]: MSan vs. Serializer:
Fight!
https://code.google.com/p/v8/issues/detail?id=3645
To reiterate, there are two possible goals. Either
a) we're interested in detecting uses of uninitialized memory after it has
been snapshotted and then restored, or
b) we just want to silence MSan.
a) requires the complicated approach outlined above. I have my doubts that
it is worth the trouble. Perhaps simply disabling snapshotting would give
us the same coverage. But that is for your team to decide.
b) is simple. You don't need to modify the actual data and figure out the
location of the padding. You just need to tell MSan that the entire object
is initialized. For that we have __msan_unpoison().
Except we don't want to unpoison the actual object on the heap, which we
may access again later (I'm not sure if that's the case for mksnapshot). If
we do, we won't be able to catch UMR bugs in later accesses. So we want to
touch only temporary objects. For example, the byte argument to
SnapshotByteSink::Put().
It's interesting what happens to this memory later and why we don't
detect it in the optimized build. Could be printf() or any other function
that we don't intercept.
Yeah, the data is written with fprintf calls in mksnapshot.cc.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
