(JP) 全件scanを多重実行すると、gpuscan_next_tuple_row()でAssertionFailedとなることがある。

[taiki-k]

#6 の再現テスト中に、#6 とは異なる箇所でAssertionFailedとなることがありました。

こちらは、#6 と比較すると、発生確率がかなり低いと感じます。

※この箇所は、ソースコード上のコメントにTODOと書いてある箇所になりますが、一応報告いたします。

• バックトレース

#0  0x0000003cdbc32925 in raise () from /lib64/libc.so.6
#1  0x0000003cdbc34105 in abort () from /lib64/libc.so.6
#2  0x0000000000949085 in ExceptionalCondition (conditionName=0x7f33469ebc48 "!(rs_index > 0 && rs_index <= rstore->kern.nrows)",
    errorType=0x7f33469eb534 "FailedAssertion", fileName=0x7f33469eb55d "gpuscan.c", lineNumber=793) at assert.c:54
#3  0x00007f33469de111 in gpuscan_next_tuple_row (gss=0x17d6718, slot=0x17d7588) at gpuscan.c:793
#4  0x00007f33469de6e5 in gpuscan_exec (node=0x17d6718) at gpuscan.c:810
#5  0x00000000006807e7 in ExecCustomPlan (cpstate=0x17d6718) at nodeCustom.c:37
#6  0x00000000006684b5 in ExecProcNode (node=0x17d6718) at execProcnode.c:453
#7  0x000000000067dbda in agg_retrieve_direct (aggstate=0x17d5f80) at nodeAgg.c:1230
#8  0x000000000067d9cb in ExecAgg (node=0x17d5f80) at nodeAgg.c:1117
#9  0x0000000000668548 in ExecProcNode (node=0x17d5f80) at execProcnode.c:487
#10 0x0000000000665efe in ExecutePlan (estate=0x17d5e68, planstate=0x17d5f80, operation=CMD_SELECT, sendTuples=1 '\001',
    numberTuples=0, direction=ForwardScanDirection, dest=0x17cc008) at execMain.c:1475
#11 0x0000000000663da8 in standard_ExecutorRun (queryDesc=0x17bb0c8, direction=ForwardScanDirection, count=0) at execMain.c:308
#12 0x0000000000663beb in ExecutorRun (queryDesc=0x17bb0c8, direction=ForwardScanDirection, count=0) at execMain.c:256
#13 0x00000000007f964e in PortalRunSelect (portal=0x17d3e58, forward=1 '\001', count=0, dest=0x17cc008) at pquery.c:946
#14 0x00000000007f9275 in PortalRun (portal=0x17d3e58, count=9223372036854775807, isTopLevel=1 '\001', dest=0x17cc008,
    altdest=0x17cc008, completionTag=0x7fff39e5d440 "") at pquery.c:790
#15 0x00000000007f29e2 in exec_simple_query (query_string=0x1783e38 "SELECT count(*) FROM oku_table WHERE data < 0.01;")
    at postgres.c:1045
#16 0x00000000007f7162 in PostgresMain (argc=1, argv=0x1715fd0, dbname=0x1715ec8 "pgstrom_test", username=0x1715ea8 "tkondo")
    at postgres.c:4004
#17 0x000000000076e18a in BackendRun (port=0x173db00) at postmaster.c:4104
#18 0x000000000076d840 in BackendStartup (port=0x173db00) at postmaster.c:3778
#19 0x0000000000769bfe in ServerLoop () at postmaster.c:1569
#20 0x0000000000769251 in PostmasterMain (argc=1, argv=0x1714e60) at postmaster.c:1222
#21 0x00000000006b8aee in main (argc=1, argv=0x1714e60) at main.c:223

• この時の、rs_indexの値

(gdb) up
#3  0x00007f33469de111 in gpuscan_next_tuple_row (gss=0x17d6718, slot=0x17d7588) at gpuscan.c:793
793                     Assert(rs_index > 0 && rs_index <= rstore->kern.nrows);
(gdb) p rs_index
$1 = 0

[kaigai]

この rs_index の値は、GPUで各レコードを評価した結果、どの行が検索条件にマッチしているかを保持する kresult->results 配列のインデックスです。

core dump が上書きされていなければ、

• kresult の各フィールド
• kresult->results[0] ~ kresult->results[10] くらいまで

の、値をダンプして頂けますか？

もしかすると OpenCL 側での可能性もあります。

[taiki-k]

kresultの各フィールドとkresult->results[0]～kresults[10]までのダンプです。

(gdb) p *kresult
$3 = {
  nrooms = 123360,
  nitems = 4096,
  debug_nums = 0,
  debug_usage = 4294967295,
  errcode = 0,
  results = 0x7f333e2b20c0
}
(gdb) p kresult->results[0]
$4 = 12289
(gdb) p kresult->results[1]
$5 = 12290
(gdb) p kresult->results[2]
$6 = 12291
(gdb) p kresult->results[3]
$7 = 12292
(gdb) p kresult->results[4]
$8 = 12293
(gdb) p kresult->results[5]
$9 = 12294
(gdb) p kresult->results[6]
$10 = 12295
(gdb) p kresult->results[7]
$11 = 12296
(gdb) p kresult->results[8]
$12 = 12297
(gdb) p kresult->results[9]
$13 = 12298
(gdb) p kresult->results[10]
$14 = 12299

[kaigai]

条件式にもよりますが、OpenCLから返ってきた戻り値は正当に思えます。
(0 ~ 123360 : nrooms の範囲内に収まっている)

本体側で何番目の行まで読んだかを示す gss->curr_index の値の戻し
忘れの可能性がありますので、お手数ですが

gss->curr_index

の値を見せていただけますか？

[taiki-k]

gss->curr_indexの値です。

(gdb) p gss->curr_index
$1 = 1862

不要かもしれませんが、1862番付近のkresult->results[]の値も提示します。
(1861番目以降は、すべて0のようです)

(gdb) p (int[100])*(kresult->results + 1850)
$3 = {14139, 14140, 14141, 14142, 14143, 14144, 14145, 14146, 14147, 14148, 14149, 0 <repeats 89 times>}

[taiki-k]

再現テスト中に新たに発生した現象(SIGSEGV)時のkresultの各フィールドとkresult->results[0]～kresults[10]までのダンプです。

(gdb) p *kresult
$6 = {
  nrooms = 65804,
  nitems = 65805,
  debug_nums = 65806,
  debug_usage = 65807,
  errcode = 65808,
  results = 0x7fcfeb35e0c0
}
(gdb) p kresult->results[0]
$7 = 65809
(gdb) p kresult->results[1]
$8 = 65810
(gdb) p kresult->results[2]
$9 = 65811
(gdb) p kresult->results[3]
$10 = 65812
(gdb) p kresult->results[4]
$11 = 65813
(gdb) p kresult->results[5]
$12 = 65814
(gdb) p kresult->results[6]
$13 = 65815
(gdb) p kresult->results[7]
$14 = 65816
(gdb) p kresult->results[8]
$15 = 65817
(gdb) p kresult->results[9]
$16 = 65818
(gdb) p kresult->results[10]
$17 = 65819

[kaigai]

本件の原因は突き止められていませんが、他のメモリ破壊バグ等の修正も加わっていますので、再度、再現を試みていただけないでしょうか？

[kaigai]

tcache_headを登録するハッシュ表のロックに関連する問題を修正後、再現しないので、
一旦クローズとする。