Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory
| От | Jia Yu |
|---|---|
| Тема | Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory |
| Дата | |
| Msg-id | CAN7JVgWr7twnnSpJ=xi=NmsVXsreo7Y71PszSw_9yJQ5t6GUZA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory (Jia Yu <jiayu198910@gmail.com>) |
| Список | pgsql-hackers |
Dear Hackers,
Sorry for bothering you again!
I have migrated my index method from PG 9.5 to PG 9.6.1 as Tom suggested. The same problem still exists. The index works fine if I just call it through my new SQL script in regression test (call "make check").
I am doubting whether this is caused by some security issues.
I compiled the code on PG 9.6.1 with flag -O0. It gave me this same error. The new backtraces are as this:
-----------------------------------
#0 0x000000000046bfbd in hippobuild (heap=<error reading variable: Cannot access memory at address 0x7ffc19b50d58>, index=<error reading variable: Cannot access memory at address 0x7ffc19b50d50>, indexInfo=<error reading variable: Cannot access memory at address 0x7ffc19b50d48>) at hippo.c:204
#1 0x000000000055d1c9 in index_build (heapRelation=0x7f0f3bdfea88, indexRelation=0x7f0f3be002b0, indexInfo=0x2e1d180, isprimary=0 '\000', isreindex=0 '\000') at index.c:2021
#2 0x000000000055beda in index_create (heapRelation=0x7f0f3bdfea88, indexRelationName=0x2ec2378 "hippo_idx", indexRelationId=20695, relFileNode=0, indexInfo=0x2e1d180, indexColNames=0x2ec0370, accessMethodObjectId=9000, tableSpaceId=0, collationObjectId=0x2ec0938, classObjectId=0x2ec0958,
coloptions=0x2ec0978, reloptions=49030800, isprimary=0 '\000', isconstraint=0 '\000', deferrable=0 '\000', initdeferred=0 '\000', allow_system_table_mods=0 '\000', skip_build=0 '\000', concurrent=0 '\000', is_internal=0 '\000', if_not_exists=0 '\000') at index.c:1099
#3 0x0000000000632d7a in DefineIndex (relationId=12503, stmt=0x2e1d298, indexRelationId=0, is_alter_table=0 '\000', check_rights=1 '\001', skip_build=0 '\000', quiet=0 '\000') at indexcmds.c:651
#4 0x000000000083660e in ProcessUtilitySlow (parsetree=0x2e7ba00, queryString=0x2e7acc8 "create index hippo_idx on hippo_tbl using hippo(id2) with (density=20);\n", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, dest=0xe68c60 <debugtupDR>, completionTag=0x7ffc613bf280 "") at utility.c:1274
#5 0x0000000000835a98 in standard_ProcessUtility (parsetree=0x2e7ba00, queryString=0x2e7acc8 "create index hippo_idx on hippo_tbl using hippo(id2) with (density=20);\n", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, dest=0xe68c60 <debugtupDR>, completionTag=0x7ffc613bf280 "") at utility.c:907
#6 0x0000000000834b71 in ProcessUtility (parsetree=0x2e7ba00, queryString=0x2e7acc8 "create index hippo_idx on hippo_tbl using hippo(id2) with (density=20);\n", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, dest=0xe68c60 <debugtupDR>, completionTag=0x7ffc613bf280 "") at utility.c:336
#7 0x0000000000833c1b in PortalRunUtility (portal=0x2eba198, utilityStmt=0x2e7ba00, isTopLevel=1 '\001', setHoldSnapshot=0 '\000', dest=0xe68c60 <debugtupDR>, completionTag=0x7ffc613bf280 "") at pquery.c:1193
#8 0x0000000000833e2e in PortalRunMulti (portal=0x2eba198, isTopLevel=1 '\001', setHoldSnapshot=0 '\000', dest=0xe68c60 <debugtupDR>, altdest=0xe68c60 <debugtupDR>, completionTag=0x7ffc613bf280 "") at pquery.c:1342
#9 0x000000000083332f in PortalRun (portal=0x2eba198, count=9223372036854775807, isTopLevel=1 '\001', dest=0xe68c60 <debugtupDR>, altdest=0xe68c60 <debugtupDR>, completionTag=0x7ffc613bf280 "") at pquery.c:815
#10 0x000000000082d05b in exec_simple_query (query_string=0x2e7acc8 "create index hippo_idx on hippo_tbl using hippo(id2) with (density=20);\n") at postgres.c:1094
#11 0x0000000000831479 in PostgresMain (argc=6, argv=0x2df5a70, dbname=0x2dfd3c0 "postgres", username=0x2dfd3c0 "postgres") at postgres.c:4070
#12 0x00000000006e7832 in main (argc=6, argv=0x2df5a70) at main.c:224
-------------------------------
The problematic line is at Hippo.c Line 204. Here is the code of that line. It is the regular routine required by designing an index access method. It will build the index.
------------------------------
/*
*This function initializes the entire Hippo. It will call buildcallback many times.
*/
IndexBuildResult *
hippobuild(Relation heap, Relation index, IndexInfo *indexInfo)
Line 204:{
IndexBuildResult *result;
double reltuples;
HippoBuildState buildstate;
Buffer buffer;
Datum *histogramBounds;
int histogramBoundsNum,i;
HeapTuple heapTuple;
Page page;/* Initial page */
Size pageSize;
AttrNumber attrNum;
............
------------------------------
This is my SQL script which works fine when running in PG regression test parallel_schedule. But it fails at normal PG server.
------------------------------
create table hippo_tbl(id int8, id2 int8, payload text);
insert into hippo_tbl(id, id2, payload) select i, random()*1000000, repeat('a', 100) from generate_series (1,1000000) i;
Alter table hippo_tbl alter column id2 set statistics 400;
Analyze hippo_tbl;
create index hippo_idx on hippo_tbl using hippo(id2) with (density=20);
select count(*) from hippo_tbl where id2>100000 and id2 <101000;
insert into hippo_tbl(id, id2, payload) select i, 100009, repeat('a', 100) from generate_series (1, 1000) i;
select count(*) from hippo_tbl where id2>100000 and id2 <101000;
delete from hippo_tbl where id2>100000 and id2 <101000;
VACUUM;
select count(*) from hippo_tbl where id2>100000 and id2 <101000;
drop index hippo_idx;
drop table hippo_tbl;
------------------------------
Any help will be appreciated!
Thanks,
Jia Yu
On Mon, Jan 23, 2017 at 5:12 PM, Jia Yu <jiayu198910@gmail.com> wrote:
Dear Tom,Thanks for your reply!Actually, I already compiled the source code with "-O0" and then got those backtraces.The hippobuild function just starts building an index access method and it will call hippobuildcallback to iterate each parent table tuple in its function body.What makes me fell very confused is that the same code works when I call "make check" to run regression test (testing my index) but fails at running normal PG server.Here are the lines before and after the problematic line hippo.c 154. It is the first line of this function and did nothing.On the other hand, I will try to adjust my code to fit in PG 9.6 as you suggested.-------------------------------------- static void hippobuildcallback(){...............Line 148 }Line 149 /*Line 150 *This function initializes the entire Hippo. It will call buildcallback many times.Line 151 */Line 152 DatumLine 153 hippobuild(PG_FUNCTION_ARGS)Line 154 {Line 155 /** This is some routine declarations for variables*/Relation heap = (Relation) PG_GETARG_POINTER(0);Relation index = (Relation) PG_GETARG_POINTER(1);IndexInfo *indexInfo = (IndexInfo *) PG_GETARG_POINTER(2);IndexBuildResult *result;double reltuples;HippoBuildState buildstate;Buffer buffer;......-------------------------------------- Any hints for this will be greatly appreciated!Thank you very much!Jia YuOn Mon, Jan 23, 2017 at 2:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:Jia Yu <jiayu198910@gmail.com> writes:
> However, these methods don't work in the normal PG server. It gave me
> "segmentation fault"
> ...
> Here is my backtrace. It looks like I cannot access fcinfo. Can you help me
> about this? Or just some hints? I have been struggling with this problem
> for weeks.
What's the problematic line (hippo.c:154) doing? What's before
that in the hippobuild function?
I wouldn't put much stock in the "Cannot access memory" message ... that
just means gdb is confused, which it frequently is. But possibly
building with -O0 would make it less confused.
BTW, I gather from the reference to OidFunctionCall3Coll that you're
using PG 9.5 or older. It'd be a good idea to switch to 9.6, which has
noticeably cleaner indexam APIs that allow some compiler error checking
on those calls.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Corey HuinkerДата:
Сообщение: Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)