Hi, Rerun of the situation described in https://bugs.gentoo.org/548912 and reported upstream in https://bugs.mysql.com/bug.php?id=76984. We still apply the patch for 5.2.7. It seems upstream has gone the route of replacing x_free with free eventually. I didn't check their changelog, but what I can confirm pre-patch the ret variable is now allocated using malloc(), and free'd using free(). Looking at the ebuild it looks like the patches are completely dropped for 5.3.9 and then re-introduced for 5.3.10. Since the patch updated malloc to my_malloc, and then that matched with the x_free, if we now patch malloc to my_malloc, it'll mismatch the free() that is now in place, resulting in badness. I don't think it matters which implementation is used, as long as it's consistent, at this point my recommendation is to back out the patch (fewer things that can conflict with upstream or cause problems). I eyeballed the other applied patches and they look good, so it just seems to be the one patch. Backing it (5.2.7-my_malloc.patch) out resolves my problems. Kind Regards, Jaco
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d3ecd1e5d0d45f9356367f294da2039449436738 commit d3ecd1e5d0d45f9356367f294da2039449436738 Author: Brian Evans <grknight@gentoo.org> AuthorDate: 2018-03-27 12:50:38 +0000 Commit: Brian Evans <grknight@gentoo.org> CommitDate: 2018-03-27 12:50:38 +0000 dev-db/myodbc: Drop patch that was integrated upstream Closes: https://bugs.gentoo.org/651386 Package-Manager: Portage-2.3.24, Repoman-2.3.6 .../{myodbc-5.3.10-r1.ebuild => myodbc-5.3.10-r2.ebuild} | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-)
