Re: [BUGS] BUG #14897: Segfault on statitics SQL request - Mailing list pgsql-bugs

From Dmitry Dolgov
Subject Re: [BUGS] BUG #14897: Segfault on statitics SQL request
Date
Msg-id CA+q6zcXe9aV5NV88u9Y=vMp+=fP7QOXgTyFQhzuvmCvTBvb_kQ@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] BUG #14897: Segfault on statitics SQL request  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] BUG #14897: Segfault on statitics SQL request  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
> On 10 November 2017 at 23:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> It'd definitely be interesting to see a stack trace, if you manage
> to reproduce the problem in a debug-enabled build.

Looks like I can reproduce something close to this issue on my Gentoo
installation using the provided dataset, but it looks quite weird for me:

at `numeric.c:4468` we generate `PolyNumAggState *result` as `Int128AggState`

4468    result = makePolyNumAggStateCurrentContext(false);

3972 static Int128AggState *
3973 makeInt128AggStateCurrentContext(bool calcSumX2)
3974 {
3975    Int128AggState *state;
3976
3977    state = (Int128AggState *) palloc0(sizeof(Int128AggState));
3978    state->calcSumX2 = calcSumX2;
3979
3980    return state;
3981 }

And as the result of this function we've got:

>>> p *state
>>> $2 = {
>>>   calcSumX2 = 0 '\000',
>>>   N = 0,
>>>   sumX = 0x00000000000000000000000000000000,
>>>   sumX2 = 0x00000000000000000000000000000000
>>> }

And after that `result->sumX` is passed to `numericvar_to_int128`

4479 #ifdef HAVE_INT128
4480    numericvar_to_int128(&num, &result->sumX);
4481 #else
4482    accum_sum_add(&result->sumX, &num);
4483 #endif

At `numeric.c:6348` we've got a segmentation fault

6348    *result = neg ? -val : val;
>>> p *result
$3 = 0x00000000000000000000000000000000

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #14897: Segfault on statitics SQL request
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #14897: Segfault on statitics SQL request