Thread: core dump on 8.1 and no dump on REL8_1_STABLE

core dump on 8.1 and no dump on REL8_1_STABLE

From
Teodor Sigaev
Date:
Hi!

Attached dump cause core on 8.1 release and works fine on REL8_1_STABLE and HEAD.
Am I missed some fixes/commits?


PS dump in KOI8, db should be initialized as
initdb -E KOI8-R --locale ru_RU.KOI8-R -D $DIR
and it should be installed ltree and tsearch2 modules.

PPS gdb output:
  Program received signal SIGSEGV, Segmentation fault.
0xb70f3f55 in crc32_sz (buf=0x1c4fabe1 <Address 0x1c4fabe1 out of bounds>,
size=1282) at crc32.c:101
101                     _CRC32_(crc, *p);
(gdb) bt
#0  0xb70f3f55 in crc32_sz (buf=0x1c4fabe1 <Address 0x1c4fabe1 out of bounds>,
size=1282) at crc32.c:101
#1  0xb70f5f9d in gtsvector_compress (fcinfo=0xffffffff) at gistidx.c:161
#2  0x0821e8fd in FunctionCall1 (flinfo=0xffffffff, arg1=16777215) at fmgr.c:1128
#3  0x0807f752 in gistcentryinit (giststate=0xffffffff, nkey=0, e=0xbfdfb0c4,
k=4294967295, r=0x0, pg=0x0, o=0, b=-1,
     l=1 '\001', isNull=0 '\0') at gistutil.c:731
#4  0x0807f0e0 in gistinsert (fcinfo=0xffffffff) at gist.c:255
#5  0x0821ecbe in FunctionCall6 (flinfo=0xffffff, arg1=4294967295,
arg2=4294967295, arg3=4294967295, arg4=4294967295,
     arg5=4294967295, arg6=4294967295) at fmgr.c:1267
#6  0x08091d1a in index_insert (indexRelation=0xb7121620, values=0xbfdfb39c,
isnull=0xbfdfb41c "", heap_t_ctid=0x837781c,
     heapRelation=0xb7172ab8, check_uniqueness=0 '\0') at indexam.c:215
#7  0x08131f23 in ExecInsertIndexTuples (slot=0x8373900, tupleid=0x837781c,
estate=0x8373530, is_vacuum=0 '\0')
     at execUtils.c:936
#8  0x0812ac67 in ExecutorRun (queryDesc=0x8373150,
direction=ForwardScanDirection, count=0) at execMain.c:1695
#9  0x081ab6a1 in ProcessQuery (parsetree=Variable "parsetree" is not available.
) at pquery.c:174
#10 0x081acb6a in PortalRun (portal=0x8370f78, count=2147483647, dest=0x82c517c,
altdest=0x82c517c,
     completionTag=0xbfdfb688 "") at pquery.c:1076
#11 0x081a892f in exec_simple_query (
     query_string=0x83591f8 "UPDATE \"Предприятия\" SET \"rubriks\"='\\'11\\'
\\'17\\' \\'116\\' \\'135\\' \\'253\\' \\'303\\' \\'409\\' \\'415\\' \\'772\\'
\\'1276\\' \\'1283\\' \\'1284\\' \\'1438\\' \\'1456\\'' WHERE \"id\"='66.20815';\n")
     at postgres.c:1014
#12 0x081aa230 in PostgresMain (argc=1, argv=0x8307248, username=0x83094a8
"postgres") at postgres.c:3168
#13 0x08148fb4 in main (argc=6, argv=0x8307248) at main.c:322



--
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Attachment

Re: core dump on 8.1 and no dump on REL8_1_STABLE

From
Tom Lane
Date:
Teodor Sigaev <teodor@sigaev.ru> writes:
> Attached dump cause core on 8.1 release and works fine on REL8_1_STABLE and HEAD.
> Am I missed some fixes/commits?

In HEAD I get

\i tsearch2.sql
...
\i ltree.sql
...
\i tsearch2_crash.dump
CREATE TABLE
ALTER TABLE
psql:tsearch2_crash.dump:86: ERROR:  syntax error at position 0 near "�"
CONTEXT:  COPY �����������, line 1, column name_ltree: "�.�.�.�.�.�.�.�.�.�.�.�.�.�"
psql:tsearch2_crash.dump:96: NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create
implicit index "�����������_pkey" for table "�����������"
ALTER TABLE
CREATE INDEX
REVOKE
REVOKE
GRANT
GRANT
UPDATE 0

The "syntax error" doesn't seem very promising --- maybe this dump needs
a particular locale/encoding setting to work (or fail as the case may
be)?
        regards, tom lane


Re: core dump on 8.1 and no dump on REL8_1_STABLE

From
Oleg Bartunov
Date:
On Wed, 23 Nov 2005, Tom Lane wrote:

> Teodor Sigaev <teodor@sigaev.ru> writes:
>> Attached dump cause core on 8.1 release and works fine on REL8_1_STABLE and HEAD.
>> Am I missed some fixes/commits?
>
> In HEAD I get
>
> \i tsearch2.sql
> ...
> \i ltree.sql
> ...
> \i tsearch2_crash.dump
> CREATE TABLE
> ALTER TABLE
> psql:tsearch2_crash.dump:86: ERROR:  syntax error at position 0 near "Й"
> CONTEXT:  COPY чьИАеьХНЕХН, line 1, column name_ltree: "Й.Ф.Е.Э.Й.М.А.Х.Э.Ш.И.Ж.Е.ь"
> psql:tsearch2_crash.dump:96: NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create
> implicit index "чьИАеьХНЕХН_pkey" for table "чьИАеьХНЕХН"
> ALTER TABLE
> CREATE INDEX
> REVOKE
> REVOKE
> GRANT
> GRANT
> UPDATE 0
>
> The "syntax error" doesn't seem very promising --- maybe this dump needs
> a particular locale/encoding setting to work (or fail as the case may
> be)?

yes, it works fine for KOI8. I just load this dump into HEAD.

>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>
    Regards,        Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Re: core dump on 8.1 and no dump on REL8_1_STABLE

From
Teodor Sigaev
Date:
initdb -E KOI8-R --locale ru_RU.KOI8-R -D $DIR

> In HEAD I get

HEAD and REL8_1STABLE works fine, 8.1 release not (I don't test REL8_1_0, just 
take a source package)

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


Re: core dump on 8.1 and no dump on REL8_1_STABLE

From
Atsushi Ogawa
Date:
I reproduced the problem by loading this dump to 8.1.0.
I think that the problem is the same as this:
http://archives.postgresql.org/pgsql-hackers/2005-11/msg01016.php

I saw heap_tuple_toast_attrs() overwrites a new tuple. And, backend
crashed while executing ExecInsertIndexTuples().

The problem occurs by the table like the following structures.(1)The table has a varlena column.(2)The table has a
columnwith check constraint after the varlena column.(3)The table has a indexed column after the column with check
constraint.
And, the problem occurs if a tuple for which TOAST is necessary is
inserted or updated.

Example:

create table test_tbl (   varlena_col     text,   check_col       text,   index_col       text,   constraint
test_tbl_chkcheck (check_col ~ '^[0-9]+$') 
);

create index test_tbl_idx on test_tbl(index_col);

insert into test_tbl (varlena_col, check_col, index_col)
values('A', '0', 'B');

update test_tbl
set varlena_col = repeat('A', 2000)
where index_col = 'B';

The backend will be crashed or wrong data will be registered to the index.
If backend is not crashed, Index Scan might return the wrong result.

explain select count(*) from test_tbl where index_col = 'B';                             QUERY PLAN
---------------------------------------------------------------------------Aggregate  (cost=8.50..8.51 rows=1 width=0)
-> Bitmap Heap Scan on test_tbl  (cost=2.01..8.49 rows=3 width=0)        Recheck Cond: (index_col = 'B'::text)
-> Bitmap Index Scan on test_tbl_idx  (cost=0.00..2.01 rows=3 width=0)              Index Cond: (index_col = 'B'::text) 

select count(*) from test_tbl where index_col = 'B';count
-------    0  (Wrong result. Correct result is 1.)

--- Atsushi Ogawa


Re: core dump on 8.1 and no dump on REL8_1_STABLE

From
Tom Lane
Date:
Atsushi Ogawa <atsushi.ogawa@gmail.com> writes:
> I reproduced the problem by loading this dump to 8.1.0.
> I think that the problem is the same as this:
> http://archives.postgresql.org/pgsql-hackers/2005-11/msg01016.php

Good catch --- I agree that bug probably explains it.
        regards, tom lane