MIME-Version: 1.0
From: Glauber Batista <glauberrbatista@gmail.com>
Date: Tue, 9 Jun 2026 15:37:24 -0300
Message-ID: 
 <CAO+_mTQgQyTYwDh=U8iTnsDmOGyWsZJjUV31SmEYwmw6_xY6Bw@mail.gmail.com>
Subject: Autoprewarm workers terminated due to a segmentation fault
To: pgsql-bugs@lists.postgresql.org
Content-Type: multipart/mixed; boundary="000000000000c49c330653d66b33"
Archived-At: 
 <https://www.postgresql.org/message-id/CAO%2B_mTQgQyTYwDh%3DU8iTnsDmOGyWsZJjUV31SmEYwmw6_xY6Bw%40mail.gmail.com>
Precedence: bulk

--000000000000c49c330653d66b33
Content-Type: multipart/alternative; boundary="000000000000c49c320653d66b31"

--000000000000c49c320653d66b31
Content-Type: text/plain; charset="UTF-8"

Hello,

I have an issue with the autoprewarm workers segfaulting during the service
restart. Sometimes, it successfully restarts after a few tries, but usually
I need to remove the autoprewarm.blocks file. My setup consists of a
primary server with two replicas and all of them present the same issue. I
have been using this setup for several years with no issues, but since I
upgraded to Postgres 18 I'm having it. This is a production database.

Details:

Postgres Version: PostgreSQL 18.3 on aarch64-unknown-linux-gnu, compiled by
gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, 64-bit

This is the related settings I'm using in postgresql.conf
```
shared_preload_libraries = 'pg_stat_statements,pg_prewarm'
pg_prewarm.autoprewarm = True
pg_prewarm.autoprewarm_interval = 300s
```

I'm using systemd to manage Postgres, but it also happens if I start
postgres using `pg_ctl`. So I ruled out a systemd issue.

This is the error message I'm seeing.
```
LOG:  restored log file "000000010000079200000015" from archive
LOG:  consistent recovery state reached at 792/15A586C8
LOG:  database system is ready to accept read-only connections
LOG:  restored log file "000000010000079200000016" from archive
LOG:  restored log file "000000010000079200000017" from archive
LOG:  background worker "autoprewarm worker" (PID 2350) was terminated by
signal 11: Segmentation fault
LOG:  terminating any other active server processes
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted while in recovery at log time
2026-06-09 17:34:19 UTC
HINT:  If this has occurred more than once some data might be corrupted and
you might need to choose an earlier recovery target.
LOG:  restored log file "00000001000007920000000D" from archive
LOG:  restored log file "0000000100000791000000F8" from archive
LOG:  entering standby mode
LOG:  redo starts at 791/F804CB38
LOG:  database system is ready to accept read-only connections
LOG:  restored log file "0000000100000791000000F9" from archive
LOG:  restored log file "0000000100000791000000FA" from archive
LOG:  restored log file "0000000100000791000000FB" from archive
LOG:  background worker "autoprewarm worker" (PID 2522) was terminated by
signal 11: Segmentation fault
LOG:  terminating any other active server processes
FATAL:  could not restore file "0000000100000791000000FC" from archive:
child process was terminated by signal 3: Quit
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted while in recovery at log time
2026-06-09 17:34:19 UTC
HINT:  If this has occurred more than once some data might be corrupted and
you might need to choose an earlier recovery target.
LOG:  restored log file "00000001000007920000000D" from archive
LOG:  restored log file "0000000100000791000000F8" from archive
LOG:  entering standby mode
```
Changing the debug level to DEBUG1 didn't show anything useful, so I'm not
pasting it here.

At first, I thought it could be somehow related to this bug:
https://www.datadoghq.com/blog/engineering/unraveling-a-postgres-segfault/,
but investigating a bit it does not seem to be the case. Either way, I
compiled Postgres again using CFLAGS="-O0 -g -fno-strict-aliasing" to check
if it was something related to the code optimization for ARM64, but the
issue persisted.

Then, I used gdb to get the core file. Since it has been quite some time
since I didn't debug anything written in C/C++, I used Claude to guide me.
Here's some info:
```
(gdb) frame 0
#0  0x0000f5a0c6003854 in autoprewarm_database_main (main_arg=0) at
autoprewarm.c:649
649                blk = block_info[i];
(gdb) list
644
645                read_stream_end(stream);
646
647                /* Advance i past all the blocks just prewarmed. */
648                i = p.pos;
649                blk = block_info[i];
650            }
651
652            relation_close(rel, AccessShareLock);
653            CommitTransactionCommand();
(gdb) p *block_info
$1 = {database = 0, tablespace = 0, filenumber = 0, forknum = MAIN_FORKNUM,
blocknum = 0}
(gdb) p p
$2 = {block_info = 0xf5a07f600000, pos = 131072, tablespace = 1663,
filenumber = 28197, forknum = MAIN_FORKNUM, nblocks = 65329}
(gdb) p stream
$3 = (ReadStream *) 0xb82a946671f0
(gdb) p *(ReadStream *) stream
$4 = {max_ios = 0, io_combine_limit = 0, ios_in_progress = 0, queue_size =
0, max_pinned_buffers = 225, forwarded_buffers = 0, pinned_buffers = 0,
distance = 1,
  initialized_buffers = 9, read_buffers_flags = 0, sync_mode = false,
batch_mode = true, advice_enabled = false, temporary = false,
buffered_blocknum = 4294967295,
  callback = 0xf5a0c600330c <apw_read_stream_next_block>,
callback_private_data = 0xfffff758cea8, seq_blocknum = 2403,
seq_until_processed = 4294967295,
  pending_read_blocknum = 2403, pending_read_nblocks = 0,
per_buffer_data_size = 0, per_buffer_data = 0x0, ios = 0xb82a94667618,
oldest_io_index = 8, next_io_index = 8,
  fast_path = false, oldest_buffer_index = 9, next_buffer_index = 9,
buffers = 0xb82a94667254}
(gdb) p p.pos
$5 = 131072
(gdb) p p.nblocks
$6 = 65329
(gdb) p apw_state->prewarm_stop_idx
$7 = 0
(gdb) p apw_state->prewarm_start_idx
$8 = 0
(gdb) p block_info[131072]
Cannot access memory at address 0xf5a07f880000
(gdb) p &block_info[131072]
$9 = (BlockInfoRecord *) 0xf5a07f880000
(gdb) p block_info[131071]
$10 = {database = 0, tablespace = 0, filenumber = 0, forknum =
MAIN_FORKNUM, blocknum = 0}
(gdb) p block_info[131070]
$11 = {database = 0, tablespace = 0, filenumber = 0, forknum =
MAIN_FORKNUM, blocknum = 0}
(gdb) p block_info[1]
$12 = {database = 0, tablespace = 0, filenumber = 0, forknum =
MAIN_FORKNUM, blocknum = 0}
(gdb) p apw_state->prewarmed_blocks
$13 = 0
(gdb) p *apw_state
$14 = {lock = {tranche = 0, state = {value = 0}, waiters = {head = 0, tail
= 0}}, bgworker_pid = 0, pid_using_dumpfile = 0, block_info_handle = 0,
database = 0,
  prewarm_start_idx = 0, prewarm_stop_idx = 0, prewarmed_blocks = 0}
(gdb) info line autoprewarm.c:649
Line 649 of "autoprewarm.c" starts at address 0xf5a0c600382c
<autoprewarm_database_main+936> and ends at 0xf5a0c600384c
<autoprewarm_database_main+968>.
(gdb) list autoprewarm.c:640,660
640                {
641                    apw_state->prewarmed_blocks++;
642                    ReleaseBuffer(buf);
643                }
644
645                read_stream_end(stream);
646
647                /* Advance i past all the blocks just prewarmed. */
648                i = p.pos;
649                blk = block_info[i];
650            }
651
652            relation_close(rel, AccessShareLock);
653            CommitTransactionCommand();
654        }
655
656        dsm_detach(seg);
657    }
658
659    /*
660     * Dump information on blocks in shared buffers.  We use a text
format here
```

I found out that some parts of the autoprewarm were re-written recently
here:
https://www.postgresql.org/message-id/flat/CAN55FZ3n8Gd%2BhajbL%3D5UkGzu_aHGRqnn%2BxktXq2fuds%3D1AOR6Q%40mail.gmail.com
and I think it could be related, given the data present in the dump.

Also, I inspected my data to ensure it was not the culprit. I got the
database and filenumber from `bt full` and run the following queries.
```
blk = {database = 23583, tablespace = 1663, filenumber = 28197, forknum =
MAIN_FORKNUM, blocknum = 49}
```
So I queried the database (23583) and the filenumber (28197) using
```
SELECT datname FROM pg_database WHERE oid = 23583;
\c <datname>
SELECT relname, relkind, relpages, pg_relation_filenode(oid) AS filenode
FROM pg_class
WHERE pg_relation_filenode(oid) = 28197;
```
and it returned
```
   relname    | relkind | relpages | filenode
--------------+---------+----------+----------
 lccss_cc_idx | i       |    64805 |    28197
```
So I think it's not stale data or shrunk relation caused by VACUUM,
TRUNCATE, etc.

I'm only reporting with the latest data I collected, but this issue has
been happening since April, when I upgraded the database.

All that said, it seems there's a missing guard-clause at line 649. I
didn't spend much time reading the code, but it's clearly accessing a
position in the array that is not allocated.

Let me know if any extra information is needed.


Best,
Glauber Cassiano Batista

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

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hello,<br><br>I have an issue with t=
he autoprewarm workers segfaulting during the service restart. Sometimes, i=
t successfully restarts after a few tries, but usually I need to remove the=
 autoprewarm.blocks file. My setup consists of a primary server with two re=
plicas and all of them present the same issue. I have been using this setup=
 for several years with no issues, but since I upgraded to Postgres 18 I=
9;m having it. This is a production database.<br><br>Details:<br><br>Postgr=
es Version: PostgreSQL 18.3 on aarch64-unknown-linux-gnu, compiled by gcc (=
Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, 64-bit<br><br>This is the related s=
ettings I&#39;m using in postgresql.conf<br>```<br>shared_preload_libraries=
 =3D &#39;pg_stat_statements,pg_prewarm&#39;<br>pg_prewarm.autoprewarm =3D =
True<br>pg_prewarm.autoprewarm_interval =3D 300s<br>```<br><br>I&#39;m usin=
g systemd to manage Postgres, but it also happens if I start postgres using=
 `pg_ctl`. So I ruled out a systemd issue.</div><div><br>This is the error =
message I&#39;m seeing.<br>```<br>LOG: =C2=A0restored log file &quot;000000=
010000079200000015&quot; from archive<br>LOG: =C2=A0consistent recovery sta=
te reached at 792/15A586C8<br>LOG: =C2=A0database system is ready to accept=
 read-only connections<br>LOG: =C2=A0restored log file &quot;00000001000007=
9200000016&quot; from archive<br>LOG: =C2=A0restored log file &quot;0000000=
10000079200000017&quot; from archive<br>LOG: =C2=A0background worker &quot;=
autoprewarm worker&quot; (PID 2350) was terminated by signal 11: Segmentati=
on fault<br>LOG: =C2=A0terminating any other active server processes<br>LOG=
: =C2=A0all server processes terminated; reinitializing<br>LOG: =C2=A0datab=
ase system was interrupted while in recovery at log time 2026-06-09 17:34:1=
9 UTC<br>HINT: =C2=A0If this has occurred more than once some data might be=
 corrupted and you might need to choose an earlier recovery target.<br>LOG:=
 =C2=A0restored log file &quot;00000001000007920000000D&quot; from archive<=
br>LOG: =C2=A0restored log file &quot;0000000100000791000000F8&quot; from a=
rchive<br>LOG: =C2=A0entering standby mode<br>LOG: =C2=A0redo starts at 791=
/F804CB38<br>LOG: =C2=A0database system is ready to accept read-only connec=
tions<br>LOG: =C2=A0restored log file &quot;0000000100000791000000F9&quot; =
from archive<br>LOG: =C2=A0restored log file &quot;0000000100000791000000FA=
&quot; from archive<br>LOG: =C2=A0restored log file &quot;00000001000007910=
00000FB&quot; from archive<br>LOG: =C2=A0background worker &quot;autoprewar=
m worker&quot; (PID 2522) was terminated by signal 11: Segmentation fault<b=
r>LOG: =C2=A0terminating any other active server processes<br>FATAL: =C2=A0=
could not restore file &quot;0000000100000791000000FC&quot; from archive: c=
hild process was terminated by signal 3: Quit<br>LOG: =C2=A0all server proc=
esses terminated; reinitializing<br>LOG: =C2=A0database system was interrup=
ted while in recovery at log time 2026-06-09 17:34:19 UTC<br>HINT: =C2=A0If=
 this has occurred more than once some data might be corrupted and you migh=
t need to choose an earlier recovery target.<br>LOG: =C2=A0restored log fil=
e &quot;00000001000007920000000D&quot; from archive<br>LOG: =C2=A0restored =
log file &quot;0000000100000791000000F8&quot; from archive<br>LOG: =C2=A0en=
tering standby mode<br>```</div><div>Changing the debug level to DEBUG1 did=
n&#39;t show anything useful, so I&#39;m not pasting it here.</div><div><br=
>At first, I thought it could be somehow related to this bug: <a href=3D"ht=
tps://www.datadoghq.com/blog/engineering/unraveling-a-postgres-segfault/" t=
arget=3D"_blank">https://www.datadoghq.com/blog/engineering/unraveling-a-po=
stgres-segfault/</a>, but investigating a bit it does not seem to be the ca=
se. Either way, I compiled Postgres again using CFLAGS=3D&quot;-O0 -g -fno-=
strict-aliasing&quot; to check if it was something related to the code opti=
mization for ARM64, but the issue persisted.</div><div><br></div><div>Then,=
 I used gdb to get the core file. Since it has been quite some time since I=
 didn&#39;t debug anything written in C/C++, I used Claude to guide me. Her=
e&#39;s some info:<br>```<br>(gdb) frame 0<br>#0 =C2=A00x0000f5a0c6003854 i=
n autoprewarm_database_main (main_arg=3D0) at autoprewarm.c:649<br>649 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0blk =3D block_info[i];<=
br>(gdb) list<br>644<br>645 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0read_stream_end(stream);<br>646<br>647 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Advance i past all the blocks just prewar=
med. */<br>648 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i =3D=
 p.pos;<br>649 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0blk =
=3D block_info[i];<br>650 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>651=
<br>652 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relation_close(rel, Access=
ShareLock);<br>653 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CommitTransacti=
onCommand();<br>(gdb) p *block_info<br>$1 =3D {database =3D 0, tablespace =
=3D 0, filenumber =3D 0, forknum =3D MAIN_FORKNUM, blocknum =3D 0}<br>(gdb)=
 p p<br>$2 =3D {block_info =3D 0xf5a07f600000, pos =3D 131072, tablespace =
=3D 1663, filenumber =3D 28197, forknum =3D MAIN_FORKNUM, nblocks =3D 65329=
}<br>(gdb) p stream<br>$3 =3D (ReadStream *) 0xb82a946671f0<br>(gdb) p *(Re=
adStream *) stream<br>$4 =3D {max_ios =3D 0, io_combine_limit =3D 0, ios_in=
_progress =3D 0, queue_size =3D 0, max_pinned_buffers =3D 225, forwarded_bu=
ffers =3D 0, pinned_buffers =3D 0, distance =3D 1,<br>=C2=A0 initialized_bu=
ffers =3D 9, read_buffers_flags =3D 0, sync_mode =3D false, batch_mode =3D =
true, advice_enabled =3D false, temporary =3D false, buffered_blocknum =3D =
4294967295,<br>=C2=A0 callback =3D 0xf5a0c600330c &lt;apw_read_stream_next_=
block&gt;, callback_private_data =3D 0xfffff758cea8, seq_blocknum =3D 2403,=
 seq_until_processed =3D 4294967295,<br>=C2=A0 pending_read_blocknum =3D 24=
03, pending_read_nblocks =3D 0, per_buffer_data_size =3D 0, per_buffer_data=
 =3D 0x0, ios =3D 0xb82a94667618, oldest_io_index =3D 8, next_io_index =3D =
8,<br>=C2=A0 fast_path =3D false, oldest_buffer_index =3D 9, next_buffer_in=
dex =3D 9, buffers =3D 0xb82a94667254}<br>(gdb) p p.pos<br>$5 =3D 131072<br=
>(gdb) p p.nblocks<br>$6 =3D 65329<br>(gdb) p apw_state-&gt;prewarm_stop_id=
x<br>$7 =3D 0<br>(gdb) p apw_state-&gt;prewarm_start_idx<br>$8 =3D 0<br>(gd=
b) p block_info[131072]<br>Cannot access memory at address 0xf5a07f880000<b=
r>(gdb) p &amp;block_info[131072]<br>$9 =3D (BlockInfoRecord *) 0xf5a07f880=
000<br>(gdb) p block_info[131071]<br>$10 =3D {database =3D 0, tablespace =
=3D 0, filenumber =3D 0, forknum =3D MAIN_FORKNUM, blocknum =3D 0}<br>(gdb)=
 p block_info[131070]<br>$11 =3D {database =3D 0, tablespace =3D 0, filenum=
ber =3D 0, forknum =3D MAIN_FORKNUM, blocknum =3D 0}<br>(gdb) p block_info[=
1]<br>$12 =3D {database =3D 0, tablespace =3D 0, filenumber =3D 0, forknum =
=3D MAIN_FORKNUM, blocknum =3D 0}<br>(gdb) p apw_state-&gt;prewarmed_blocks=
<br>$13 =3D 0<br>(gdb) p *apw_state<br>$14 =3D {lock =3D {tranche =3D 0, st=
ate =3D {value =3D 0}, waiters =3D {head =3D 0, tail =3D 0}}, bgworker_pid =
=3D 0, pid_using_dumpfile =3D 0, block_info_handle =3D 0, database =3D 0,<b=
r>=C2=A0 prewarm_start_idx =3D 0, prewarm_stop_idx =3D 0, prewarmed_blocks =
=3D 0}<br>(gdb) info line autoprewarm.c:649<br>Line 649 of &quot;autoprewar=
m.c&quot; starts at address 0xf5a0c600382c &lt;autoprewarm_database_main+93=
6&gt; and ends at 0xf5a0c600384c &lt;autoprewarm_database_main+968&gt;.<br>=
(gdb) list autoprewarm.c:640,660<br>640 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0{<br>641 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0apw_state-&gt;prewarmed_blocks++;<br>642 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ReleaseBuffer(bu=
f);<br>643 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>644<=
br>645 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0read_stream_e=
nd(stream);<br>646<br>647 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0/* Advance i past all the blocks just prewarmed. */<br>648 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i =3D p.pos;<br>649 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0blk =3D block_info[i];<br>650 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>651<br>652 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0relation_close(rel, AccessShareLock);<br>653 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CommitTransactionCommand();<br>654 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0}<br>655<br>656 =C2=A0 =C2=A0 =C2=A0 =C2=A0dsm_deta=
ch(seg);<br>657 =C2=A0 =C2=A0}<br>658<br>659 =C2=A0 =C2=A0/*<br>660 =C2=A0 =
=C2=A0 * Dump information on blocks in shared buffers.=C2=A0 We use a text =
format here<br>```<br><br>I found out that some parts of the autoprewarm we=
re re-written recently here: <a href=3D"https://www.postgresql.org/message-=
id/flat/CAN55FZ3n8Gd%2BhajbL%3D5UkGzu_aHGRqnn%2BxktXq2fuds%3D1AOR6Q%40mail.=
gmail.com" target=3D"_blank">https://www.postgresql.org/message-id/flat/CAN=
55FZ3n8Gd%2BhajbL%3D5UkGzu_aHGRqnn%2BxktXq2fuds%3D1AOR6Q%40mail.gmail.com</=
a> and I think it could be related, given the data present in the dump.<br>=
<br>Also, I inspected my data to ensure it was not the culprit. I got the d=
atabase and filenumber from `bt full` and run the following queries.<br>```=
<br>blk =3D {database =3D 23583, tablespace =3D 1663, filenumber =3D 28197,=
 forknum =3D MAIN_FORKNUM, blocknum =3D 49}<br>```<br>So I queried the data=
base (23583) and the filenumber (28197) using<br>```<br>SELECT datname FROM=
 pg_database WHERE oid =3D 23583;<br>\c &lt;datname&gt;<br>SELECT relname, =
relkind, relpages, pg_relation_filenode(oid) AS filenode<br>FROM pg_class<b=
r>WHERE pg_relation_filenode(oid) =3D 28197;<br>```<br>and it returned<br>`=
``<br>=C2=A0 =C2=A0relname =C2=A0 =C2=A0| relkind | relpages | filenode<br>=
--------------+---------+----------+----------<br>=C2=A0lccss_cc_idx | i =
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A064805 | =C2=A0 =C2=A028197<br>```<br>So=
 I think it&#39;s not stale data or shrunk relation caused by VACUUM, TRUNC=
ATE, etc.</div><div><br></div><div>I&#39;m only reporting with the latest d=
ata I collected, but this issue has been happening since April, when I upgr=
aded the database.</div><div><br></div><div>All that said, it seems there&#=
39;s a missing guard-clause at line 649. I didn&#39;t spend much time readi=
ng the code, but it&#39;s clearly accessing a position in the array that is=
 not allocated.</div><div><br></div><div>Let me know if any extra informati=
on is needed.</div><div><br></div><div><div dir=3D"ltr" class=3D"gmail_sign=
ature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><br></div><=
div>Best,</div><div>Glauber Cassiano Batista<br></div></div></div></div></d=
iv>
</div>

--000000000000c49c320653d66b31--

--000000000000c49c330653d66b33
Content-Type: text/plain; charset="US-ASCII"; name="bt_full.txt"
Content-Disposition: attachment; filename="bt_full.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_mq6ykiro0>
X-Attachment-Id: f_mq6ykiro0

IzAgIDB4MDAwMGY1YTBjNjAwMzg1NCBpbiBhdXRvcHJld2FybV9kYXRhYmFzZV9tYWluIChtYWlu
X2FyZz0wKSBhdCBhdXRvcHJld2FybS5jOjY0OQogICAgICAgIHN0cmVhbSA9IDB4YjgyYTk0NjY3
MWYwCiAgICAgICAgYnVmID0gMAogICAgICAgIGZvcmtudW0gPSBNQUlOX0ZPUktOVU0KICAgICAg
ICBuYmxvY2tzID0gNjUzMjkKICAgICAgICBwID0ge2Jsb2NrX2luZm8gPSAweGY1YTA3ZjYwMDAw
MCwgcG9zID0gMTMxMDcyLCB0YWJsZXNwYWNlID0gMTY2MywgZmlsZW51bWJlciA9IDI4MTk3LCBm
b3JrbnVtID0gTUFJTl9GT1JLTlVNLCBuYmxvY2tzID0gNjUzMjl9CiAgICAgICAgdGFibGVzcGFj
ZSA9IDE2NjMKICAgICAgICBmaWxlbnVtYmVyID0gMjgxOTcKICAgICAgICByZWxvaWQgPSAyODE5
NwogICAgICAgIHJlbCA9IDB4ZjVhMDdmMTlmNDQ4CiAgICAgICAgYmxvY2tfaW5mbyA9IDB4ZjVh
MDdmNjAwMDAwCiAgICAgICAgaSA9IDEzMTA3MgogICAgICAgIGJsayA9IHtkYXRhYmFzZSA9IDIz
NTgzLCB0YWJsZXNwYWNlID0gMTY2MywgZmlsZW51bWJlciA9IDI4MTk3LCBmb3JrbnVtID0gTUFJ
Tl9GT1JLTlVNLCBibG9ja251bSA9IDQ5fQogICAgICAgIHNlZyA9IDB4YjgyYTk0NWI2NjA4CiAg
ICAgICAgX19mdW5jX18gPSAiYXV0b3ByZXdhcm1fZGF0YWJhc2VfbWFpbiIKIzEgIDB4MDAwMGI4
MmE5MTBmNmEwMCBpbiBCYWNrZ3JvdW5kV29ya2VyTWFpbiAoc3RhcnR1cF9kYXRhPTB4YjgyYTk0
NWU5YTQwLCBzdGFydHVwX2RhdGFfbGVuPTE0NzIpIGF0IGJnd29ya2VyLmM6ODQzCiAgICAgICAg
bG9jYWxfc2lnam1wX2J1ZiA9IHt7X19qbXBidWYgPSB7MjAyNDkzMDE3Mzc5MTIwLCAzLCAyMDI0
OTI5NjkwNzAwMjQsIDIwMjQ5Mjk2MDUxMTQwNCwgMjgxNDc0ODMxNTM4ODI0LCAyNzAwNzA5MTg3
ODU4ODAsIDAsIDI3MDA3MDkxODc4NzA3MiwgMjAyNDkyOTY5MDcwMDI0LCAwLAogICAgICAgICAg
ICAgIDI4MTQ3NDgzMTUzNjE5MiwgMTQ3NDgwNzU4ODQ4MTc1NjY3NzMsIDIwMjQ5Mjk2NTYyNjQ3
MiwgMTQ3NDgxNTMyMTQxMzE2Mjg5NzMsIDAsIDAsIDAsIDAsIDAsIDAsIDAsIDB9LCBfX21hc2tf
d2FzX3NhdmVkID0gMSwgX19zYXZlZF9tYXNrID0ge19fdmFsID0gewogICAgICAgICAgICAgICAg
MTg0NDY3NDQwNjYxOTI5NjQwOTksIDI4MTQ3NDgzMTUzNjEyOCwgMjcwMDcwOTAzOTgzODI4LCAy
ODE0NzQ4MzE1MzYxNjAsIDI4MTQ3NDgzMTUzNjE5MiwgMjgxNDc0ODMxNTM2MTkyLCAyODE0NzQ4
MzE1MzYxNzYsIDQyOTQ5NjcyODgsCiAgICAgICAgICAgICAgICA3Nzk5NDcyMzE1MjU3MTUzNTM2
LCAyODE0NzQ4MzE1MzYxOTIsIDIwMjQ5Mjk2NTE0OTE2NCwgMjAyNDkzMDE3Mzc5MTIwLCAzLCAy
ODE0NzQ4MzE1MzYxOTIsIDIwMjQ5Mjk2NTE0OTE0MCwgMjgxNDc0ODMxNTM2MTkyfX19fQogICAg
ICAgIHdvcmtlciA9IDB4YjgyYTk0NWVkMjM4CiAgICAgICAgZW50cnlwdCA9IDB4ZjVhMGM2MDAz
NDg0IDxhdXRvcHJld2FybV9kYXRhYmFzZV9tYWluPgogICAgICAgIF9fZnVuY19fID0gIkJhY2tn
cm91bmRXb3JrZXJNYWluIgojMiAgMHgwMDAwYjgyYTkxMGZiMDI0IGluIHBvc3RtYXN0ZXJfY2hp
bGRfbGF1bmNoIChjaGlsZF90eXBlPUJfQkdfV09SS0VSLCBjaGlsZF9zbG90PTEwMzksIHN0YXJ0
dXBfZGF0YT0weGI4MmE5NDVlOWE0MCwgc3RhcnR1cF9kYXRhX2xlbj0xNDcyLCBjbGllbnRfc29j
az0weDApCiAgICBhdCBsYXVuY2hfYmFja2VuZC5jOjI5MAogICAgICAgIHBpZCA9IDAKIzMgIDB4
MDAwMGI4MmE5MTEwMzFhMCBpbiBTdGFydEJhY2tncm91bmRXb3JrZXIgKHJ3PTB4YjgyYTk0NWU5
YTQwKSBhdCBwb3N0bWFzdGVyLmM6NDE1NwogICAgICAgIGJuID0gMHhiODJhOTQ1YzA4MDAKICAg
ICAgICB3b3JrZXJfcGlkID0gNjU1MzUKICAgICAgICBfX2Z1bmNfXyA9ICJTdGFydEJhY2tncm91
bmRXb3JrZXIiCiM0ICAweDAwMDBiODJhOTExMDM0OTAgaW4gbWF5YmVfc3RhcnRfYmd3b3JrZXJz
ICgpIGF0IHBvc3RtYXN0ZXIuYzo0MzIzCiAgICAgICAgcncgPSAweGI4MmE5NDVlOWE0MAogICAg
ICAgIG51bV9sYXVuY2hlZCA9IDAKICAgICAgICBub3cgPSAwCiAgICAgICAgaXRlciA9IHtjdXIg
PSAweGI4MmE5NDVlYTAxOCwgbmV4dCA9IDB4YjgyYTk0NTYwMGEwLCBlbmQgPSAweGI4MmE5MTgw
NGRlOCA8QmFja2dyb3VuZFdvcmtlckxpc3Q+fQojNSAgMHgwMDAwYjgyYTkxMTAxY2Y0IGluIExh
dW5jaE1pc3NpbmdCYWNrZ3JvdW5kUHJvY2Vzc2VzICgpIGF0IHBvc3RtYXN0ZXIuYzozMzk3Ck5v
IGxvY2Fscy4KIzYgIDB4MDAwMGI4MmE5MTBmZjMwOCBpbiBTZXJ2ZXJMb29wICgpIGF0IHBvc3Rt
YXN0ZXIuYzoxNzE3CiAgICAgICAgbm93ID0gMTc4MTAyNzkxOQogICAgICAgIGxhc3RfbG9ja2Zp
bGVfcmVjaGVja190aW1lID0gMTc4MTAyNzg4MgogICAgICAgIGxhc3RfdG91Y2hfdGltZSA9IDE3
ODEwMjczODEKICAgICAgICBldmVudHMgPSB7e3BvcyA9IDAsIGV2ZW50cyA9IDEsIGZkID0gLTEs
IHVzZXJfZGF0YSA9IDB4MH0sIHtwb3MgPSAwLCBldmVudHMgPSAwLCBmZCA9IC0zMiwgdXNlcl9k
YXRhID0gMHgwfSwge3BvcyA9IC05MzQ4NDc4MzYsIGV2ZW50cyA9IDYyODgwLCBmZCA9IC0xNDUx
NzM5MDQsCiAgICAgICAgICAgIHVzZXJfZGF0YSA9IDB4ZjVhMGM4NDc2N2RjIDxfX0dJX19fbGli
Y19tYWxsb2MrNTQwPn0sIHtwb3MgPSAtOTMzNjkxMzkyLCBldmVudHMgPSA2Mjg4MCwgZmQgPSAz
MTIsIHVzZXJfZGF0YSA9IDB4ODAzMH0sIHtwb3MgPSAtOTIwMDIxMTUyLCBldmVudHMgPSA2Mjg4
MCwKICAgICAgICAgICAgZmQgPSAtOTMzNjY2ODE2LCB1c2VyX2RhdGEgPSAweGY1YTBjOTI5OTg5
OH0sIHtwb3MgPSAwLCBldmVudHMgPSAwLCBmZCA9IC05MTk3NTI3MDQsIHVzZXJfZGF0YSA9IDB4
YjgyYTkxN2RhZGM4fSwge3BvcyA9IDAsIGV2ZW50cyA9IDAsIGZkID0gLTE0NTE3MTg2NCwKICAg
ICAgICAgICAgdXNlcl9kYXRhID0gMHg2MTY0MmY2NzcwMmYyMjIwfSwge3BvcyA9IC0xNDUxNzM4
NTYsIGV2ZW50cyA9IDY1NTM1LCBmZCA9IDEzODIzNzc0NzIsIHVzZXJfZGF0YSA9IDB4ZmZmZmY3
NThkMmUwfSwge3BvcyA9IC05MzQ4NDI0NzIsIGV2ZW50cyA9IDYyODgwLAogICAgICAgICAgICBm
ZCA9IC0xODA1ODgzMDg4LCB1c2VyX2RhdGEgPSAweGY1YTBjOTI5OTc2MH0sIHtwb3MgPSAtMTQ1
MTczNzkyLCBldmVudHMgPSA2NTUzNSwgZmQgPSAtOTM0ODQyNDcyLCB1c2VyX2RhdGEgPSAweGZm
ZmZmNzU4ZDJlMH0sIHtwb3MgPSAtOTM0ODQyNDcyLAogICAgICAgICAgICBldmVudHMgPSA2Mjg4
MCwgZmQgPSAtMTgwNTg4MzA4OCwgdXNlcl9kYXRhID0gMHhmNWEwYzkyOTk3NjB9LCB7cG9zID0g
LTkzMzY2NTA0MCwgZXZlbnRzID0gNjI4ODAsIGZkID0gMjU2LCB1c2VyX2RhdGEgPSAweGZmZmZm
NzU4ZDMyMH0sIHtwb3MgPSAtOTM0Njg4MDI0LAogICAgICAgICAgICBldmVudHMgPSA2Mjg4MCwg
ZmQgPSAxMCwgdXNlcl9kYXRhID0gMHgzfSwge3BvcyA9IC0xODU0MDM0NDg4LCBldmVudHMgPSA0
NzE0NiwgZmQgPSAtMTg2MjU5MzEwOCwgdXNlcl9kYXRhID0gMHhmZmZmZjc1OGRhODh9LCB7cG9z
ID0gLTkzNDY4NzI3NiwKICAgICAgICAgICAgZXZlbnRzID0gNjI4ODAsIGZkID0gLTE0NTE3MzY5
NiwgdXNlcl9kYXRhID0gMHhiODJhOTExYWVmNTggPEZyZWVEZXNjKzEyND59LCB7cG9zID0gLTE0
NTE3MzY5NiwgZXZlbnRzID0gNjU1MzUsIGZkID0gLTE4NjA1MDU3NjgsIHVzZXJfZGF0YSA9IDB4
ZmZmZmY3NThkMzcwfSwgewogICAgICAgICAgICBwb3MgPSAtMTg2MDUwNDI3MiwgZXZlbnRzID0g
NDcxNDYsIGZkID0gLTE0NTE3MzY2NCwgdXNlcl9kYXRhID0gMHhiODJhOTQ1NjBkMjB9LCB7cG9z
ID0gLTE0NTE3MjUxMiwgZXZlbnRzID0gNjU1MzUsIGZkID0gLTE4NjA1MDIxMzIsCiAgICAgICAg
ICAgIHVzZXJfZGF0YSA9IDB4ZmZmZmY3NThkMzgwfSwge3BvcyA9IC05MzQ4NDg2NTIsIGV2ZW50
cyA9IDYyODgwLCBmZCA9IC0xNDUxNzM1MjAsIHVzZXJfZGF0YSA9IDB4ZjVhMGM4NDc2N2RjIDxf
X0dJX19fbGliY19tYWxsb2MrNTQwPn0sIHtwb3MgPSAtOTMzNjkxMzkyLAogICAgICAgICAgICBl
dmVudHMgPSA2Mjg4MCwgZmQgPSAzMTIsIHVzZXJfZGF0YSA9IDB4MTAwMH0sIHtwb3MgPSAtOTIw
MDIxMTUyLCBldmVudHMgPSA2Mjg4MCwgZmQgPSAtOTMzNjY2ODE2LCB1c2VyX2RhdGEgPSAweGY1
YTBjOTI5OTg5OH0sIHtwb3MgPSAwLCBldmVudHMgPSAwLCBmZCA9IDEsCiAgICAgICAgICAgIHVz
ZXJfZGF0YSA9IDB4MH0sIHtwb3MgPSAwLCBldmVudHMgPSAwLCBmZCA9IC0xNDUxNzM0MjQsIHVz
ZXJfZGF0YSA9IDB4ZjVhMGM4NDc2N2RjIDxfX0dJX19fbGliY19tYWxsb2MrNTQwPn0sIHtwb3Mg
PSAtMTQ1MTczNDA4LCBldmVudHMgPSA2NTUzNSwKICAgICAgICAgICAgZmQgPSAtOTM0ODQ0NDUy
LCB1c2VyX2RhdGEgPSAweGY1YTBjODU5MDAwMCA8Y3VycmVudF9ydG1pbj59LCB7cG9zID0gMzEy
LCBldmVudHMgPSAwLCBmZCA9IDIwNDgsIHVzZXJfZGF0YSA9IDB4ZjVhMGM5Mjk5NzYwfSwge3Bv
cyA9IC05MzM2NjY4MTYsIGV2ZW50cyA9IDMsCiAgICAgICAgICAgIGZkID0gNywgdXNlcl9kYXRh
ID0gMHhiODJhOTQ1YzkxNzB9LCB7cG9zID0gLTE4MDU4NzI3NDQsIGV2ZW50cyA9IDQ3MTQ2LCBm
ZCA9IC0xODU0MDM0NDg4LCB1c2VyX2RhdGEgPSAweDI4fSwge3BvcyA9IC0xNDUxNzMzNDQsIGV2
ZW50cyA9IDY1NTM1LAogICAgICAgICAgICBmZCA9IC0xODU3ODA4MzI4LCB1c2VyX2RhdGEgPSAw
eGZmZmZmNzU4ZDRhMH0sIHtwb3MgPSAtMTg1NzgwODYwNCwgZXZlbnRzID0gNywgZmQgPSAxMDI0
LCB1c2VyX2RhdGEgPSAweDQwMH0sIHtwb3MgPSAtMTQ1MTczMzYwLCBldmVudHMgPSA2NTUzNSwK
ICAgICAgICAgICAgZmQgPSAtOTM0ODU5NTQ0LCB1c2VyX2RhdGEgPSAweGZmZmZmNzU4ZDRjMH0s
IHtwb3MgPSAtOTM0ODU0MjI4LCBldmVudHMgPSA2Mjg4MCwgZmQgPSAtMTgwNTg4MzA4OCwgdXNl
cl9kYXRhID0gMHhmNWEwYzg1OTBhNTAgPG1haW5fYXJlbmE+fSwge3BvcyA9IDIwNjQsCiAgICAg
ICAgICAgIGV2ZW50cyA9IDAsIGZkID0gLTE4MDU4ODEwMjQsIHVzZXJfZGF0YSA9IDB4ZmZmZmY3
NThkNTAwfSwge3BvcyA9IC05MzQ4NDI0NzIsIGV2ZW50cyA9IDYyODgwLCBmZCA9IC0xODA1ODgz
MDg4LCB1c2VyX2RhdGEgPSAweGY1YTBjOTI5OTc2MH0sIHtwb3MgPSAtOTMzNjY1MDQwLAogICAg
ICAgICAgICBldmVudHMgPSA2Mjg4MCwgZmQgPSAyNTYsIHVzZXJfZGF0YSA9IDB4MH0sIHtwb3Mg
PSAtOTM0OTUwMTQ0LCBldmVudHMgPSA2Mjg4MCwgZmQgPSAtMTQ1MTcyOTI4LCB1c2VyX2RhdGEg
PSAweGY1YTBjODRhMWQwMCA8X19saWJjX2ZvcmsrNDMyPn0sIHtwb3MgPSAwLAogICAgICAgICAg
ICBldmVudHMgPSAwLCBmZCA9IDMsIHVzZXJfZGF0YSA9IDB4ZmZmZmY3NThkNjYwfSwge3BvcyA9
IC05MzQ2NjcwMDgsIGV2ZW50cyA9IDYyODgwLCBmZCA9IDEsIHVzZXJfZGF0YSA9IDB4M30sIHtw
b3MgPSAtOTIwMDIxMTUyLCBldmVudHMgPSA2Mjg4MCwgZmQgPSAwLAogICAgICAgICAgICB1c2Vy
X2RhdGEgPSAweGZmZmZmNzU4ZGE4OH0sIHtwb3MgPSAtOTE5NzUzODk2LCBldmVudHMgPSA2Mjg4
MCwgZmQgPSAwLCB1c2VyX2RhdGEgPSAweGY1YTBjOTJkYjAwMCA8X3J0bGRfZ2xvYmFsPn0sIHtw
b3MgPSAtMTQ1MTcyODk2LCBldmVudHMgPSA2NTUzNSwKICAgICAgICAgICAgZmQgPSAtOTM0NjY3
MzYwLCB1c2VyX2RhdGEgPSAweGI4MmE5NDVjNWFiMH0sIHtwb3MgPSAwLCBldmVudHMgPSAwLCBm
ZCA9IDg4LCB1c2VyX2RhdGEgPSAweGI4MmE5NDVjNWI2MH0sIHtwb3MgPSAtMTQ1MTczMDcyLCBl
dmVudHMgPSA2NTUzNSwgZmQgPSAtOTM0ODU5NTQ0LAogICAgICAgICAgICB1c2VyX2RhdGEgPSAw
eGZmZmZmNzU4ZDVlMH0sIHtwb3MgPSAtOTM0ODU0MjI4LCBldmVudHMgPSA2Mjg4MCwgZmQgPSAt
MTgwNTg3NjkxMiwgdXNlcl9kYXRhID0gMHhmNWEwYzg1OTBhNTAgPG1haW5fYXJlbmE+fSwge3Bv
cyA9IDQxMTIsIGV2ZW50cyA9IDAsCiAgICAgICAgICAgIGZkID0gLTE4MDU4NzI4MDAsIHVzZXJf
ZGF0YSA9IDB4ZmZmZmY3NThkNjQwfSwge3BvcyA9IC05MzQ5Mzg4NjQsIGV2ZW50cyA9IDYyODgw
LCBmZCA9IDAsIHVzZXJfZGF0YSA9IDB4ZjVhMGM4NTkyMDAwIDxpbml0aWFsKzQxNj59LCB7cG9z
ID0gLTE0NTE3Mjg5NiwKICAgICAgICAgICAgZXZlbnRzID0gNjU1MzUsIGZkID0gLTkzNDkzODg2
NCwgdXNlcl9kYXRhID0gMHgwfSwge3BvcyA9IC05MzM2ODMyMDAsIGV2ZW50cyA9IDYyODgwLCBm
ZCA9IC05MjAwMjMwMDgsIHVzZXJfZGF0YSA9IDB4YjgyYTkwZmIxNWFjIDxtYWluPn0sIHtwb3Mg
PSAwLAogICAgICAgICAgICBldmVudHMgPSAwLCBmZCA9IC05MzQ5NDUxNTIsIHVzZXJfZGF0YSA9
IDB4MH0sIHtwb3MgPSAwLCBldmVudHMgPSA0NzE0NiwgZmQgPSAwLCB1c2VyX2RhdGEgPSAweDZj
M2Q0YWJmNTI2NTY4MDB9LCB7cG9zID0gLTE0NTE3MjYyNCwgZXZlbnRzID0gNjU1MzUsCiAgICAg
ICAgICAgIGZkID0gLTE4NjEyNDM4NzIsIHVzZXJfZGF0YSA9IDB4ZmZmZmY3NThkYTY4fSwge3Bv
cyA9IDMsIGV2ZW50cyA9IDAsIGZkID0gLTE4NTQwMzQ0ODgsIHVzZXJfZGF0YSA9IDB4YjgyYTkw
ZmIxNWFjIDxtYWluPn0sIHtwb3MgPSAtMTQ1MTcxODMyLCBldmVudHMgPSA2NTUzNSwKICAgICAg
ICAgICAgZmQgPSAxMzgyMzc3NDcyLCB1c2VyX2RhdGEgPSAweGZmZmZmNzU4ZDZiMH0sIHtwb3Mg
PSAtOTM1MjExNjg0LCBldmVudHMgPSA2Mjg4MCwgZmQgPSAtMTQ1MTcyNjI0LCB1c2VyX2RhdGEg
PSAweGI4MmE5MTBmYWNlOCA8Zm9ya19wcm9jZXNzKzI2OD59LCB7CiAgICAgICAgICAgIHBvcyA9
IC0xNDUxNzI3MjAsIGV2ZW50cyA9IDY1NTM1LCBmZCA9IDQxOTQzMDQsIHVzZXJfZGF0YSA9IDB4
ZmZmZmY3NThkYTY4fSwge3BvcyA9IC0xODA2NDY5MjAwLCBldmVudHMgPSA0NzE0NiwgZmQgPSAt
MTgwNjQ2OTAwMCwgdXNlcl9kYXRhID0gMHg0MDAwMDB9LCB7CiAgICAgICAgICAgIHBvcyA9IDEw
MjQsIGV2ZW50cyA9IDAsIGZkID0gLTE4MDY0NjkyMDAsIHVzZXJfZGF0YSA9IDB4YjgyYTkxODM2
ZmU4IDxjb250ZXh0X2ZyZWVsaXN0cysxNj59LCB7cG9zID0gMTksIGV2ZW50cyA9IDEzLCBmZCA9
IC0xNDUxNzI2ODgsCiAgICAgICAgICAgIHVzZXJfZGF0YSA9IDB4YjgyYTkxNDA3YmU0IDxlcnJz
dGFydCsyNjQ+fSwge3BvcyA9IDEwMjQsIGV2ZW50cyA9IDAsIGZkID0gMTksIHVzZXJfZGF0YSA9
IDB4ZmZmZmY3NThkNzUwfSwge3BvcyA9IC0xODU4MDQ0OTU2LCBldmVudHMgPSA0NzE0NiwgZmQg
PSAwLAogICAgICAgICAgICB1c2VyX2RhdGEgPSAweGQ5NDVjMTFiMH0sIHtwb3MgPSAtMTQ1MTcy
NjA4LCBldmVudHMgPSA2NTUzNSwgZmQgPSAtMTg2MTIzNDYwNCwgdXNlcl9kYXRhID0gMHgwfSwg
e3BvcyA9IDEzODIzNzc0NzIsIGV2ZW50cyA9IDE4MTU5NTYxNTksIGZkID0gLTE0NTE3MjYwOCwK
ICAgICAgICAgICAgdXNlcl9kYXRhID0gMHhiODJhOTEwZmFlZGMgPHBvc3RtYXN0ZXJfY2hpbGRf
bGF1bmNoKzcyPn0sIHtwb3MgPSAtMTQ1MTcyNTQ0LCBldmVudHMgPSA2NTUzNSwgZmQgPSAtMTg2
MTIxMDgyOCwgdXNlcl9kYXRhID0gMHgwfSwge3BvcyA9IDAsIGV2ZW50cyA9IDAsIGZkID0gMCwK
ICAgICAgICAgICAgdXNlcl9kYXRhID0gMHgyMDAwMDA0NDJ9LCB7cG9zID0gLTE0NTE3MjMwNCwg
ZXZlbnRzID0gNjU1MzUsIGZkID0gLTE4NjEyMjc4OTIsIHVzZXJfZGF0YSA9IDB4ZmZmZjAwMDAw
MDAwfX0KICAgICAgICBuZXZlbnRzID0gMQogICAgICAgIF9fZnVuY19fID0gIlNlcnZlckxvb3Ai
CiM3ICAweDAwMDBiODJhOTEwZmVhOTAgaW4gUG9zdG1hc3Rlck1haW4gKGFyZ2M9MywgYXJndj0w
eGI4MmE5NDUxOTViMCkgYXQgcG9zdG1hc3Rlci5jOjE0MDAKICAgICAgICBvcHQgPSAtMQogICAg
ICAgIHN0YXR1cyA9IDAKICAgICAgICB1c2VyRG9wdGlvbiA9IDB4YjgyYTk0NTVlNGQwICIvcGcv
ZGF0YSIKICAgICAgICBsaXN0ZW5fYWRkcl9zYXZlZCA9IHRydWUKICAgICAgICBvdXRwdXRfY29u
ZmlnX3ZhcmlhYmxlID0gMHgwCiAgICAgICAgX19mdW5jX18gPSAiUG9zdG1hc3Rlck1haW4iCiM4
ICAweDAwMDBiODJhOTBmYjE5NzAgaW4gbWFpbiAoYXJnYz0zLCBhcmd2PTB4YjgyYTk0NTE5NWIw
KSBhdCBtYWluLmM6MjI3CiAgICAgICAgZG9fY2hlY2tfcm9vdCA9IHRydWUKICAgICAgICBkaXNw
YXRjaF9vcHRpb24gPSBESVNQQVRDSF9QT1NUTUFTVEVSCg==
--000000000000c49c330653d66b33--