Bug #51357 crash when using handler commands on spatial indexes
| Submitted: | 20 Feb 2010 20:47 | Modified: | 18 Jun 2010 1:54 |
|---|---|---|---|
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: GIS | Severity: | S1 (Critical) |
| Version: | 4.1.25,5.0.90,5.1.45,5.5.1-m2,5.5.99-m3 | OS: | Any |
| Assigned to: | Georgi Kodinov | CPU Architecture: | Any |
| Tags: | crash, handler, spatial | ||
[20 Feb 2010 20:47]
Shane Bester
[21 Feb 2010 9:04]
Valeriy Kravchuk
Thank you for the bug report. Verified just as described on Mac OS X.
[26 Feb 2010 11:42]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/101598 3358 Georgi Kodinov 2010-02-26 Bug #51357: crash when using handler commands on spatial indexes Spatial indexes were not checking for out-of-record condition in the handler next command when the previous command didn't found rows. Fixed by making the rtree index to check for end of rows condition before re-using the key from the previous search.
[4 Mar 2010 14:50]
Georgi Kodinov
Ramil has found a new crashing scenario (even with my fix):
CREATE TABLE t1(a GEOMETRY NOT NULL,SPATIAL INDEX a(a));
HANDLER t1 OPEN;
HANDLER t1 READ a FIRST;
INSERT INTO t1 VALUES (GeomFromText('Polygon((40 40,60 40,60 60,40 60,40 40))'));
HANDLER t1 READ a NEXT;
HANDLER t1 CLOSE;
DROP TABLE t1;
Looking into it now.
[4 Mar 2010 16:13]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/102352 3358 Georgi Kodinov 2010-03-04 Bug #51357: crash when using handler commands on spatial indexes Spatial indexes were not checking for out-of-record condition in the handler next command when the previous command didn't found rows. Fixed by making the rtree index to check for end of rows condition before re-using the key from the previous search. Fixed another crash if the tree has changed since the last search. Added a test case for the other error.
[8 Mar 2010 10:02]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/102549 3373 Georgi Kodinov 2010-03-04 Bug #51357: crash when using handler commands on spatial indexes Spatial indexes were not checking for out-of-record condition in the handler next command when the previous command didn't found rows. Fixed by making the rtree index to check for end of rows condition before re-using the key from the previous search. Fixed another crash if the tree has changed since the last search. Added a test case for the other error.
[8 Mar 2010 10:40]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/102559 2849 Georgi Kodinov 2010-03-08 Backport of the fix for bug #51357 to 5.0-bugteam.: Spatial indexes were not checking for out-of-record condition in the handler next command when the previous command didn't found rows. Fixed by making the rtree index to check for end of rows condition before re-using the key from the previous search. Fixed another crash if the tree has changed since the last search. Added a test case for the other error.
[9 Mar 2010 17:01]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/102758 3380 Georgi Kodinov 2010-03-09 Disable the second part of the test for bug #51357 until bug #51877 is fixed.
[26 Mar 2010 8:23]
Bugs System
Pushed into 5.5.4-m3 (revid:alik@sun.com-20100326080914-2pz8ns984e0spu03) (version source revid:alexey.kopytov@sun.com-20100312095153-t4rtoqc7p96lmxvh) (merge vers: 5.5.3-m2) (pib:16)
[26 Mar 2010 8:27]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100326081116-m3v4l34yhr43mtsv) (version source revid:alik@sun.com-20100325072612-4sds00ix8ajo1e84) (pib:16)
[26 Mar 2010 8:31]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100326081944-qja07qklw1p2w7jb) (version source revid:alik@sun.com-20100325073410-4t4i9gu2u1pge7xb) (merge vers: 6.0.14-alpha) (pib:16)
[6 Apr 2010 7:53]
Bugs System
Pushed into 5.0.91 (revid:joro@sun.com-20100406075152-flz4btqirl9hly31) (version source revid:joro@sun.com-20100308103957-byh54e6q91b5h4om) (merge vers: 5.0.91) (pib:16)
[6 Apr 2010 7:58]
Bugs System
Pushed into 5.1.46 (revid:sergey.glukhov@sun.com-20100405111026-7kz1p8qlzglqgfmu) (version source revid:joro@sun.com-20100309170015-3ajklvjyjsby9a18) (merge vers: 5.1.45) (pib:16)
[14 Apr 2010 19:45]
Paul DuBois
Noted in 5.0.91, 5.1.46, 5.5.5, 6.0.14 changelogs. Use of HANDLER statements with tables that had spatial indexes caused a server crash.
[17 Jun 2010 12:16]
Bugs System
Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:03]
Bugs System
Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:martin.skold@mysql.com-20100609211156-tsac5qhw951miwtt) (merge vers: 5.1.46-ndb-6.2.19) (pib:16)
[17 Jun 2010 13:44]
Bugs System
Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.079 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.