Bug #7705 CONVERT_TZ() crashes with subquery/WHERE on index column
| Submitted: | 6 Jan 2005 14:02 | Modified: | 5 Feb 2005 1:48 |
|---|---|---|---|
| Reporter: | Andrew Edem | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 4.1.8 | OS: | Linux (Linux/RedHat9) |
| Assigned to: | Dmitry Lenev | CPU Architecture: | Any |
[6 Jan 2005 14:02]
Andrew Edem
[6 Jan 2005 14:19]
Hartmut Holzgraefe
also crashes 5.0 (bk build from Dec 20th, using SuSE 9.0)
[6 Jan 2005 20:54]
Andrew Edem
After further investigation of the first problem, it seems as though there is an issue with the arguments passed to the function. When args[2]->const_item() is called in Item_func_convert_tz::fix_fields(), it returns 0, but, when it is called in: Item_func_convert_tz::get_date(), args[2]->const_item() returns 1, this means that the to_tz variable is never initialized, which causes the segmentation violation. Unfortunately I'm not familiar enough with the internals of mysql to guess as to why this is happening. Any ideas?
[7 Jan 2005 13:44]
Andrew Edem
I have created a patch that works around this problem. I do not thing that this is an actual solution, because it does not address the core problem which is that in some cases object's arguments args[1] and args[2] are always marked as constant when get_date() is called, regardless of whether or not they are constant strings. My solution is to simply always look up both time zone arguments every time the function is called. Obviously this is going to lead to performance penalties if you perform a CONVERT_TZ() with one time zone as a constant string and another as a column name on a large number of rows. However, at least it won't cause mysqld to SEGV. Patch: http://www.kaxis.cx/~andrew/item_timefunc.cc.diff
[29 Jan 2005 18:52]
Dmitry Lenev
Fixed in 4.1.10 and 5.0.3
[5 Feb 2005 1:48]
Paul DuBois
Mentioned in 4.1.10 and 5.0.3 change notes.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.055 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.