Thread: 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
Attachment
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:17 >> > The 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
Attachment
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
Attachment
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. [1]: https://commitfest.postgresql.org/24/ -- Michael
Attachment
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
Attachment
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. > > [1]: https://commitfest.postgresql.org/24/ 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