|
From: Yuri <yu...@ra...> - 2011-12-03 02:41:52
|
While running memcheck, I see such error: ==26916== Address 0x31d96c0 is 48 bytes inside a block of size 51 alloc'd ==26916== at 0x25A96B: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ... What does this mean? Does it imply that malloc returned already allocated block? This is system malloc from libc.so on FreeBSD. Yuri |
|
From: Brad H. <br...@fr...> - 2011-12-03 03:04:13
|
On Sat, 3 Dec 2011 01:08:52 PM Yuri wrote: > While running memcheck, I see such error: > ==26916== Address 0x31d96c0 is 48 bytes inside a block of size 51 alloc'd > ==26916== at 0x25A96B: malloc (in > /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) > ... > > What does this mean? Does it imply that malloc returned already > allocated block? This is system malloc from libc.so on FreeBSD. The meaning depends on the context, which you haven't provided. One possibility is that you've malloc'd a char foo[51], and are writing beyond the bounds of that array, say with a long at foo[48]; Brad |
|
From: Yuri <yu...@ra...> - 2011-12-03 03:18:17
|
On 12/02/2011 19:04, Brad Hards wrote: > The meaning depends on the context, which you haven't provided. One > possibility is that you've malloc'd a char foo[51], and are writing beyond the > bounds of that array, say with a long at foo[48]; Error is printed for the malloc call itself. Below in stack is STL string constructor, like this: std::basic_string<char, std::char_traits<char>, ... If writing would have occurred like you suggested, the error would have been printed for the function where writing was performed. Yuri |
|
From: Brad H. <br...@fr...> - 2011-12-03 06:29:22
|
On Sat, 3 Dec 2011 02:18:01 PM Yuri wrote: > On 12/02/2011 19:04, Brad Hards wrote: > > The meaning depends on the context, which you haven't provided. One > > possibility is that you've malloc'd a char foo[51], and are writing > > beyond the bounds of that array, say with a long at foo[48]; > > Error is printed for the malloc call itself. Below in stack is STL > string constructor, like this: std::basic_string<char, > std::char_traits<char>, ... > If writing would have occurred like you suggested, the error would have > been printed for the function where writing was performed. So if you provide detailed information such as the exact trace, we might be able to do something other than guess. Brad |
|
From: Yuri <yu...@ra...> - 2011-12-03 06:51:53
|
On 12/02/2011 22:29, Brad Hards wrote: > So if you provide detailed information such as the exact trace, we might be > able to do something other than guess. I pretty much explained the stack. Well, here it is verbatim: ==27401== Address 0x31d96c0 is 48 bytes inside a block of size 51 alloc'd ==27401== at 0x25A96B: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==27401== by 0x79C72A: XAllocator::xalloc(unsigned long) (allocator.h:16) ==27401== by 0x7A21E9: Allocs::xallocator<char>::allocate(unsigned long, void const*) (allocator-for-stl.h:23) ==27401== by 0x7A192E: std::basic_string<char, std::char_traits<char>, Allocs::xallocator<char> >::_Rep::_S_create(unsigned long, unsigned long, Allocs::xallocator<char> const&) (basic_string.tcc:609) ==27401== by 0x7A06AA: std::basic_string<char, std::char_traits<char>, Allocs::xallocator<char> >::_Rep::_M_clone(Allocs::xallocator<char> const&, unsigned long) (basic_string.tcc:631) ==27401== by 0x79F86D: std::basic_string<char, std::char_traits<char>, Allocs::xallocator<char> >::_Rep::_M_grab(Allocs::xallocator<char> const&, Allocs::xallocator<char> const&) (basic_string.h:224) ==27401== by 0x7A934E: std::basic_string<char, std::char_traits<char>, Allocs::xallocator<char> >::basic_string(std::basic_string<char, std::char_traits<char>, Allocs::xallocator<char> > const&) (basic_string.tcc:175) Now I am curious what additional information you can deduce from this stack. Yuri |
|
From: Brad H. <br...@fr...> - 2011-12-03 07:10:15
|
On Sat, 3 Dec 2011 05:51:38 PM Yuri wrote: > On 12/02/2011 22:29, Brad Hards wrote: > > So if you provide detailed information such as the exact trace, we might > > be able to do something other than guess. > > I pretty much explained the stack. Well, here it is verbatim: <snip> > Now I am curious what additional information you can deduce from this > stack. You need the rest of the stack. Try adding --num-callers=40 Brad |
|
From: David C. <dcc...@ac...> - 2011-12-03 07:15:24
|
On 12/2/2011 10:51 PM, Yuri wrote:
> On 12/02/2011 22:29, Brad Hards wrote:
>> So if you provide detailed information such as the exact trace, we might be
>> able to do something other than guess.
> I pretty much explained the stack. Well, here it is verbatim:
What is the actual error you are getting? You have never told us what
the error is. This shows only the address that memcheck thinks is being
accessed improperly.
Is this the first error, or are there other messages from memcheck
before this one? If the memory allocator is so confused that it is
allocating memory that has not yet been freed, memory is pretty well
corrupted. In this case, the first messages are the only ones that are
really reliable; other messages may result from the memory corruption
itself.
If you write far enough outside the bounds of an allocated memory block,
you might start to write into another allocated memory block. memcheck
isn't smart enough to know which memory block should be accessed, so it
guesses. It may have allowed an improper memory write without flagging it.
We need to see the error message itself as well as the full call chain
(stack) before we can even start to help. The stack chain you printed
is incomplete; it should go all the way up to main(). You've only
showed us the stack up to the allocator routine in the standard C
llibrary routine.
--
David Chapman dcc...@ac...
Chapman Consulting -- San Jose, CA
|