Re: jsonpath

On 4/14/19 10:43 PM, Alexander Korotkov wrote:
> 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?
>

I have downgraded jacana to gcc 7.3.0, which has resolved the problem.
I'm still a bit worried that we're clobbering the stack somehow though.
I have no idea how to test that.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services