Bug #17480 handlers are deleted incorrectly

• Submitted: 16 Feb 2006 16:11
• Modified: 29 Jul 2006 20:09
• Reporter: Sergei Golubchik
• Status: Won't fix
• Category: MySQL Server
• Severity: S3 (Non-critical)
• Assigned to: Antony Curtis
• CPU Architecture: Any

[16 Feb 2006 16:11] Sergei Golubchik

Description:
To create a new handler we call a handlerton method - it is correct.
But to delete a handler we do 'delete handler' which is wrong, according to
http://www.isotton.com/howtos/C++-dlopen-mini-HOWTO/C++-dlopen-mini-HOWTO.html

"
You must provide both a creation and a destruction function; you must not destroy the instances using delete from inside the executable, but always pass it back to the module. This is due to the fact that in C++ the operators new and delete may be overloaded; this would cause a non-matching new and delete to be called, which could cause anything from nothing to memory leaks and segmentation faults. The same is true if different standard libraries are used to link the module and the executable.
"

How to repeat:
cat sql/handler.cc

[26 Jul 2006 9:21] Antony Curtis

In the mysql-5.x codebase, handler classes are allocated in a mrm_root area. The class destructor is not always called and it is assumed that there is no tidy up to be performed - in fact, in places where the current code attempts to dispose of a handler instance, it would translate into a no-op.

The only instance where there will be trouble would arise if the handler instance is not created in the expected arena.

Fixing the codebase to allow the storage engine to be responsible for the memory management of the handler instances would require incompatible changes to be made to the storage engine api and would require work to ensure that the appropiate destructor is called - possibly done by having a virtual method in the handler class which would dispose of itself...

void ha_fooengine::dispose()
{
  delete this;
}