|
From: hce <web...@gm...> - 2009-03-02 05:46:42
|
Hi,
I am running valgrind 3.3 on FC9 64-bit linux. I use the valgrind to
check my C++ program, the valgrind generated a very long error
reports, but I was not clear what were wrong for the following errors:
==9629== Invalid read of size 4
==9629== at 0x43DE2D:
Pattern::sendSequence(std::_Rb_tree_iterator<std::pair<unsigned const,
std::string> >) (DataPattern.cpp:168)
==9629== by 0x43DFC5: Pattern::bottomSearchAlgorithm() (DataPattern.cpp:136)
==9629== by 0x43E011: Pattern::handle(std::string const&, unsigned)
(DataPattern.cpp:125)
:
:
The first statement in line 168 is:
offset = it->first + count; where the offset, it->fist and count are
all uint32_t type, so what is the problem for it?
The second statement in line 136 is:
return sendSequence(it); where the bool
Pattern::sendSequence(std::map<uint32_t, std::string>::iterator it)
The third statement in line 125 is:
return bottomSearchAlgorithm(); where the bool
Pattern::bottomSearchAlgorithm(void)
Please enlighten me are there real errors or what I was missing?
Thank you.
Kind Regards,
Geny
|
|
From: Konstantin S. <kon...@gm...> - 2009-03-02 06:33:43
|
Hi Geny, I suggest you to try valgrind 3.4 (or 3.4.1) with a flag --track-origins=yes. This will give more informative reports. --kcc On Mon, Mar 2, 2009 at 8:46 AM, hce <web...@gm...> wrote: > Hi, > > I am running valgrind 3.3 on FC9 64-bit linux. I use the valgrind to > check my C++ program, the valgrind generated a very long error > reports, but I was not clear what were wrong for the following errors: > > ==9629== Invalid read of size 4 > ==9629== at 0x43DE2D: > Pattern::sendSequence(std::_Rb_tree_iterator<std::pair<unsigned const, > std::string> >) (DataPattern.cpp:168) > ==9629== by 0x43DFC5: Pattern::bottomSearchAlgorithm() (DataPattern.cpp:136) > ==9629== by 0x43E011: Pattern::handle(std::string const&, unsigned) > (DataPattern.cpp:125) > : > : > > > The first statement in line 168 is: > > offset = it->first + count; where the offset, it->fist and count are > all uint32_t type, so what is the problem for it? > > The second statement in line 136 is: > > return sendSequence(it); where the bool > Pattern::sendSequence(std::map<uint32_t, std::string>::iterator it) > > The third statement in line 125 is: > > return bottomSearchAlgorithm(); where the bool > Pattern::bottomSearchAlgorithm(void) > > Please enlighten me are there real errors or what I was missing? > > Thank you. > > Kind Regards, > > Geny > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Bart V. A. <bar...@gm...> - 2009-03-02 07:01:33
|
On Mon, Mar 2, 2009 at 6:46 AM, hce <web...@gm...> wrote: > The first statement in line 168 is: > > offset = it->first + count; where the offset, it->fist and count are > all uint32_t type, so what is the problem for it? It might be a good idea to check whether the iterator 'it' is still valid and e.g. doesn't point to an already erased node. Bart. |
|
From: Julian S. <js...@ac...> - 2009-03-02 09:31:02
|
> I suggest you to try valgrind 3.4 (or 3.4.1) with a flag > --track-origins=yes. This will give more informative reports. --track-origins=yes is useful for making sense of uninitialised value errors, but not for the error shown, which is an addressing error. > > ==9629== Invalid read of size 4 > > ==9629== at 0x43DE2D: > > Pattern::sendSequence(std::_Rb_tree_iterator<std::pair<unsigned const, > > std::string> >) (DataPattern.cpp:168) > > ==9629== by 0x43DFC5: Pattern::bottomSearchAlgorithm() > > (DataPattern.cpp:136) ==9629== by 0x43E011: > > Pattern::handle(std::string const&, unsigned) (DataPattern.cpp:125) > > : > > : Look carefully at the complete error here. Does it have a second stack trace, starting "Address xxxxx is nnn bytes before/after a block of size mmm alloc'd at" ? If you can find that text, it will help explain what the problem is. J |
|
From: hce <web...@gm...> - 2009-03-02 22:48:37
|
On Mon, Mar 2, 2009 at 8:30 PM, Julian Seward <js...@ac...> wrote: > >> I suggest you to try valgrind 3.4 (or 3.4.1) with a flag >> --track-origins=yes. This will give more informative reports. > > --track-origins=yes is useful for making sense of uninitialised value > errors, but not for the error shown, which is an addressing error. > >> > ==9629== Invalid read of size 4 >> > ==9629== at 0x43DE2D: >> > Pattern::sendSequence(std::_Rb_tree_iterator<std::pair<unsigned const, >> > std::string> >) (DataPattern.cpp:168) >> > ==9629== by 0x43DFC5: Pattern::bottomSearchAlgorithm() >> > (DataPattern.cpp:136) ==9629== by 0x43E011: >> > Pattern::handle(std::string const&, unsigned) (DataPattern.cpp:125) >> > : >> > : > > Look carefully at the complete error here. Does it have a second > stack trace, starting "Address xxxxx is nnn bytes before/after a block > of size mmm alloc'd at" ? If you can find that text, it will help > explain what the problem is. There is indeed following with one stack trace, please see following error messages. It frees an object with std::map, but I failed to see why that could be a problem. I must miss something here, please enlighten me. ==9629== Address 0xaebeea8 is 32 bytes inside a block of size 48 free'd ==9629== at 0x4A05B9D: operator delete(void*) (vg_replace_malloc.c:342) ==9629== by 0x43F9A0: __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<unsigned const, std::string> > >::deallocate(std::_Rb_tree_node<std::pair<unsigned const, std::string> >*, unsigned long) (new_allocator.h:98) ==9629== by 0x43F9C8: std::_Rb_tree<unsigned, std::pair<unsigned const, std::string>, std::_Select1st<std::pair<unsigned const, std::string> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, std::string> > >::_M_put_node(std::_Rb_tree_node<std::pair<unsigned const, std::string> >*) (stl_tree.h:361) ==9629== by 0x43FA15: std::_Rb_tree<unsigned, std::pair<unsigned const, std::string>, std::_Select1st<std::pair<unsigned const, std::string> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, std::string> > >::_M_destroy_node(std::_Rb_tree_node<std::pair<unsigned const, std::string> >*) (stl_tree.h:391) ==9629== by 0x43FA75: std::_Rb_tree<unsigned, std::pair<unsigned const, std::string>, std::_Select1st<std::pair<unsigned const, std::string> >, std::less<unsigned>, std::allocator<std::pair<unsigned const, std::string> > >::erase(std::_Rb_tree_iterator<std::pair<unsigned const, std::string> >) (stl_tree.h:1319) ==9629== by 0x43FAA8: std::map<unsigned, std::string, std::less<unsigned>, std::allocator<std::pair<unsigned const, std::string> > >::erase(std::_Rb_tree_iterator<std::pair<unsigned const, std::string> >) (stl_map.h:523) I'll take your advice to try valgrind 3.4 (or 3.4.1) with a flag --track-origins=yes. But I am more worried about the memory problems as Julian indicated. Thank you. Geny |
|
From: Christoph B. <bar...@or...> - 2009-03-02 23:26:44
|
> There is indeed following with one stack trace, please see following > error messages. It frees an object with std::map, but I failed to see > why that could be a problem. I must miss something here, please > enlighten me. > > ==9629== Address 0xaebeea8 is 32 bytes inside a block of size 48 free'd > ==9629== at 0x4A05B9D: operator delete(void*) (vg_replace_malloc.c:342) > ==9629== by 0x43F9A0: ... (new_allocator.h:98) > ==9629== by 0x43F9C8: ... (stl_tree.h:361) > ==9629== by 0x43FA15: ... (stl_tree.h:391) > ==9629== by 0x43FA75: ... (stl_tree.h:1319) > ==9629== by 0x43FAA8: ... (stl_map.h:523) You are accessing an object that has been deleted. Look at the tracebacks where your code starts. If they are too short increase their depth with --num-callers=20000. The part of the traceback you showed does not reveal where the object got deleted. Look at the code between the deletion and the usage of the bad pointer. Normally they are not too wide apart. You could also show the code. Christoph |
|
From: hce <web...@gm...> - 2009-03-06 01:50:22
|
On Tue, Mar 3, 2009 at 10:26 AM, Christoph Bartoschek <bar...@or...> wrote: >> There is indeed following with one stack trace, please see following >> error messages. It frees an object with std::map, but I failed to see >> why that could be a problem. I must miss something here, please >> enlighten me. >> >> ==9629== Address 0xaebeea8 is 32 bytes inside a block of size 48 free'd >> ==9629== at 0x4A05B9D: operator delete(void*) (vg_replace_malloc.c:342) >> ==9629== by 0x43F9A0: ... (new_allocator.h:98) >> ==9629== by 0x43F9C8: ... (stl_tree.h:361) >> ==9629== by 0x43FA15: ... (stl_tree.h:391) >> ==9629== by 0x43FA75: ... (stl_tree.h:1319) >> ==9629== by 0x43FAA8: ... (stl_map.h:523) > > You are accessing an object that has been deleted. Look at the tracebacks > where your code starts. If they are too short increase their depth > with --num-callers=20000. The part of the traceback you showed does not > reveal where the object got deleted. > > Look at the code between the deletion and the usage of the bad pointer. > Normally they are not too wide apart. You could also show the code. Thanks Christoph, you are right, it was a bug. After fixing that, all read errors are gone. Now it has only errors for " Use of uninitialised value of size 8", and "Conditional jump or move depends on uninitialised value". The "definitely lost: 0 bytes in 0 blocks", but " possibly lost: 917,938 bytes in 5,594 blocks." I guess I don't need to worry too much about above, right? I am going to further check it. Thank you. Kind Regards, Geny |
|
From: Christoph B. <bar...@or...> - 2009-03-06 07:33:30
|
Am Freitag, 6. März 2009 schrieb hce: > Thanks Christoph, you are right, it was a bug. After fixing that, all > read errors are gone. Now it has only errors for > > " Use of uninitialised value of size 8", and "Conditional jump or move > depends on uninitialised value". The "definitely lost: 0 bytes in 0 > blocks", but " possibly lost: 917,938 bytes in 5,594 blocks." > > I guess I don't need to worry too much about above, right? I am going > to further check it. You have to worry about the "Use of uninitialised value of size 8" and the "Conditional jump or move depends on uninitialised value" errors, because these are often real errors. The possibly lost message does not point directly to an error. But you should check whether the possibly lost memory is expected. Christoph |