Thread: [Valgrind-users] Address 0xNNNNN is N bytes inside a block of size N alloc'd

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Folks, could you please tell what exactly this error message mean? I
googled around the documentation and found nothing...

Thanks

-- 
Best regards, Pavel

On Mon, Jul 27, 2009 at 12:42 PM, Pavel Shevaev<pac...@gm...> wrote:
> Folks, could you please tell what exactly this error message mean? I
> googled around the documentation and found nothing...

The text you quoted in the title of this e-mail is not an error
message by itself, but a clarification of the error message printed
above that message. It would help if you could post the entire
message.

Bart.

Am Montag, 27. Juli 2009 schrieb Pavel Shevaev:
> Folks, could you please tell what exactly this error message mean? I
> googled around the documentation and found nothing...

If the message is:

Address 0xNNNNN is Y bytes inside a block of size X alloc'd

Then you have somehow allocated X bytes of memory and you have got back a 
pointer to address:

0xNNNNN - Y

So the address 0xNNNNN is the Y'th byte after the start of the block you got.
The range of the block is:

[0xNNNNN - Y, 0xNNNNN - Y + X)

Christoph

> So the address 0xNNNNN is the Y'th byte after the start of the block you got.
> The range of the block is:
>
> [0xNNNNN - Y, 0xNNNNN - Y + X)

Thanks for clarification

-- 
Best regards, Pavel

On Mon, Jul 27, 2009 at 2:55 PM, Bart Van
Assche<bar...@gm...> wrote:
> On Mon, Jul 27, 2009 at 12:42 PM, Pavel Shevaev<pac...@gm...> wrote:
>> Folks, could you please tell what exactly this error message mean? I
>> googled around the documentation and found nothing...
>
> The text you quoted in the title of this e-mail is not an error
> message by itself, but a clarification of the error message printed
> above that message. It would help if you could post the entire
> message.

Thanks for the quick reply! For example, I have the following lines in
valgrind log:

==31513== Thread 3:
==31513== Syscall param socketcall.sendmsg(msg.msg_iov[i]) points to
uninitialised byte(s)
......
(lot's of lines looking like this)
==31513==    by 0x59549EA:
......
==31513==  Address 0xad39096 is 86 bytes inside a block of size 32,444 alloc'd
.....
(some more lines)

-- 
Best regards, Pavel

On Mon, Jul 27, 2009 at 7:24 PM, Pavel Shevaev<pac...@gm...> wrote:
> On Mon, Jul 27, 2009 at 2:55 PM, Bart Van
> Assche<bar...@gm...> wrote:
>> On Mon, Jul 27, 2009 at 12:42 PM, Pavel Shevaev<pac...@gm...> wrote:
>>> Folks, could you please tell what exactly this error message mean? I
>>> googled around the documentation and found nothing...
>>
>> The text you quoted in the title of this e-mail is not an error
>> message by itself, but a clarification of the error message printed
>> above that message. It would help if you could post the entire
>> message.
>
> Thanks for the quick reply! For example, I have the following lines in
> valgrind log:
>
> ==31513== Thread 3:
> ==31513== Syscall param socketcall.sendmsg(msg.msg_iov[i]) points to
> uninitialised byte(s)
> ......
> (lot's of lines looking like this)
> ==31513==    by 0x59549EA:
> ......
> ==31513==  Address 0xad39096 is 86 bytes inside a block of size 32,444 alloc'd
> .....
> (some more lines)

It can be challenging to find out the cause of such error messages.
Sometimes this message is caused by uninitialized padding bytes. If
you don't find the cause via source reading, you can check the data
passed to the system call sendmsg() via the
VALGRIND_CHECK_MEM_IS_DEFINED() client request. See also the header
file /usr/include/valgrind/memcheck.h for more information.

Bart.

> Sometimes this message is caused by uninitialized padding bytes. If
> you don't find the cause via source reading, you can check the data
> passed to the system call sendmsg() via the
> VALGRIND_CHECK_MEM_IS_DEFINED() client request. See also the header
> file /usr/include/valgrind/memcheck.h for more information.

Thanks for the tip.

So in general "Address 0xNNNNN is X bytes inside a block of size Y
alloc'd" is just some info message, right? I just don't understand
completely why I may need it...

-- 
Best regards, Pavel

Am Montag, den 27.07.2009, 21:24 +0400 schrieb Pavel Shevaev:
> On Mon, Jul 27, 2009 at 2:55 PM, Bart Van
> Assche<bar...@gm...> wrote:
> > On Mon, Jul 27, 2009 at 12:42 PM, Pavel Shevaev<pac...@gm...> wrote:
> >> Folks, could you please tell what exactly this error message mean? I
> >> googled around the documentation and found nothing...
> >
> > The text you quoted in the title of this e-mail is not an error
> > message by itself, but a clarification of the error message printed
> > above that message. It would help if you could post the entire
> > message.
> 
> Thanks for the quick reply! For example, I have the following lines in
> valgrind log:
> 
> ==31513== Thread 3:
> ==31513== Syscall param socketcall.sendmsg(msg.msg_iov[i]) points to
> uninitialised byte(s)
> ......
> (lot's of lines looking like this)
> ==31513==    by 0x59549EA:
> ......
> ==31513==  Address 0xad39096 is 86 bytes inside a block of size 32,444 alloc'd
> .....
> (some more lines)
> 

That looks like you used the --track-origins=yes command line parameter
for Valgrind. The "Syscall param ... points to uninitialised byte(s)"
message means that the memory that you passed as parameter to sendmsg()
contains uninitialized bytes (Valgrind knows that the memory passed to
sendmsg() should be initialized, so it prints a warning).

The lines following that give the backtrace for the sendmsg() call; and
the message "Address 0xad39096 is 86 bytes inside a block of size 32,444
alloc'd ..." tells you details about the above error:
- where the uninitialized memory was originally allocated (the lines
following the "Address 0xad39096 is 86 bytes inside..." line should give
the exact backtrace to the malloc() call)
- which byte in the memory is uninitialized; in this case it's the 86th
byte.

You could now look at the byte at offset 86 in the message you send out,
and check what data should be at that position, and check at which point
in your code the data should be initialized.

Personally I'd guess that offset contains just padding bytes or space
reserved for future extensions; so maybe it's no problem to leave it
uninitialized (though in security-sensitive areas it might pass
"confidential data" over the net - just guessing here). Setting those
unused bytes to 0 would then fix the Valgrind warning.

Regards,
Oliver

> The lines following that give the backtrace for the sendmsg() call; and
> the message "Address 0xad39096 is 86 bytes inside a block of size 32,444
> alloc'd ..." tells you details about the above error:
> - where the uninitialized memory was originally allocated (the lines
> following the "Address 0xad39096 is 86 bytes inside..." line should give
> the exact backtrace to the malloc() call)
> - which byte in the memory is uninitialized; in this case it's the 86th
> byte.

I think I understand what happens now, I'm using std::vector for
storing bytes to be sent over the socket and I guess at some moment
std::vector automatically reserves more memory for future needs:

==31513==  Address 0xad39096 is 86 bytes inside a block of size 32,444 alloc'd
==31513==    at 0x40279EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==31513==    by 0x4C72C7C: __gnu_cxx::new_allocator<unsigned
char>::allocate(unsigned int, void const*) (new_allocator.h:92)
==31513==    by 0x4C72CB7: std::__norm::_Vector_base<unsigned char,
std::allocator<unsigned char> >::_M_allocate(unsigned int)
(stl_vector.h:144)
==31513==    by 0x59B7775: std::__norm::vector<unsigned char,
std::allocator<unsigned char>
>::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned char*,
std::__norm::vector<unsigned char, std::allocator<unsigned char> > >,
unsigned int, unsigned char const&) (vector.tcc:395)
==31513==    by 0x59B7943: std::__norm::vector<unsigned char,
std::allocator<unsigned char>
>::insert(__gnu_cxx::__normal_iterator<unsigned char*,
std::__norm::vector<unsigned char, std::allocator<unsigned char> > >,
unsigned int, unsigned char const&) (stl_vector.h:792)
==31513==    by 0x59B79D6: std::__norm::vector<unsigned char,
std::allocator<unsigned char> >::resize(unsigned int, unsigned char)
(stl_vector.h:509)
==31513==    by 0x59B7AA3: std::__debug::vector<unsigned char,
std::allocator<unsigned char> >::resize(unsigned int, unsigned char)
(vector:214)
==31513==    by 0x59B56DE: ByteBuffer::append(unsigned char const*,
unsigned int) (ByteBuffer.cpp:264)

Thank you all again for being so much helpful

-- 
Best regards, Pavel

Thread: [Valgrind-users] Address 0xNNNNN is N bytes inside a block of size N alloc'd

valgrind-users