Thread: [sqlsmith] Failing assertions in spgtextproc.c

I do see two assertions in spgtextproc.c fail on occasion when testing
with sqlsmith:

TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)

I can't reproduce it reliably but looking at the coredumps, the failing
part of the expression is always
   in->level == 0 && DatumGetPointer(in->reconstructedValue) == NULL

In all of the dumps I looked at, in->reconstructedValue contains a
zero-length text instead of the asserted NULL, and the tuples fed to
leaf_consistent()/inner_consistent() look like the one below.

,----
| (gdb) p *in
| $1 = {scankeys = 0x60a3ee0, nkeys = 1, reconstructedValue = 101373680, level = 0, 
|   returnData = 1 '\001', allTheSame = 1 '\001', hasPrefix = 0 '\000', prefixDatum = 0, nNodes = 8, 
|   nodeLabels = 0x37b6768}
| (gdb) x ((text *)in->reconstructedValue)->vl_len_
| 0x60ad6f0:    0x00000010
| (gdb) p *(text *)in->scankeys[0]->sk_argument
| $2 = {vl_len_ = "0\000\000", vl_dat = 0x855950c "sqlsmith~", '\177' <repeats 8123 times>, "\020 "}
| (gdb) p in->nodeLabels[0]
| $3 = 65535
`----

Maybe these assertions are just too strict?  I don't see the code
misbehaving when relaxing them to
   reconstrValue != NULL && VARSIZE_ANY_EXHDR(reconstrValue) == in->level     || in->level == 0

regards,
Andreas

On Fri, Dec 18, 2015 at 1:23 PM, Andreas Seltenreich <seltenreich@gmx.de> wrote:
> I do see two assertions in spgtextproc.c fail on occasion when testing
> with sqlsmith:
>
> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)
>
> I can't reproduce it reliably but looking at the coredumps, the failing
> part of the expression is always
>
>     in->level == 0 && DatumGetPointer(in->reconstructedValue) == NULL
>
> In all of the dumps I looked at, in->reconstructedValue contains a
> zero-length text instead of the asserted NULL, and the tuples fed to
> leaf_consistent()/inner_consistent() look like the one below.

Can you do this?:

(gdb) p debug_query_string

It's a global variable, often useful in these situations.

-- 
Peter Geoghegan

Peter Geoghegan writes:

> Can you do this?:
>
> (gdb) p debug_query_string

output below.  Since sqlsmith ist no longer restricted to read-only
statements, the chances for reproduction are low :-/.

select pg_catalog.pg_stat_get_buf_written_backend() as c0, subq_1.c0 as c1, subq_1.c0 as c2, subq_1.c0 as c3
from (select       (select ordinal_position from information_schema.parameters limit 1 offset 12)as c0,       ref_2.t
asc1     from       public.radix_text_tbl as ref_2         inner join pg_catalog.pg_stat_activity as ref_3         on
(ref_2.t= ref_3.application_name )     where ref_2.t @@ cast(coalesce(ref_2.t, ref_3.client_hostname) as text)
limit111) as subq_1, lateral (select       subq_1.c0 as c0,       subq_2.c2 as c1,       56 as c2,
cast(coalesce(cast(coalesce((selectpop from public.real_city limit 1 offset 34)
 
, subq_1.c0) as integer), subq_2.c0) as integer) as c3,       74 as c4,       (select unique1 from public.onek2 limit 1
offset17)as c5     from       (select             (select ordinal_position from information_schema.parameters limit 1
offset27)as c0,             sample_2.umoptions as c1,             sample_2.umserver as c2           from
pg_catalog.pg_user_mappingas sample_2 tablesample system (6.2)           where 49 is NULL) as subq_2     where
cast(coalesce(subq_1.c0,subq_2.c0) as integer) is not NULL     limit 105) as subq_3
 
where ((select x from public.tt0 limit 1 offset 12)<= subq_3.c0) and (subq_3.c4 <= 30);

Andreas Seltenreich <seltenreich@gmx.de> writes:
> I do see two assertions in spgtextproc.c fail on occasion when testing
> with sqlsmith:
> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)

Can you show us the definition of the index that's causing this,
and some samples of the data you're putting in it?
        regards, tom lane

On 2015-12-19 07:04:09 +0100, Andreas Seltenreich wrote:
> output below.  Since sqlsmith ist no longer restricted to read-only
> statements, the chances for reproduction are low :-/.

How many backends are concurrently writing data with sqlsmith? Just one?
If so, and possibly even otherwise, it might be worthwhile to set up
PITR and record the LSN at the beginning of transactions. That'd allow
to replay the state of the database to just before the failing xact.

Regards,

Andres

Tom Lane writes:

> Andreas Seltenreich <seltenreich@gmx.de> writes:
>> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
>> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)
>
> Can you show us the definition of the index that's causing this,
> and some samples of the data you're putting in it?

Here's a recipe for triggering the former:
   create table t(c text);   create index on t using spgist(c);   insert into t select '' from
generate_series(1,10000);  set enable_seqscan to off; select count(1) from t;
 

I still think it's just the assertions being too strict.

regards,
Andreas

Andreas Seltenreich <seltenreich@gmx.de> writes:
> Here's a recipe for triggering the former:

>     create table t(c text);
>     create index on t using spgist(c);
>     insert into t select '' from generate_series(1,10000);
>     set enable_seqscan to off; select count(1) from t;

Ah-hah.  Thanks for the test case.

> I still think it's just the assertions being too strict.

Yes, now I agree.  Fix pushed.
        regards, tom lane