Re: jsonpath

On Tue, Apr 9, 2019 at 7:16 PM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)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(at)entry=0x0,
message=message(at)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(at)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