Re: jsonpath

On Tue, Apr 9, 2019 at 7:16 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
>
> On Sun, Apr 07, 2019 at 03:03:58AM +0300, Alexander Korotkov wrote:
> >On Sun, Apr 7, 2019 at 2:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> >> > Thus, contents of unused function makes test fail or pass.  So far, it
> >> > looks like a compiler bug.  Any thoughts?
> >>
> >> Yeah :-(.  The fact that we've not seen a similar failure on any other
> >> machines points in that direction, too.  Maybe it's some other aspect
> >> of the machine's toolchain, like flex or bison, but that's not that
> >> much different from our standpoint.
> >>
> >> There's a lot of stuff I don't especially like about jsonpath_scan,
> >> for instance I think the "init" arguments to resizeString etc are
> >> a pretty error-prone and unmaintainable way to do things.  But
> >> I don't see anything that looks like it'd be a portability hazard
> >> that would explain this.
> >>
> >> I still have a nagging feeling that there's a wild store somewhere
> >> in here, but I don't know how to find it based on the limited
> >> evidence we've got.
> >
> >Yeah, it might be not because compiler error.  It might depend on
> >memory layout.  So existence of extra function changes memory layout
> >and, in turn, causes an error.  I will try to disassemble
> >jsonpath_scan.o and see whether content of yyparse2 influences
> >assembly of other functions.
> >
>
> Have you tried other compiler version / different optimization level?

Error goes away with -O0.  Or I just didn't manage to reproduce that.
In my observation error depends on memory layout or something.  So, it
might be that I just didn't manage to reproduce it with -O0 while it
really still persists.  I didn't try other compilers yet.

> Or running it under valgrind. Not sure how difficult that is on Windows.

Valgrind isn't installed there.  I'm not sure how to do that, but I
will probably try.

The interesting thing is that on failure I got following backtrace.

#0  0x00007ff94f86a458 in ntdll!RtlRaiseStatus () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ff94f87760e in ntdll!memset () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ff94dc42e1a in msvcrt!_setjmpex () from
C:\WINDOWS\System32\msvcrt.dll
#3  0x000000000086a37a in pg_re_throw () at elog.c:1720
#4  0x000000000086a166 in errfinish (dummy=<optimized out>) at elog.c:464
#5  0x00000000007c3d18 in jsonpath_yyerror (result=result@entry=0x0,
    message=message@entry=0xa87d38 <__func__.110220+1512>
"unrecognized flag of LIKE_REGEX predicate") at jsonpath_scan.l:276
#6  0x00000000007c5f3d in makeItemLikeRegex (pattern=<optimized out>,
pattern=<optimized out>, flags=<optimized out>, expr=0x7216760) at
jsonpath_gram.y:500
#7  jsonpath_yyparse (result=<optimized out>, result@entry=0x495e818)
at jsonpath_gram.y:178

So, error happens inside implementation of siglongjmp().  I've checked
that contents of *PG_exception_stack didn't change since previous
successfully thrown error.  Probably this implementation of long jump
saves some part of state outside of sigjmp_buf and that part is
corrupt.  Any ideas?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company