Dbx check -access report wua when call vsnprintf

Question

I don't undertand WHY I would get this "Write to unallocated (wua)" error? I tried purify, purify does NOT report this error.
#include <stdio.h>
#include <stdarg.h>
int write(char* buffer,const char* format, ...)
va_list vlist;
va_start(vlist,format);
printf("Buffer Address at %x\n", &buffer[0]);
int size = vsnprintf(&buffer[0], 2, format, vlist);
va_end(vlist);
return 0;
int main()
char* buffer = new char[2]; *// if I use char buffer[2] instead of new char[2], I won’t get this error report!*
printf("Buffer Address at %x\n", buffer);
write(buffer,"%s\n", "xujian");
return 0;
CC -g -o test test.cpp
-bash-3.00$ dbx ./test
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.7' in your .dbxrc
Reading test
Reading ld.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.2
Reading libc.so.1
(dbx) check -access
access checking - ON
(dbx) run
Running: test
(process id 21660)
RTC: Enabling Error Checking...
RTC: Running program...
Reading disasm.so
Buffer Address at 80672a8
Buffer Address at 80672a8
Write to unallocated (wua):
Attempting to write 1 byte at address 0x80672aa
which is just past heap block of size 2 bytes at 0x80672a8
This block was allocated from:
*[1] operator new() at 0xecd06887*
*[2] operator new[]() at 0xecd05bdd*
*[3] main() at line 23 in "test.cpp"*
stopped in write at line 15 in file "test.cpp"
*15 int size = vsnprintf(&buffer[0], 2, format, vlist);*
(dbx)
Edited by: jianxu1 on Jan 19, 2010 1:49 AM

Answer 1

jianxu1 wrote:
Thanks, MaximKartashev~, Yes, I am on x86.
BTW, I noticed that bcheck(dbx check -access) is much much slower than purify~~ -:(Yes, Purify does not impact performance anywhere near as much as bcheck does.
Also, the behavior you're seeing seems consistent with trying to write the seven bytes of the string "xujian" into a two-byte buffer allocated from the heap. If you make that string more than 8 characters long, you should see Purify start to complain, too.
That's because malloc() (which the new operator uses), per the man page, "returns a pointer to a block of at least size bytes suitably aligned for any use." That phrase "suitably aligned for any use" effectively means that malloc()'d memory comes in 8-byte chunks. So even though you're asking for two bytes, you're getting a pointer to an eight-byte chunk. Ask for 9, and you'll get 16.
Your "char buffer[2];" variant doesn't get any errors from bcheck because bcheck doesn't do any run-time checking of automatic or stack variables. Purify should. I am somewhat surprised Purify doesn't give you an "array bounds write" (ABW) error on the "char buffer[2];" variant of your test case. Perhaps Purify has problems handling varargs and automatic variables. You may want to file a bug on Purify for that. FWIW, if you declare "char buffer[2]" and then try something like
char buffer[ 2 ];
strcpy( buffer, "ThisIsALongString" );Purify should give you an ABW for that.