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:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL pollutes the file system
Next
From: Alvaro Herrera
Date:
Subject: Re: PostgreSQL pollutes the file system