Re: jsonpath - Mailing list pgsql-hackers
From | Tomas Vondra |
---|---|
Subject | Re: jsonpath |
Date | |
Msg-id | 20190327144518.GA28958@development Whole thread Raw |
In response to | Re: jsonpath (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
List | pgsql-hackers |
On Wed, Mar 27, 2019 at 05:37:40PM +0300, Alexander Korotkov wrote: >On Wed, Mar 27, 2019 at 4:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Alexander Korotkov <a.korotkov@postgrespro.ru> writes: >> > Still no reproduction. >> >> Annoying, but it's probably not worth expending more effort on >> right now. I wonder whether that buildfarm animal can be upgraded >> to capture core dump stack traces --- if so, then if it happens >> again we'd have more info. > >Hopefully, Andrew will manage to get a backtrace [1]. > >BTW, while searching for this bug, I've collected this backtrace using valgrind. > >==00:00:00:14.596 10866== Conditional jump or move depends on >uninitialised value(s) >==00:00:00:14.596 10866== at 0x579F8C4: ____strtod_l_internal (in >/usr/lib64/libc-2.17.so) >==00:00:00:14.596 10866== by 0x771561: float8in_internal_opt_error >(float.c:394) >==00:00:00:14.596 10866== by 0x7718B9: float8in_internal (float.c:515) >==00:00:00:14.596 10866== by 0x7718B9: float8in (float.c:336) >==00:00:00:14.596 10866== by 0x842D43: DirectFunctionCall1Coll (fmgr.c:803) >==00:00:00:14.596 10866== by 0x7C9649: numeric_float8 (numeric.c:3417) >==00:00:00:14.596 10866== by 0x842D43: DirectFunctionCall1Coll (fmgr.c:803) >==00:00:00:14.596 10866== by 0x7A1D8D: jsonb_float8 (jsonb.c:2058) >==00:00:00:14.596 10866== by 0x5F8F54: ExecInterpExpr (execExprInterp.c:649) >==00:00:00:14.596 10866== by 0x6A2E19: ExecEvalExprSwitchContext >(executor.h:307) >==00:00:00:14.596 10866== by 0x6A2E19: evaluate_expr (clauses.c:4827) >==00:00:00:14.596 10866== by 0x6A45FF: evaluate_function (clauses.c:4369) >==00:00:00:14.596 10866== by 0x6A45FF: simplify_function (clauses.c:3999) >==00:00:00:14.596 10866== by 0x6A31C1: >eval_const_expressions_mutator (clauses.c:2474) >==00:00:00:14.596 10866== by 0x644466: expression_tree_mutator >(nodeFuncs.c:3072) >==00:00:00:14.596 10866== >{ > <insert_a_suppression_name_here> > Memcheck:Cond > fun:____strtod_l_internal > fun:float8in_internal_opt_error > fun:float8in_internal > fun:float8in > fun:DirectFunctionCall1Coll > fun:numeric_float8 > fun:DirectFunctionCall1Coll > fun:jsonb_float8 > fun:ExecInterpExpr > fun:ExecEvalExprSwitchContext > fun:evaluate_expr > fun:evaluate_function > fun:simplify_function > fun:eval_const_expressions_mutator > fun:expression_tree_mutator >} > >Not sure whether it's related to 16d489b0fe. Will investigate more. > This might be another case of false positive due to SSE (which I think is used by strtod in some cases). But I'd expect strncasecmp in the stack in that case, so maybe that's not it. cheers -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql-hackers by date: