MIME-Version: 1.0
References: <19482-4cc37cbf52d55235@postgresql.org>
In-Reply-To: <19482-4cc37cbf52d55235@postgresql.org>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Sun, 17 May 2026 20:14:24 +0530
Message-ID: 
 <CAJTYsWX5zQQozsqR-i1JQjDpw=d7mPhafD2qanCo3sH6BguTPA@mail.gmail.com>
Subject: Re: BUG #19482: Recursive QueueFKConstraintValidation() lacks stack
 depth check
To: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Content-Type: multipart/mixed; boundary="0000000000001fadac0652047c5e"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJTYsWX5zQQozsqR-i1JQjDpw%3Dd7mPhafD2qanCo3sH6BguTPA%40mail.gmail.com>
Precedence: bulk

--0000000000001fadac0652047c5e
Content-Type: multipart/alternative; boundary="0000000000001fadab0652047c5c"

--0000000000001fadab0652047c5c
Content-Type: text/plain; charset="UTF-8"

Hi,

On Sun, 17 May 2026 at 18:01, PG Bug reporting form <noreply@postgresql.org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference:      19482
> Logged by:          Alexander Lakhin
> Email address:      exclusion@gmail.com
> PostgreSQL version: 18.4
> Operating system:   Ubuntu 24.04
> Description:
>
> The following script:
> echo "
> CREATE TABLE tp0 (a int, PRIMARY KEY (a)) PARTITION BY RANGE(a);
> ALTER TABLE tp0 ADD CONSTRAINT fk FOREIGN KEY (a) REFERENCES tp0 NOT VALID;
> " | psql
>
> for ((i=1;i<=48000;i++)); do # may take 2-3 hours
>   echo "CREATE TABLE tp$i PARTITION OF tp$(( $i - 1 ))
>          FOR VALUES FROM ($i) TO (1000000) PARTITION BY RANGE (a);";
> done | psql > psql.log
>
> echo "
> ALTER TABLE tp0 VALIDATE CONSTRAINT fk;
> " | psql
>
> leads to:
> 2026-05-16 12:35:43.258 EEST|law|regression|6a083a6f.34aa38|LOG:
> statement:
> ALTER TABLE tp0 VALIDATE CONSTRAINT fk;
> 2026-05-16 12:35:56.104 EEST|||6a07f1d1.32a4c7|LOG:  client backend (PID
> 3451448) was terminated by signal 11: Segmentation fault
> 2026-05-16 12:35:56.104 EEST|||6a07f1d1.32a4c7|DETAIL:  Failed process was
> running: ALTER TABLE tp0 VALIDATE CONSTRAINT fk;
>
> Core was generated by `postgres: law regression 127.0.0.1(48420) ALTER
> TABLE
> '.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x00005e57e8d06ae9 in hash_initial_lookup (hashp=0x5e580f378e10,
> hashvalue=795799848, bucketptr=0x7ffe0c940090) at dynahash.c:1767
> 1767        bucket = calc_bucket(hctl, hashvalue);
> (gdb) (gdb) (gdb) (gdb) #0  0x00005e57e8d06ae9 in hash_initial_lookup
> (hashp=0x5e580f378e10, hashvalue=795799848, bucketptr=0x7ffe0c940090) at
> dynahash.c:1767
> #1  0x00005e57e8d0545c in hash_search_with_hash_value
> (hashp=0x5e580f378e10,
> keyPtr=0x7ffe0c94010c, hashvalue=795799848, action=HASH_FIND, foundPtr=0x0)
>     at dynahash.c:1010
> #2  0x00005e57e8d0538a in hash_search (hashp=0x5e580f378e10,
> keyPtr=0x7ffe0c94010c, action=HASH_FIND, foundPtr=0x0) at dynahash.c:961
> #3  0x00005e57e8a7c224 in GetPrivateRefCountEntry (buffer=125,
> do_move=true)
> at bufmgr.c:381
> #4  0x00005e57e8a8051a in PinBuffer (buf=0x762990250980, strategy=0x0) at
> bufmgr.c:3085
> ...
> #20 0x00005e57e8ce0a15 in CheckNNConstraintFetch (relation=0x762989504168)
> at relcache.c:4619
> #21 0x00005e57e8cd9b66 in RelationBuildTupleDesc (relation=0x762989504168)
> at relcache.c:701
> #22 0x00005e57e8cdaa23 in RelationBuildDesc (targetRelId=464701,
> insertIt=true) at relcache.c:1204
> #23 0x00005e57e8cdc5cb in RelationIdGetRelation (relationId=464701) at
> relcache.c:2142
> #24 0x00005e57e84d14d2 in relation_open (relationId=464701, lockmode=4) at
> relation.c:58
> #25 0x00005e57e85a16c8 in table_open (relationId=464701, lockmode=4) at
> table.c:44
> #26 0x00005e57e877c41b in QueueFKConstraintValidation
> (wqueue=0x7ffe0d13d128, conrel=0x76299e17b6d0, fkrel=0x7629895039e8,
> pkrelid=16385,
>     contuple=0x5e5850492148, lockmode=4) at tablecmds.c:13080
> #27 0x00005e57e877c450 in QueueFKConstraintValidation
> (wqueue=0x7ffe0d13d128, conrel=0x76299e17b6d0, fkrel=0x762989503268,
> pkrelid=16385,
>     contuple=0x5e5850491c98, lockmode=4) at tablecmds.c:13086
> #28 0x00005e57e877c450 in QueueFKConstraintValidation
> (wqueue=0x7ffe0d13d128, conrel=0x76299e17b6d0, fkrel=0x762989502ae8,
> pkrelid=16385,
>     contuple=0x5e58504917e8, lockmode=4) at tablecmds.c:13086
> ...
> #37383 0x00005e57e877c450 in QueueFKConstraintValidation
> (wqueue=0x7ffe0d13d128, conrel=0x76299e17b6d0, fkrel=0x76299dd9b218,
> pkrelid=16385,
>     contuple=0x5e580f357b98, lockmode=4) at tablecmds.c:13086
> #37384 0x00005e57e877c450 in QueueFKConstraintValidation
> (wqueue=0x7ffe0d13d128, conrel=0x76299e17b6d0, fkrel=0x76299dd98358,
> pkrelid=16385,
>     contuple=0x5e580f35d628, lockmode=4) at tablecmds.c:13086
> #37385 0x00005e57e877c025 in ATExecValidateConstraint
> (wqueue=0x7ffe0d13d128, rel=0x76299dd98358, constrName=0x5e580f3554d8 "fk",
> recurse=true,
>     recursing=false, lockmode=4) at tablecmds.c:12966
> #37386 0x00005e57e876acde in ATExecCmd (wqueue=0x7ffe0d13d128,
> tab=0x5e580f354fc8, cmd=0x5e580f355488, lockmode=4, cur_pass=AT_PASS_MISC,
>     context=0x7ffe0d13d320) at tablecmds.c:5497
> #37387 0x00005e57e876a347 in ATRewriteCatalogs (wqueue=0x7ffe0d13d128,
> lockmode=4, context=0x7ffe0d13d320) at tablecmds.c:5334
> #37388 0x00005e57e876968c in ATController (parsetree=0x5e580f32aa88,
> rel=0x76299dd98358, cmds=0x5e580f32aa38, recurse=true, lockmode=4,
> context=0x7ffe0d13d320)
>     at tablecmds.c:4889
> #37389 0x00005e57e876929d in AlterTable (stmt=0x5e580f32aa88, lockmode=4,
> context=0x7ffe0d13d320) at tablecmds.c:4544
> #37390 0x00005e57e8ae8380 in ProcessUtilitySlow (pstate=0x5e580f354470,
> pstmt=0x5e580f32ab38,
>     queryString=0x5e580f329f60 "ALTER TABLE tp0 VALIDATE CONSTRAINT fk;",
> context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0,
> dest=0x5e580f32aef8,
>     qc=0x7ffe0d13d980) at utility.c:1321
>
> Reproduced on REL_18_STABLE, starting from b663b9436, and on master.
>
>
Thanks for the report and the bisected commit.

QueueFKConstraintValidation() recurses through the partition hierarchy
without a stack-depth check, which is the usual reason for SIGSEGV
crashes like the one in your stack trace.  Other recursive helpers in
tablecmds.c (and elsewhere in the backend) call check_stack_depth() at
function entry so that we raise a controlled "stack depth limit
exceeded" error instead.

The attached patch does the same here.  With max_stack_depth reduced
to 100kB, a scaled-down repro (2000 nested partitions) reproduces the
crash on master and produces the following clean error with the patch:

  ALTER TABLE tp0 VALIDATE CONSTRAINT fk;
  ERROR:  stack depth limit exceeded
  HINT:  Increase the configuration parameter "max_stack_depth"
         (currently 100kB), ...

Thoughts?

Regards,
Ayush

--0000000000001fadab0652047c5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, 17 May 2026 =
at 18:01, PG Bug reporting form &lt;<a href=3D"mailto:noreply@postgresql.or=
g" target=3D"_blank">noreply@postgresql.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">The following bug has been logge=
d on the website:<br>
<br>
Bug reference:=C2=A0 =C2=A0 =C2=A0 19482<br>
Logged by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alexander Lakhin<br>
Email address:=C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:exclusion@gmail.com" t=
arget=3D"_blank">exclusion@gmail.com</a><br>
PostgreSQL version: 18.4<br>
Operating system:=C2=A0 =C2=A0Ubuntu 24.04<br>
Description:=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>
<br>
The following script:<br>
echo &quot;<br>
CREATE TABLE tp0 (a int, PRIMARY KEY (a)) PARTITION BY RANGE(a);<br>
ALTER TABLE tp0 ADD CONSTRAINT fk FOREIGN KEY (a) REFERENCES tp0 NOT VALID;=
<br>
&quot; | psql<br>
<br>
for ((i=3D1;i&lt;=3D48000;i++)); do # may take 2-3 hours<br>
=C2=A0 echo &quot;CREATE TABLE tp$i PARTITION OF tp$(( $i - 1 ))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FOR VALUES FROM ($i) TO (1000000) PARTITI=
ON BY RANGE (a);&quot;;<br>
done | psql &gt; psql.log<br>
<br>
echo &quot;<br>
ALTER TABLE tp0 VALIDATE CONSTRAINT fk;<br>
&quot; | psql<br>
<br>
leads to:<br>
2026-05-16 12:35:43.258 EEST|law|regression|6a083a6f.34aa38|LOG:=C2=A0 stat=
ement:<br>
ALTER TABLE tp0 VALIDATE CONSTRAINT fk;<br>
2026-05-16 12:35:56.104 EEST|||6a07f1d1.32a4c7|LOG:=C2=A0 client backend (P=
ID<br>
3451448) was terminated by signal 11: Segmentation fault<br>
2026-05-16 12:35:56.104 EEST|||6a07f1d1.32a4c7|DETAIL:=C2=A0 Failed process=
 was<br>
running: ALTER TABLE tp0 VALIDATE CONSTRAINT fk;<br>
<br>
Core was generated by `postgres: law regression 127.0.0.1(48420) ALTER TABL=
E<br>
&#39;.<br>
Program terminated with signal SIGSEGV, Segmentation fault.<br>
#0=C2=A0 0x00005e57e8d06ae9 in hash_initial_lookup (hashp=3D0x5e580f378e10,=
<br>
hashvalue=3D795799848, bucketptr=3D0x7ffe0c940090) at dynahash.c:1767<br>
1767=C2=A0 =C2=A0 =C2=A0 =C2=A0 bucket =3D calc_bucket(hctl, hashvalue);<br=
>
(gdb) (gdb) (gdb) (gdb) #0=C2=A0 0x00005e57e8d06ae9 in hash_initial_lookup<=
br>
(hashp=3D0x5e580f378e10, hashvalue=3D795799848, bucketptr=3D0x7ffe0c940090)=
 at<br>
dynahash.c:1767<br>
#1=C2=A0 0x00005e57e8d0545c in hash_search_with_hash_value (hashp=3D0x5e580=
f378e10,<br>
keyPtr=3D0x7ffe0c94010c, hashvalue=3D795799848, action=3DHASH_FIND, foundPt=
r=3D0x0)<br>
=C2=A0 =C2=A0 at dynahash.c:1010<br>
#2=C2=A0 0x00005e57e8d0538a in hash_search (hashp=3D0x5e580f378e10,<br>
keyPtr=3D0x7ffe0c94010c, action=3DHASH_FIND, foundPtr=3D0x0) at dynahash.c:=
961<br>
#3=C2=A0 0x00005e57e8a7c224 in GetPrivateRefCountEntry (buffer=3D125, do_mo=
ve=3Dtrue)<br>
at bufmgr.c:381<br>
#4=C2=A0 0x00005e57e8a8051a in PinBuffer (buf=3D0x762990250980, strategy=3D=
0x0) at<br>
bufmgr.c:3085<br>
...<br>
#20 0x00005e57e8ce0a15 in CheckNNConstraintFetch (relation=3D0x762989504168=
)<br>
at relcache.c:4619<br>
#21 0x00005e57e8cd9b66 in RelationBuildTupleDesc (relation=3D0x762989504168=
)<br>
at relcache.c:701<br>
#22 0x00005e57e8cdaa23 in RelationBuildDesc (targetRelId=3D464701,<br>
insertIt=3Dtrue) at relcache.c:1204<br>
#23 0x00005e57e8cdc5cb in RelationIdGetRelation (relationId=3D464701) at<br=
>
relcache.c:2142<br>
#24 0x00005e57e84d14d2 in relation_open (relationId=3D464701, lockmode=3D4)=
 at<br>
relation.c:58<br>
#25 0x00005e57e85a16c8 in table_open (relationId=3D464701, lockmode=3D4) at=
<br>
table.c:44<br>
#26 0x00005e57e877c41b in QueueFKConstraintValidation<br>
(wqueue=3D0x7ffe0d13d128, conrel=3D0x76299e17b6d0, fkrel=3D0x7629895039e8,<=
br>
pkrelid=3D16385,<br>
=C2=A0 =C2=A0 contuple=3D0x5e5850492148, lockmode=3D4) at tablecmds.c:13080=
<br>
#27 0x00005e57e877c450 in QueueFKConstraintValidation<br>
(wqueue=3D0x7ffe0d13d128, conrel=3D0x76299e17b6d0, fkrel=3D0x762989503268,<=
br>
pkrelid=3D16385,<br>
=C2=A0 =C2=A0 contuple=3D0x5e5850491c98, lockmode=3D4) at tablecmds.c:13086=
<br>
#28 0x00005e57e877c450 in QueueFKConstraintValidation<br>
(wqueue=3D0x7ffe0d13d128, conrel=3D0x76299e17b6d0, fkrel=3D0x762989502ae8,<=
br>
pkrelid=3D16385,<br>
=C2=A0 =C2=A0 contuple=3D0x5e58504917e8, lockmode=3D4) at tablecmds.c:13086=
<br>
...<br>
#37383 0x00005e57e877c450 in QueueFKConstraintValidation<br>
(wqueue=3D0x7ffe0d13d128, conrel=3D0x76299e17b6d0, fkrel=3D0x76299dd9b218,<=
br>
pkrelid=3D16385,<br>
=C2=A0 =C2=A0 contuple=3D0x5e580f357b98, lockmode=3D4) at tablecmds.c:13086=
<br>
#37384 0x00005e57e877c450 in QueueFKConstraintValidation<br>
(wqueue=3D0x7ffe0d13d128, conrel=3D0x76299e17b6d0, fkrel=3D0x76299dd98358,<=
br>
pkrelid=3D16385,<br>
=C2=A0 =C2=A0 contuple=3D0x5e580f35d628, lockmode=3D4) at tablecmds.c:13086=
<br>
#37385 0x00005e57e877c025 in ATExecValidateConstraint<br>
(wqueue=3D0x7ffe0d13d128, rel=3D0x76299dd98358, constrName=3D0x5e580f3554d8=
 &quot;fk&quot;,<br>
recurse=3Dtrue,<br>
=C2=A0 =C2=A0 recursing=3Dfalse, lockmode=3D4) at tablecmds.c:12966<br>
#37386 0x00005e57e876acde in ATExecCmd (wqueue=3D0x7ffe0d13d128,<br>
tab=3D0x5e580f354fc8, cmd=3D0x5e580f355488, lockmode=3D4, cur_pass=3DAT_PAS=
S_MISC,<br>
=C2=A0 =C2=A0 context=3D0x7ffe0d13d320) at tablecmds.c:5497<br>
#37387 0x00005e57e876a347 in ATRewriteCatalogs (wqueue=3D0x7ffe0d13d128,<br=
>
lockmode=3D4, context=3D0x7ffe0d13d320) at tablecmds.c:5334<br>
#37388 0x00005e57e876968c in ATController (parsetree=3D0x5e580f32aa88,<br>
rel=3D0x76299dd98358, cmds=3D0x5e580f32aa38, recurse=3Dtrue, lockmode=3D4,<=
br>
context=3D0x7ffe0d13d320)<br>
=C2=A0 =C2=A0 at tablecmds.c:4889<br>
#37389 0x00005e57e876929d in AlterTable (stmt=3D0x5e580f32aa88, lockmode=3D=
4,<br>
context=3D0x7ffe0d13d320) at tablecmds.c:4544<br>
#37390 0x00005e57e8ae8380 in ProcessUtilitySlow (pstate=3D0x5e580f354470,<b=
r>
pstmt=3D0x5e580f32ab38,<br>
=C2=A0 =C2=A0 queryString=3D0x5e580f329f60 &quot;ALTER TABLE tp0 VALIDATE C=
ONSTRAINT fk;&quot;,<br>
context=3DPROCESS_UTILITY_TOPLEVEL, params=3D0x0, queryEnv=3D0x0,<br>
dest=3D0x5e580f32aef8,<br>
=C2=A0 =C2=A0 qc=3D0x7ffe0d13d980) at utility.c:1321<br>
<br>
Reproduced on REL_18_STABLE, starting from b663b9436, and on master.<br><br=
></blockquote><div><br></div>Thanks for the report and the bisected commit.=
<br><br>QueueFKConstraintValidation() recurses through the partition hierar=
chy<br>without a stack-depth check, which is the usual reason for SIGSEGV<b=
r>crashes like the one in your stack trace.=C2=A0 Other recursive helpers i=
n<br>tablecmds.c (and elsewhere in the backend) call check_stack_depth() at=
<br>function entry so that we raise a controlled &quot;stack depth limit<br=
>exceeded&quot; error instead.<br><br>The attached patch does the same here=
.=C2=A0 With max_stack_depth reduced<br>to 100kB, a scaled-down repro (2000=
 nested partitions) reproduces the<br>crash on master and produces the foll=
owing clean error with the patch:<br><br>=C2=A0 ALTER TABLE tp0 VALIDATE CO=
NSTRAINT fk;<br>=C2=A0 ERROR: =C2=A0stack depth limit exceeded<br>=C2=A0 HI=
NT: =C2=A0Increase the configuration parameter &quot;max_stack_depth&quot;<=
br><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(currently 100kB), ...=C2=A0</div=
><div><br></div><div>Thoughts?<br><br>Regards,<br>Ayush</div></div></div>
</div>

--0000000000001fadab0652047c5c--

--0000000000001fadac0652047c5e
Content-Type: application/octet-stream;
	name="v1-0001-Add-stack-depth-check-to-QueueFKConstraintValidat.patch"
Content-Disposition: attachment;
	filename="v1-0001-Add-stack-depth-check-to-QueueFKConstraintValidat.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mp9vx3on0>
X-Attachment-Id: f_mp9vx3on0

RnJvbSA5OTg2MWMzYTMwNGRiYTlkOGI5YzFmMWYyZmMwMWI0ZjAzNjBkYTU1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBeXVzaCBUaXdhcmkgPGF5dXNodGl3YXJpLnNsZzAxQGdtYWls
LmNvbT4KRGF0ZTogU3VuLCAxNyBNYXkgMjAyNiAxNDoxODoyNyArMDAwMApTdWJqZWN0OiBbUEFU
Q0ggdjFdIEFkZCBzdGFjayBkZXB0aCBjaGVjayB0byBRdWV1ZUZLQ29uc3RyYWludFZhbGlkYXRp
b24oKQoKUXVldWVGS0NvbnN0cmFpbnRWYWxpZGF0aW9uKCkgcmVjdXJzZXMgdGhyb3VnaCB0aGUg
cGFydGl0aW9uIGhpZXJhcmNoeQp0byBxdWV1ZSBjaGlsZCBjb25zdHJhaW50IHZhbGlkYXRpb25z
IGFuZCB0byBtYXJrIGNoaWxkIHJvd3MgYXMKdmFsaWRhdGVkLiAgT24gYSBzdWZmaWNpZW50bHkg
ZGVlcCBwYXJ0aXRpb24gdHJlZSAodGhlIHJlcG9ydCB1c2VzCnJvdWdobHkgNDgwMDAgbmVzdGVk
IGxldmVscyksIHRoZSByZWN1cnNpb24gZXhoYXVzdHMgdGhlIHByb2Nlc3MKc3RhY2sgYW5kIHRo
ZSBiYWNrZW5kIGNyYXNoZXMgd2l0aCBTSUdTRUdWIGZyb20gZGVlcCBpbnNpZGUgdGhlCmNhdGFs
b2cgYWNjZXNzIHBhdGguCgpPdGhlciByZWN1cnNpdmUgaGVscGVycyBpbiB0YWJsZWNtZHMuYyAo
YW5kIGVsc2V3aGVyZSBpbiB0aGUgYmFja2VuZCkKZm9sbG93IHRoZSBjb252ZW50aW9uIG9mIGNh
bGxpbmcgY2hlY2tfc3RhY2tfZGVwdGgoKSBhdCBmdW5jdGlvbgplbnRyeSBzbyB0aGF0IHRoZSBw
cm9jZXNzIHJhaXNlcyBhIGNvbnRyb2xsZWQgInN0YWNrIGRlcHRoIGxpbWl0CmV4Y2VlZGVkIiBl
cnJvciB3ZWxsIGJlZm9yZSB3ZSBydW4gb3V0IG9mIHN0YWNrLiAgRG8gdGhlIHNhbWUgaGVyZS4K
ClJlcG9ydGVkLWJ5OiBBbGV4YW5kZXIgTGFraGluIDxleGNsdXNpb25AZ21haWwuY29tPgpEaXNj
dXNzaW9uOiBodHRwczovL3Bvc3Rnci5lcy9tLzE5NDgyLTRjYzM3Y2JmNTJkNTUyMzVAcG9zdGdy
ZXNxbC5vcmcKLS0tCiBzcmMvYmFja2VuZC9jb21tYW5kcy90YWJsZWNtZHMuYyB8IDYgKysrKysr
CiAxIGZpbGUgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tl
bmQvY29tbWFuZHMvdGFibGVjbWRzLmMgYi9zcmMvYmFja2VuZC9jb21tYW5kcy90YWJsZWNtZHMu
YwppbmRleCA5MmIwZjM4YzM1My4uYjE1YjMxOThjZTEgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5k
L2NvbW1hbmRzL3RhYmxlY21kcy5jCisrKyBiL3NyYy9iYWNrZW5kL2NvbW1hbmRzL3RhYmxlY21k
cy5jCkBAIC0xMzI3NSw2ICsxMzI3NSwxMiBAQCBRdWV1ZUZLQ29uc3RyYWludFZhbGlkYXRpb24o
TGlzdCAqKndxdWV1ZSwgUmVsYXRpb24gY29ucmVsLCBSZWxhdGlvbiBma3JlbCwKIAlIZWFwVHVw
bGUJY29weVR1cGxlOwogCUZvcm1fcGdfY29uc3RyYWludCBjb3B5X2NvbjsKIAorCS8qCisJICog
VGhpcyBmdW5jdGlvbiByZWN1cnNlcyB0aHJvdWdoIHRoZSBwYXJ0aXRpb24gaGllcmFyY2h5LCBz
byBndWFyZAorCSAqIGFnYWluc3Qgc3RhY2sgb3ZlcmZsb3cgb24gdmVyeSBkZWVwbHkgbmVzdGVk
IHBhcnRpdGlvbiB0cmVlcy4KKwkgKi8KKwljaGVja19zdGFja19kZXB0aCgpOworCiAJY29uID0g
KEZvcm1fcGdfY29uc3RyYWludCkgR0VUU1RSVUNUKGNvbnR1cGxlKTsKIAlBc3NlcnQoY29uLT5j
b250eXBlID09IENPTlNUUkFJTlRfRk9SRUlHTik7CiAJQXNzZXJ0KCFjb24tPmNvbnZhbGlkYXRl
ZCk7Ci0tIAoyLjQzLjAKCg==
--0000000000001fadac0652047c5e--