| Summary: | dev-db/mysql-5.0.44-r2 - mysqld crashes with a sorted select on a view if compiled widh debug flag on | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Patrick ALLAERT <patrickallaert> |
| Component: | [OLD] Server | Assignee: | Gentoo Linux MySQL bugs team <mysql-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | gcrispin |
| Priority: | High | ||
| Version: | 2007.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Patrick ALLAERT
2007-12-25 14:58:23 UTC
I forgot to mention that this bug is 100% reproducible on my x86 box but that I am unable to reproduce it on my x86_64 one (same mysql version) This looks a lot like this one, resolved in 5.0.46: http://bugs.mysql.com/bug.php?id=29104 "Noted in 5.0.46, 5.1.21 changelogs. An assertion failure occurred if a query contained a conjunctive predicate of the form view_column = constant in the WHERE clause and the GROUP BY clause contained a reference to a different view column. The fix also enables application of an optimization that was being skipped if a query contained a conjunctive predicate of the form view_column = constant in the WHERE clause and the GROUP BY clause contained a reference to the same view column." I have been able to reproduce this bug, but it only seems to occur with the debug use flag switched on.
I assume DBUG_ASSERT is trapping these, and is only active when compiled with the debug use flag.
bool Item_direct_view_ref::eq(const Item *item, bool binary_cmp) const
{
if (item->type() == REF_ITEM)
{
Item_ref *item_ref= (Item_ref*) item;
if (item_ref->ref_type() == VIEW_REF)
{
Item *item_ref_ref= *(item_ref->ref);
DBUG_ASSERT((*ref)->real_item()->type() ==
item_ref_ref->real_item()->type());
return ((*ref)->real_item() == item_ref_ref->real_item());
}
}
return FALSE;
}
(In reply to comment #3) > I have been able to reproduce this bug, but it only seems to occur with the > debug use flag switched on. > > I assume DBUG_ASSERT is trapping these, and is only active when compiled with > the debug use flag. debug flag is not activated at my side. mysql has been emerged (and re-emerged) with: dev-db/mysql-5.0.44-r2 USE="berkdb debug ssl -big-tables -cluster -embedded -extraengine -latin1 -max-idx-128 -minimal -perl (-selinux) -static" (In reply to comment #4) > (In reply to comment #3) > > I have been able to reproduce this bug, but it only seems to occur with the > > debug use flag switched on. > > > > I assume DBUG_ASSERT is trapping these, and is only active when compiled with > > the debug use flag. > > debug flag is not activated at my side. mysql has been emerged (and re-emerged) > with: > > dev-db/mysql-5.0.44-r2 USE="berkdb debug ssl -big-tables -cluster -embedded > -extraengine -latin1 -max-idx-128 -minimal -perl (-selinux) -static" I really need to buy glasses... Don't know how and why a line like "dev-db/mysql debug" is present in my package.use. Anyway, this bug shouldn't occurs with debug activated but removing it solves the problem. Thanks Gareth for pointing this out :) This has been resolved in upstream sources, I've just tested with 5.0.51 with debug enabled - it runs without issue. This follows upstream bug: http://bugs.mysql.com/bug.php?id=29104 This patch submitted to MySQL bitkeeper resolved the issue. http://mysql.bkbits.net:8080/mysql-5.0-community/sql/item.cc?PAGE=diffs&REV=4679834eR-SU9AwtX53lhdZ-6HXkDQ For Gentoo users there are two resolutions; release the newer version into portage, or backport the patch above using the mysql-extras tarball. 5.0.54 is in the tree now pmasked for more testing, resolving this. |
