From bruen...@google.com on January 02, 2011 16:03:26

both test and ref runs of xalancbmk have 80 unaddrs:
:::Dr.Memory::: 80 unique, 80 total unaddressable access(es)

they all look pretty much like this. I'm guessing libc.so.6!__wcsnrtombs
is doing typical string tricks:

Error #1: UNADDRESSABLE ACCESS: reading 0x09503032-0x09503034 2 byte(s) within 0x09503030-0x09503034
Elapsed time = 0:00:01.778 in thread 26886
Note: next higher malloc: 0x09503048-0x09503110
Note: prev lower malloc: 0x09503000-0x09503032
0x005b6f10 <libc.so.6+0x76f10> libc.so.6!?
??:0
0x005cb95c <libc.so.6+0x8b95c> libc.so.6!??
??:0
0x005c14ea <libc.so.6+0x814ea> libc.so.6!wcsnrtombs
/usr/src/debug/glibc-2.11/wcsmbs/wcsnrtombs.c:117
0x0056e890 <libc.so.6+0x2e890> libc.so.6!??
??:0
0x08255b5b <Xalan_base.amd64-m32-gcc42-nn+0x20db5b> Xalan_base.amd64-m32-gcc42-nn!xalanc_1_8::doTranscodeFromLocalCodePage(char const, unsigned int, bool, std::vector<unsigned short, std::allocator >&, bool)
XalanDOMString.cpp:0
0x082561f1 <Xalan_base.amd64-m32-gcc42-nn+0x20e1f1> Xalan_base.amd64-m32-gcc42-nn!xalanc_1_8::XalanDOMString::append(char const, unsigned int)
??:0
0x082563ab <Xalan_base.amd64-m32-gcc42-nn+0x20e3ab> Xalan_base.amd64-m32-gcc42-nn!xalanc_1_8::XalanDOMString::XalanDOMString(char const*, unsigned int)
??:0
...

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