Memory Issue in Explain

[Brian Aker]

==15540== 120 bytes in 4 blocks are definitely lost in loss record 26 of 187
==15540== at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220)
==15540== by 0x32F0699EA0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:89)
==15540== by 0x32F069B819: std::string::_M_mutate(unsigned long, unsigned long, unsigned long) (basic_string.tcc:457)
==15540== by 0x32F069B9AB: std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) (basic_string.tcc:662)
==15540== by 0x577022: drizzled::optimizer::ExplainPlan::explainUnion(Session*, Select_Lex_Unit*, select_result*) (basic_string.h:970)
==15540== by 0x577797: drizzled::optimizer::ExplainPlan::printPlan() (explain_plan.cc:453)
==15540== by 0x564629: JOIN::exec() (join.cc:1299)
==15540== by 0x5DF6F1: 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:426)
==15540== by 0x5770E3: drizzled::optimizer::ExplainPlan::explainUnion(Session*, Select_Lex_Unit*, select_result*) (explain_plan.cc:560)
==15540== by 0x5D9138: execute_sqlcom_select(Session*, TableList*) (sql_parse.cc:545)
==15540== by 0x5D97B7: dispatch_command(enum_server_command, Session*, char*, unsigned int) (sql_parse.cc:501)
==15540== by 0x5ACBBE: Session::executeStatement() (session.cc:746)
==15540== by 0x5ADE86: Session::run() (session.cc:596)
==15540== by 0x18A75D51: ???
==15540== by 0x32EDA06A39: start_thread (pthread_create.c:297)
==15540== by 0x32ED2DE67C: clone (clone.S:112)

[Padraig O'Sullivan (posulliv)]

This has been fixed in the lp:~posulliv/drizzle/optimizer-style-cleanup branch that is proposed for merging.

[Monty Taylor (mordred)]

Brian Aker wrote:
> Public bug reported:

Funny. I was _just_ noticing this. (I was working on some valgrind
suppressions)

> ==15540== 120 bytes in 4 blocks are definitely lost in loss record 26 of 187
> ==15540== at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220)
> ==15540== by 0x32F0699EA0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:89)
> ==15540== by 0x32F069B819: std::string::_M_mutate(unsigned long, unsigned long, unsigned long) (basic_string.tcc:457)
> ==15540== by 0x32F069B9AB: std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) (basic_string.tcc:662)
> ==15540== by 0x577022: drizzled::optimizer::ExplainPlan::explainUnion(Session*, Select_Lex_Unit*, select_result*) (basic_string.h:970)
> ==15540== by 0x577797: drizzled::optimizer::ExplainPlan::printPlan() (explain_plan.cc:453)
> ==15540== by 0x564629: JOIN::exec() (join.cc:1299)
> ==15540== by 0x5DF6F1: 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:426)
> ==15540== by 0x5770E3: drizzled::optimizer::ExplainPlan::explainUnion(Session*, Select_Lex_Unit*, select_result*) (explain_plan.cc:560)
> ==15540== by 0x5D9138: execute_sqlcom_select(Session*, TableList*) (sql_parse.cc:545)
> ==15540== by 0x5D97B7: dispatch_command(enum_server_command, Session*, char*, unsigned int) (sql_parse.cc:501)
> ==15540== by 0x5ACBBE: Session::executeStatement() (session.cc:746)
> ==15540== by 0x5ADE86: Session::run() (session.cc:596)
> ==15540== by 0x18A75D51: ???
> ==15540== by 0x32EDA06A39: start_thread (pthread_create.c:297)
> ==15540== by 0x32ED2DE67C: clone (clone.S:112)
>
> ** Affects: drizzle
> Importance: Critical
> Status: New
>
> ** Changed in: drizzle
> Importance: Undecided => Critical
>

[Jay Pipes (jaypipes)]

I found this leak in r1247 two days ago and notified Padraig of my findings. He fixed it and pushed a merge proposal shortly afterwards.

/me notes that this leak was introduced >1 month ago. We should cleanup the valgrind reporting to track important pieces (like grepping for "bytes definitely lost" etc.

[Brian Aker (brianaker)]

Hi!

I thought I had reported it as well, but when I went to the bug system I couldn't find it.

Cheers,
 -Brian

On Jan 28, 2010, at 8:03 AM, Jay Pipes wrote:

> I found this leak in r1247 two days ago and notified Padraig of my
> findings. He fixed it and pushed a merge proposal shortly afterwards.
>
> /me notes that this leak was introduced >1 month ago. We should cleanup
> the valgrind reporting to track important pieces (like grepping for
> "bytes definitely lost" etc.
>
> --
> Memory Issue in Explain
> https://bugs.launchpad.net/bugs/513631
> 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: Fix Committed
>
> Bug description:
> ==15540== 120 bytes in 4 blocks are definitely lost in loss record 26 of 187
> ==15540== at 0x4A05974: operator new(unsigned long) (vg_replace_malloc.c:220)
> ==15540== by 0x32F0699EA0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:89)
> ==15540== by 0x32F069B819: std::string::_M_mutate(unsigned long, unsigned long, unsigned long) (basic_string.tcc:457)
> ==15540== by 0x32F069B9AB: std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) (basic_string.tcc:662)
> ==15540== by 0x577022: drizzled::optimizer::ExplainPlan::explainUnion(Session*, Select_Lex_Unit*, select_result*) (basic_string.h:970)
> ==15540== by 0x577797: drizzled::optimizer::ExplainPlan::printPlan() (explain_plan.cc:453)
> ==15540== by 0x564629: JOIN::exec() (join.cc:1299)
> ==15540== by 0x5DF6F1: 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:426)
> ==15540== by 0x5770E3: drizzled::optimizer::ExplainPlan::explainUnion(Session*, Select_Lex_Unit*, select_result*) (explain_plan.cc:560)
> ==15540== by 0x5D9138: execute_sqlcom_select(Session*, TableList*) (sql_parse.cc:545)
> ==15540== by 0x5D97B7: dispatch_command(enum_server_command, Session*, char*, unsigned int) (sql_parse.cc:501)
> ==15540== by 0x5ACBBE: Session::executeStatement() (session.cc:746)
> ==15540== by 0x5ADE86: Session::run() (session.cc:596)
> ==15540== by 0x18A75D51: ???
> ==15540== by 0x32EDA06A39: start_thread (pthread_create.c:297)
> ==15540== by 0x32ED2DE67C: clone (clone.S:112)
>
>

[Monty Taylor (mordred)]

Jay Pipes wrote:
> I found this leak in r1247 two days ago and notified Padraig of my
> findings. He fixed it and pushed a merge proposal shortly afterwards.
>
> /me notes that this leak was introduced >1 month ago. We should cleanup
> the valgrind reporting to track important pieces (like grepping for
> "bytes definitely lost" etc.

Yes... I'm still working on adding suppressions for the things that are
out of our control.