Status: Accepted
Owner: ----
CC: [email protected], [email protected], [email protected]
Labels: Type-Bug Priority-Medium
New issue 3645 by [email protected]: MSan vs. Serializer: Fight!
https://code.google.com/p/v8/issues/detail?id=3645
mksnapshot currently fails in Debug mode when compiling with msan=1. The
(/one?) reason is that strings contain padding bytes for alignment
purposes, which are never initialized. Example: one-byte internalized
string "undefined":
0x00007fb87d9049b9 // map
0x0000000092115c22 // hash
0x0000000900000000 // length
0x656e696665646e75 // 8 bytes payload
0xdeadbeedbeadbe64 // 1 byte payload, 7 bytes uninitialized
Since these padding bytes are also never read, that's generally fine. They
are, however, read when the heap is serialized for the purpose of
snapshotting.
We could simply initialize these filler bytes with zeroes (maybe only
#ifdef MSAN). However, this would be needless overhead, would have to be
done in both C++ and generated code, and would potentially hide valid
complaints if those bytes are ever read in situations other than
serialization.
Ideally, mksnapshot would be allowed to serialize anything, but serialize
MSan's metadata along with it, so that after snapshot extraction, we'd
still know which bytes are uninitialized. This is probably hard.
Maybe we should simply turn off MSan for mksnapshot. This would have the
drawback that when uninitialized bytes are serialized, deserialized, and
then read, MSan would be unable to detect this.
Maybe we should simply have msan=1 imply v8_use_snapshot='false' to avoid
the issue?
--
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.
