BUG #15910: Valgrind-detected error in DecodeTimeOnly
The following bug has been logged on the website:
Bug reference: 15910
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 12beta2
Operating system: Ubuntu 18.04
Description:
When executing the following query:
SELECT time with time zone '04:05:06 m2';
I get a strange result:
timetz
-------------------
04:05:06+02:30:17
and the valgrind errors:
==00:00:00:07.177 31724== Conditional jump or move depends on uninitialised
value(s)
==00:00:00:07.177 31724== at 0x57333D: DetermineTimeZoneOffsetInternal
(datetime.c:1485)
==00:00:00:07.177 31724== by 0x573DA6: DetermineTimeZoneOffset
(datetime.c:1445)
==00:00:00:07.177 31724== by 0x575FEE: DecodeTimeOnly (datetime.c:2317)
==00:00:00:07.177 31724== by 0x570D6B: timetz_in (date.c:1994)
==00:00:00:07.177 31724== by 0x67356B: InputFunctionCall (fmgr.c:1548)
==00:00:00:07.177 31724== by 0x67378C: OidInputFunctionCall
(fmgr.c:1651)
==00:00:00:07.177 31724== by 0x30C312: stringTypeDatum
(parse_type.c:641)
==00:00:00:07.177 31724== by 0x2F282F: coerce_type (parse_coerce.c:304)
==00:00:00:07.177 31724== by 0x2F1B15: coerce_to_target_type
(parse_coerce.c:103)
==00:00:00:07.177 31724== by 0x2F8E4A: transformTypeCast
(parse_expr.c:2813)
==00:00:00:07.177 31724== by 0x2F83F8: transformExprRecurse
(parse_expr.c:202)
==00:00:00:07.177 31724== by 0x2F807F: transformExpr (parse_expr.c:155)
==00:00:00:07.177 31724== Uninitialised value was created by a stack
allocation
==00:00:00:07.177 31724== at 0x570C8E: timetz_in (date.c:1972)
==00:00:00:07.177 31724==
...
==00:00:00:07.179 31724== Conditional jump or move depends on uninitialised
value(s)
==00:00:00:07.179 31724== at 0x6B2165: pg_next_dst_boundary
(localtime.c:1698)
==00:00:00:07.179 31724== by 0x573447: DetermineTimeZoneOffsetInternal
(datetime.c:1508)
==00:00:00:07.179 31724== by 0x573DA6: DetermineTimeZoneOffset
(datetime.c:1445)
==00:00:00:07.179 31724== by 0x575FEE: DecodeTimeOnly (datetime.c:2317)
==00:00:00:07.179 31724== by 0x570D6B: timetz_in (date.c:1994)
==00:00:00:07.179 31724== by 0x67356B: InputFunctionCall (fmgr.c:1548)
==00:00:00:07.179 31724== by 0x67378C: OidInputFunctionCall
(fmgr.c:1651)
==00:00:00:07.179 31724== by 0x30C312: stringTypeDatum
(parse_type.c:641)
==00:00:00:07.179 31724== by 0x2F282F: coerce_type (parse_coerce.c:304)
==00:00:00:07.179 31724== by 0x2F1B15: coerce_to_target_type
(parse_coerce.c:103)
==00:00:00:07.179 31724== by 0x2F8E4A: transformTypeCast
(parse_expr.c:2813)
==00:00:00:07.179 31724== by 0x2F83F8: transformExprRecurse
(parse_expr.c:202)
==00:00:00:07.180 31724== Uninitialised value was created by a stack
allocation
==00:00:00:07.180 31724== at 0x570C8E: timetz_in (date.c:1972)
Bug reference: 15910
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 12beta2
Operating system: Ubuntu 18.04
Description:When executing the following query:
SELECT time with time zone '04:05:06 m2';
I get a strange result:
timetz
-------------------
04:05:06+02:30:17
and the valgrind errors:
==00:00:00:07.177 31724== Conditional jump or move depends on uninitialised
value(s)
==00:00:00:07.177 31724== at 0x57333D: DetermineTimeZoneOffsetInternal
(datetime.c:1485)
==00:00:00:07.177 31724== by 0x573DA6: DetermineTimeZoneOffset
The attached patch fixes this issue.
Best regards,
Alexander
Attachments:
fix-DecodeTimeOnly.patchtext/x-patch; name=fix-DecodeTimeOnly.patchDownload+6-0
Hello hackers,
16.07.2019 19:24, Alexander Lakhin wrote:
Bug reference: 15910
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 12beta2
Operating system: Ubuntu 18.04
Description:When executing the following query:
SELECT time with time zone '04:05:06 m2';
I get a strange result:
timetz
-------------------
04:05:06+02:30:17The attached patch fixes this issue.
In case this bug is worth fixing, please look at the improved patch with
the corresponding regression test.
Best regards,
Alexander
Attachments:
fix-DecodeTimeOnly-v2.patchtext/x-patch; name=fix-DecodeTimeOnly-v2.patchDownload+14-0
On Mon, Aug 05, 2019 at 08:55:55AM +0300, Alexander Lakhin wrote:
In case this bug is worth fixing, please look at the improved patch with
the corresponding regression test.
In this case, DecodeSpecial() decodes the abbrevation passed down as
UNITS, which is right on its own. Still, afterwards the code fails to
correctly set a date from the string present. In short, your
suggestion of fix looks good to me and that's more consistent with the
full timezone spec case. The test case you added in this patch
triggers the error in the code path where the timezone is not
specified. Could you add an extra test case for the timezone
abbreviation?
Note that the next set of minor versions is very close by (we are in a
cease-fire period for commits on back-branches), so this won't be
fixed in the upcoming releases.
--
Michael
On Tue, Aug 06, 2019 at 03:21:11PM +0900, Michael Paquier wrote:
Note that the next set of minor versions is very close by (we are in a
cease-fire period for commits on back-branches), so this won't be
fixed in the upcoming releases.
By the way, as long as I do not forget, could you add this patch to
the next CF [1]https://commitfest.postgresql.org/24/ -- Michael as a bug fix? It is fine to add me as a reviewer.
[1]: https://commitfest.postgresql.org/24/ -- Michael
--
Michael
Hello Michael,
06.08.2019 9:21, Michael Paquier wrote:
On Mon, Aug 05, 2019 at 08:55:55AM +0300, Alexander Lakhin wrote:
In case this bug is worth fixing, please look at the improved patch with
the corresponding regression test.In this case, DecodeSpecial() decodes the abbrevation passed down as
UNITS, which is right on its own. Still, afterwards the code fails to
correctly set a date from the string present. In short, your
suggestion of fix looks good to me and that's more consistent with the
full timezone spec case. The test case you added in this patch
triggers the error in the code path where the timezone is not
specified. Could you add an extra test case for the timezone
abbreviation?
Sure, please look at the improved fix.
Best regards,
Alexander
Attachments:
fix-DecodeTimeOnly-v3.patchtext/x-patch; name=fix-DecodeTimeOnly-v3.patchDownload+21-0
06.08.2019 9:24, Michael Paquier wrote:
On Tue, Aug 06, 2019 at 03:21:11PM +0900, Michael Paquier wrote:
Note that the next set of minor versions is very close by (we are in a
cease-fire period for commits on back-branches), so this won't be
fixed in the upcoming releases.By the way, as long as I do not forget, could you add this patch to
the next CF [1] as a bug fix? It is fine to add me as a reviewer.
Thank you Michael. It's done:
https://commitfest.postgresql.org/24/2231/
Best regards,
Alexander
On Wed, Aug 07, 2019 at 07:12:48AM +0300, Alexander Lakhin wrote:
Sure, please look at the improved fix.
Thanks Alexander. I have been able to look at that today, and applied
the patch down to 9.4, after testing each branch. Valgrind was
complaining all the way down..
--
Michael