Drizzle

Valgrind errors - tree_or

Bug #438434 reported by Lee Bieber
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Drizzle
Invalid
Critical
Stewart Smith
Drizzle bell "bell"

Bug Description

innodb.test
==11906== 128 bytes in 16 blocks are definitely lost in loss record 6 of 13
==11906== at 0x4A06FFC: operator new(unsigned long) (vg_replace_malloc.c:230)
==11906== by 0x4D0FE4: void std::vector<SEL_IMERGE*, std::allocator<SEL_IMERGE*> >::_M_insert_aux<SEL_IMERGE* const&>(__gnu_cxx::__normal_iterator<SEL_IMERGE**, std::vector<SEL_IMERGE*, std::allocator<SEL_IMERGE*> > >, SEL_IMERGE* const&&&) (new_allocator.h:89)
==11906== by 0x4CB9CF: tree_or(RANGE_OPT_PARAM*, SEL_TREE*, SEL_TREE*) (stl_vector.h:741)
==11906== by 0x4CF6D5: get_mm_tree(RANGE_OPT_PARAM*, Item*) (opt_range.cc:4172)
==11906== by 0x4D005F: SQL_SELECT::test_quick_select(Session*, std::bitset<72ul>, unsigned long, unsigned long, bool, bool) (opt_range.cc:2304)
==11906== by 0x51DFD7: get_quick_record_count(Session*, SQL_SELECT*, Table*, std::bitset<72ul> const*, unsigned long) (sql_select.cc:483)
==11906== by 0x4AD335: make_join_statistics(JOIN*, TableList*, Item*, st_dynamic_array*) (join.cc:5869)
==11906== by 0x4AE8DE: JOIN::optimize() (join.cc:536)
==11906== by 0x51E0B9: mysql_select(Session*, Item***, TableList*, unsigned int, List<Item>&, Item*, unsigned int, order_st*, order_st*, Item*, unsigned long, select_result*, Select_Lex_Unit*, Select_Lex*) (sql_select.cc:420)
==11906== by 0x51EA6E: mysql_explain_union(Session*, Select_Lex_Unit*, select_result*) (sql_select.cc:7043)
==11906== by 0x516216: execute_sqlcom_select(Session*, TableList*) (sql_parse.cc:538)
==11906== by 0x513845: mysql_execute_command(Session*) (sql_parse.cc:495)
==11906== by 0x51456D: mysql_parse(Session*, char const*, unsigned int, char const**) (sql_parse.cc:783)
==11906== by 0x514EB0: dispatch_command(enum_server_command, Session*, char*, unsigned int) (sql_parse.cc:217)
==11906== by 0x4DD68E: Session::executeStatement() (session.cc:728)
==11906== by 0x4DE626: Session::run() (session.cc:600)

innodb_notembedded
==19571== 32 bytes in 4 blocks are definitely lost in loss record 3 of 10
==19571== at 0x4A06FFC: operator new(unsigned long) (vg_replace_malloc.c:230)
==19571== by 0x4D0FE4: void std::vector<SEL_IMERGE*, std::allocator<SEL_IMERGE*> >::_M_insert_aux<SEL_IMERGE* const&>(__gnu_cxx::__normal_iterator<SEL_IMERGE**, std::vector<SEL_IMERGE*, std::allocator<SEL_IMERGE*> > >, SEL_IMERGE* const&&&) (new_allocator.h:89)
==19571== by 0x4CB9CF: tree_or(RANGE_OPT_PARAM*, SEL_TREE*, SEL_TREE*) (stl_vector.h:741)
==19571== by 0x4CF6D5: get_mm_tree(RANGE_OPT_PARAM*, Item*) (opt_range.cc:4172)
==19571== by 0x4D005F: SQL_SELECT::test_quick_select(Session*, std::bitset<72ul>, unsigned long, unsigned long, bool, bool) (opt_range.cc:2304)
==19571== by 0x51DFD7: get_quick_record_count(Session*, SQL_SELECT*, Table*, std::bitset<72ul> const*, unsigned long) (sql_select.cc:483)
==19571== by 0x4AD335: make_join_statistics(JOIN*, TableList*, Item*, st_dynamic_array*) (join.cc:5869)
==19571== by 0x4AE8DE: JOIN::optimize() (join.cc:536)
==19571== by 0x51E0B9: mysql_select(Session*, Item***, TableList*, unsigned int, List<Item>&, Item*, unsigned int, order_st*, order_st*, Item*, unsigned long, select_result*, Select_Lex_Unit*, Select_Lex*) (sql_select.cc:420)
==19571== by 0x51EA6E: mysql_explain_union(Session*, Select_Lex_Unit*, select_result*) (sql_select.cc:7043)
==19571== by 0x516216: execute_sqlcom_select(Session*, TableList*) (sql_parse.cc:538)
==19571== by 0x513845: mysql_execute_command(Session*) (sql_parse.cc:495)
==19571== by 0x51456D: mysql_parse(Session*, char const*, unsigned int, char const**) (sql_parse.cc:783)
==19571== by 0x514EB0: dispatch_command(enum_server_command, Session*, char*, unsigned int) (sql_parse.cc:217)
==19571== by 0x4DD68E: Session::executeStatement() (session.cc:728)
==19571== by 0x4DE626: Session::run() (session.cc:600)

sum_distinct
==24130== 96 (88 direct, 8 indirect) bytes in 11 blocks are definitely lost in loss record 8 of 15
==24130== at 0x4A06FFC: operator new(unsigned long) (vg_replace_malloc.c:230)
==24130== by 0x4D0FE4: void std::vector<SEL_IMERGE*, std::allocator<SEL_IMERGE*> >::_M_insert_aux<SEL_IMERGE* const&>(__gnu_cxx::__normal_iterator<SEL_IMERGE**, std::vector<SEL_IMERGE*, std::allocator<SEL_IMERGE*> > >, SEL_IMERGE* const&&&) (new_allocator.h:89)
==24130== by 0x4CB9CF: tree_or(RANGE_OPT_PARAM*, SEL_TREE*, SEL_TREE*) (stl_vector.h:741)
==24130== by 0x4CF6D5: get_mm_tree(RANGE_OPT_PARAM*, Item*) (opt_range.cc:4172)
==24130== by 0x4D005F: SQL_SELECT::test_quick_select(Session*, std::bitset<72ul>, unsigned long, unsigned long, bool, bool) (opt_range.cc:2304)
==24130== by 0x51DFD7: get_quick_record_count(Session*, SQL_SELECT*, Table*, std::bitset<72ul> const*, unsigned long) (sql_select.cc:483)
==24130== by 0x4AD335: make_join_statistics(JOIN*, TableList*, Item*, st_dynamic_array*) (join.cc:5869)
==24130== by 0x4AE8DE: JOIN::optimize() (join.cc:536)
==24130== by 0x51E0B9: mysql_select(Session*, Item***, TableList*, unsigned int, List<Item>&, Item*, unsigned int, order_st*, order_st*, Item*, unsigned long, select_result*, Select_Lex_Unit*, Select_Lex*) (sql_select.cc:420)
==24130== by 0x51EA6E: mysql_explain_union(Session*, Select_Lex_Unit*, select_result*) (sql_select.cc:7043)
==24130== by 0x516216: execute_sqlcom_select(Session*, TableList*) (sql_parse.cc:538)
==24130== by 0x513845: mysql_execute_command(Session*) (sql_parse.cc:495)
==24130== by 0x51456D: mysql_parse(Session*, char const*, unsigned int, char const**) (sql_parse.cc:783)
==24130== by 0x514EB0: dispatch_command(enum_server_command, Session*, char*, unsigned int) (sql_parse.cc:217)
==24130== by 0x4DD68E: Session::executeStatement() (session.cc:728)
==24130== by 0x4DE626: Session::run() (session.cc:600)

Lee Bieber (kalebral-deactivatedaccount)
Changed in drizzle:
importance: Undecided → High
status: New → Confirmed
milestone: none → bell
assignee: nobody → Stewart Smith (stewart-flamingspork)
Brian Aker (brianaker)
Changed in drizzle:
importance: High → Critical
Revision history for this message
Jay Pipes (jaypipes) wrote :

What branch is this on? The line numbers in the backtrace certainly don't match the code in trunk, so this is very difficult to follow...

Revision history for this message
Brian Aker (brianaker) wrote : Re: [Bug 438434] Re: Valgrind errors - tree_or
Download full text (6.7 KiB)

Hi!

Just run this:
./test-run --valgrind innodb

Then look at the master.err file.

I suspect the problem is a missed conversion to vector that should
have never happened.

Cheers,
    -Brian

On Nov 5, 2009, at 8:35 AM, Jay Pipes wrote:

> What branch is this on? The line numbers in the backtrace certainly
> don't match the code in trunk, so this is very difficult to follow...
>
> --
> Valgrind errors - tree_or
> https://bugs.launchpad.net/bugs/438434
> You received this bug notification because you are a member of
> Drizzle-
> developers, which is subscribed to Drizzle.
>
> Status in A Lightweight SQL Database for Cloud and Web: Confirmed
>
> Bug description:
> innodb.test
> ==11906== 128 bytes in 16 blocks are definitely lost in loss record
> 6 of 13
> ==11906== at 0x4A06FFC: operator new(unsigned long)
> (vg_replace_malloc.c:230)
> ==11906== by 0x4D0FE4: void std::vector<SEL_IMERGE*,
> std::allocator<SEL_IMERGE*> >::_M_insert_aux<SEL_IMERGE* const&>
> (__gnu_cxx::__normal_iterator<SEL_IMERGE**, std::vector<SEL_IMERGE*,
> std::allocator<SEL_IMERGE*> > >, SEL_IMERGE* const&&&)
> (new_allocator.h:89)
> ==11906== by 0x4CB9CF: tree_or(RANGE_OPT_PARAM*, SEL_TREE*,
> SEL_TREE*) (stl_vector.h:741)
> ==11906== by 0x4CF6D5: get_mm_tree(RANGE_OPT_PARAM*, Item*)
> (opt_range.cc:4172)
> ==11906== by 0x4D005F: SQL_SELECT::test_quick_select(Session*,
> std::bitset<72ul>, unsigned long, unsigned long, bool, bool)
> (opt_range.cc:2304)
> ==11906== by 0x51DFD7: get_quick_record_count(Session*,
> SQL_SELECT*, Table*, std::bitset<72ul> const*, unsigned long)
> (sql_select.cc:483)
> ==11906== by 0x4AD335: make_join_statistics(JOIN*, TableList*,
> Item*, st_dynamic_array*) (join.cc:5869)
> ==11906== by 0x4AE8DE: JOIN::optimize() (join.cc:536)
> ==11906== by 0x51E0B9: mysql_select(Session*, Item***,
> TableList*, unsigned int, List<Item>&, Item*, unsigned int,
> order_st*, order_st*, Item*, unsigned long, select_result*,
> Select_Lex_Unit*, Select_Lex*) (sql_select.cc:420)
> ==11906== by 0x51EA6E: mysql_explain_union(Session*,
> Select_Lex_Unit*, select_result*) (sql_select.cc:7043)
> ==11906== by 0x516216: execute_sqlcom_select(Session*,
> TableList*) (sql_parse.cc:538)
> ==11906== by 0x513845: mysql_execute_command(Session*)
> (sql_parse.cc:495)
> ==11906== by 0x51456D: mysql_parse(Session*, char const*,
> unsigned int, char const**) (sql_parse.cc:783)
> ==11906== by 0x514EB0: dispatch_command(enum_server_command,
> Session*, char*, unsigned int) (sql_parse.cc:217)
> ==11906== by 0x4DD68E: Session::executeStatement() (session.cc:728)
> ==11906== by 0x4DE626: Session::run() (session.cc:600)
>
> innodb_notembedded
> ==19571== 32 bytes in 4 blocks are definitely lost in loss record 3
> of 10
> ==19571== at 0x4A06FFC: operator new(unsigned long)
> (vg_replace_malloc.c:230)
> ==19571== by 0x4D0FE4: void std::vector<SEL_IMERGE*,
> std::allocator<SEL_IMERGE*> >::_M_insert_aux<SEL_IMERGE* const&>
> (__gnu_cxx::__normal_iterator<SEL_IMERGE**, std::vector<SEL_IMERGE*,
> std::allocator<SEL_IMERGE*> > >, SEL_IMERGE* const&&&)
> (new_allocator.h:89)
> ==19571==...

Read more...

Revision history for this message
Jay Pipes (jaypipes) wrote :

OK, I ran ./dtr --valgrind-mysqld innodb. No leaks:

==15584== LEAK SUMMARY:
==15584== definitely lost: 0 bytes in 0 blocks.
==15584== indirectly lost: 80 bytes in 5 blocks.
==15584== possibly lost: 0 bytes in 0 blocks.
==15584== still reachable: 15,897,451 bytes in 156 blocks.
==15584== suppressed: 7,117 bytes in 40 blocks.

This was on a freshly pulled trunk branch, so the errors you are seeing must not be on trunk? I see a few use of uninitialized variable errors, and will look into those, but Brian could you verify that you see this on trunk?

Thanks!

Jay

Revision history for this message
Stewart Smith (stewart) wrote :

this specific test doesn't give this warning anymore on trunk pandora

Changed in drizzle:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.