On Wed, 2012-06-13 at 00:42 -0500, Jonathan Nieder wrote:
> shawn wrote:
>
> > As these unaligned memory accesses are not going to be fixed in time for
> > wheezy,
>
> Is that a given? Do we have a patch that is waiting to be applied, or
> has a bug been filed upstream? Are there lots of different areas of
> code that perform unaligned accesses, making it implausible to fix?
no it is not certain, sorry for being negative. Patch below for that
issue. However
I am unable to continue working on this, because I do not know how to
run
chromium from the build directory directly, without installing (root
access).
Can you help with that?
This is only run at startup, so there are other unaligned memory access
issues.
(the logs do spam if you have reporting on)
>
> Timo's trace shows two unaligned accesses, which sounds fixable.
>
> Thanks,
> Jonathan
--
-Shawn Landden
commit e4f2ddb3fc2333bae34fd8bd9552933ab698bd95
Author: Shawn Landden <shawnland...@gmail.com>
Date: Sun Jun 3 23:42:30 2012 -0700
fix unalignment memory access in
src/ui/base/resource/data_pack.cc:132
diff --git a/src/ui/base/resource/data_pack.cc
b/src/ui/base/resource/data_pack.cc
index be44afa..e2b37f1 100644
--- a/src/ui/base/resource/data_pack.cc
+++ b/src/ui/base/resource/data_pack.cc
@@ -129,7 +129,8 @@ bool DataPack::Load(const FilePath& path) {
for (size_t i = 0; i < resource_count_ + 1; ++i) {
const DataPackEntry* entry = reinterpret_cast<const
DataPackEntry*>(
mmap_->data() + kHeaderLength + (i * sizeof(DataPackEntry)));
- if (entry->file_offset > mmap_->length()) {
+ // file_offset is 4-byte, but only aligned to 2-byte boundry
+ if (memcmp(entry->file_offset, mmap_->length(), 32) > 0) {
LOG(ERROR) << "Entry #" << i << " in data pack points off end of
file. "
<< "Was the file corrupted?";
UMA_HISTOGRAM_ENUMERATION("DataPack.Load", ENTRY_NOT_FOUND,
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
