Re: jsonpath

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

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