part of kernel address space considered ok in unaddr report on chrome

Question

From bruen....com on September 06, 2011 14:55:13

from https://code.google.com/p/chromium/issues/detail?id=94163 I don't think this was booted with /3GB so there's something wrong here:

UNADDRESSABLE ACCESS: writing 0x892102ba-0x892102bb 1 byte(s) within 0x892102ba-0x892102be Note: instruction: mov %ecx -> 0x000000f8(%eax) #1 SkPDFDevice::setDrawingArea
...

what's weird is that the tool thinks the other 3 bytes are ok: if it complained about the whole thing it would make more sense (i.e., a wild write). do we have the full logs? if there was an earlier unaddr, drmem will mark as defined to avoid future duplicate bugs, which is one explanation.

Timur were there earlier errors reported? or was this with /3GB?

Original issue: http://code.google.com/p/drmemory/issues/detail?id=579

该提问来源于开源项目：DynamoRIO/drmemory

Answer 1

From timurrrr.com on September 07, 2011 05:48:00

I don't think this was booted with /3GB Nope, it wasn't. Here are the options I've used: "-pause_at_assert -suppress -quiet -callstack_max_frames 40 -no_check_uninitialized -no_count_leaks -logdir

"

This was on Windows 7 x64; also seeing these addresses in a similar report: UNADDRESSABLE ACCESS: writing 0xcc210ecf-0xcc210ed0 1 byte(s) within 0xcc210ecf-0xcc210ed3 Note: instruction: mov %ecx -> 0x000000f8(%eax)

Did I get your idea right? We're seeing an unaligned 4-byte write at 0x892102ba-0x892102be and the tool only barks about the first byte.

Possible explanations: - the tool is mad - since the access address is unaligned the tool has gone to a slowpath which treats the N-sized write as N 1-byte writes? - 0x...02bb-0x...02be are addressable (left OOB write? why the allocation is not aligned? all the allocation-related headers are aligned, right?)

I don't think this was booted with /3GB so there's something wrong here 0x89...... is the 3rd GB or RAM and this shouldn't happen on Win 7 x64 for 32-bit binaries - right? Maybe unless the memory came from the kernel, e.g. CreateDIBSection? I think SKIA uses the latter very often.

Timur were there earlier errors reported? I'm seeing a few "UNKNOWN REGION" warnings from unrelated stacks before the UNADDR report and also 100000 (yes, one hundred thousands) lines line WARNING: free exceeded heap nesting 28 >= 12 WARNING: RtlFreeHeap exceeded heap nesting 29 >= 12 out of 150000 total lines of the global.PID.log file