MySQL Bugs: #64725: segfault using prepared select statement

Bug #64725	segfault using prepared select statement
Submitted:	21 Mar 2012 19:26	Modified:	3 Feb 2015 13:52
Reporter:	Richard Kojedzinszky	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: C API (client library)	Severity:	S2 (Serious)
Version:	5.5.40, 5.5.42, 5.6.23	OS:	Linux (debian wheezy)
Assigned to:		CPU Architecture:	Any

Description:
I was using tntdb as a wrapper around mysql, but when a prepared select statement was executed multiple times, the application crashed. The crash came from libmysql. Attached a c app which does nearly the same calls as tntdb does.

How to repeat:

http://www38.zippyshare.com/v/84424887/file.html

If for some reason it does not segfault, the run it with valgrind -v, it'll show the invalid memory access.

Suggested fix:

Somehow it would be nice to inform the MYSQL_STMT structure that a MYSQL_BIND has disappeared.

The real example using tntdb

Attachment: test.cpp (text/x-c++src), 309 bytes.

C version of the attached file

Attachment: test.c (text/x-csrc), 2.49 KiB.

Bug #64754 is a duplicate of this one.

Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://dev.mysql.com/doc/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

Problem is row #11: free(r->length);

You have not allocated memory with malloc for r->length, so looks like it is nothing to free. This is not MySQL bug.

Actually a more than two year bug report, still exists on 5.5.40. And after reading the docs, still dont see the wrong code in previously attached test files.

Thank you for the feedback.

You are correct: I misread your code. Verified as described on Linux using last development sources, compiled with debug option. With release version 5.6.21 on Mac bug is not repeatable.

Is there any updates/progress regarding this bug?