Thread: memory problems in copying large table to STDOUT
Folks, I've been struggling to copy a large table (200 million records, 60GB) to tape using: psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k After processing about 10 million records (this varies), I get: FATAL 1: Memory exhausted in AllocSetAlloc() (The tape drive is a DLT 7000, and the tape is not filled at this point). There is no evidence that the backend has really exhausted avail memory (I have 256MB but 1GB swap and the postgres user and database user both have unlimited memory usage). This is 6.5.1 on Linux 2.2.11 (w/Debian 2.1) on a dual 450Mhz Xeon box with a 128GB software Raid0 array. I've set SHMEM to 128MB am using "-B 12288 -S 8192". I've been trying to figure this out for a few weeks but can't seem to get this table copied to tape. Can one of the developers offer a suggestion? BTW, this is a large astronomical database which will eventually grow to about 500 million records. Besides this tape problem, pgsql is now working nicely for our application. I've been following the mysql thread. You folks may want to add "works with databases over 2GB" to your plus column. With thoughtful indexing, one can retrieve queries of <100000 records in 1 to 15 minutes which competes nicely with our main data server, a bunch of Sun Enterprise 5000 and 6000s running Informix. Of course, many people using this large system simultaneously, but our goal for this project is to recommend an alternative hardware/software solution to the astronomical community for <$10K. --M =========================================================================== Martin Weinberg Phone: (413) 545-3821 Dept. of Physics and Astronomy FAX: (413) 545-2117/0648 530 Graduate Research Tower weinberg@astro.umass.edu University of Massachusetts http://www.astro.umass.edu/~weinberg/ Amherst, MA 01003-4525
Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
> I've been struggling to copy a large table (200 million
> records, 60GB) to tape using:
> psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k
> After processing about 10 million records (this varies), I
> get:
> FATAL 1: Memory exhausted in AllocSetAlloc()
Hmm. What is the exact declaration of the table?
The only explanation I can think of offhand is that the output
conversion function for one of the column types is leaking memory...
copy.c itself looks to be pretty careful not to.
regards, tom lane
Tom Lane wrote on Sat, 09 Oct 1999 11:54:34 EDT >Martin Weinberg <weinberg@osprey.astro.umass.edu> writes: >> I've been struggling to copy a large table (200 million >> records, 60GB) to tape using: >> psql -qc "copy psc to STDOUT;" Winter99 | dd of=/dev/st0 bs=32k >> After processing about 10 million records (this varies), I >> get: >> FATAL 1: Memory exhausted in AllocSetAlloc() > >Hmm. What is the exact declaration of the table? > >The only explanation I can think of offhand is that the output >conversion function for one of the column types is leaking memory... >copy.c itself looks to be pretty careful not to. > The table def is: CREATE TABLE psc (hemis text,date date,scan int2,id int4,ra float4,dec float4,glon float4,glat float4,err_maj float4,err_min float4,err_ang int2,xscan float4,cnf_flag text,j_m float4,h_m float4,k_m float4,j_msig float4,h_msig float4,k_msig float4,j_m_psf float4,h_m_psf float4,k_m_psf float4,j_psfchi float4,h_psfchi float4,k_psfchi float4,j_skyval float4,h_skyval float4,k_skyval float4,j_blend int2,h_blend int2,k_blend int2,j_m_stdap float4,h_m_stdap float4,k_m_stdap float4,j_msig_stdap float4,h_msig_stdap float4,k_msig_stdap float4,j_prob_pers float4,h_prob_pers float4,k_prob_pers float4,j_prg_flg text,h_prg_flg text,k_prg_flg text,j_mrg_flg text,h_mrg_flg text,k_mrg_flg text,j_pix_flg text,h_pix_flg text,k_pix_flg text,j_cal float4,h_cal float4,k_cal float4,gal_contam int2,id_opt text,dist_opt float4,b_m_opt float4,r_m_opt float4,j_h float4,h_k float4,j_k float4,dup_src int2,use_src int2,ext_key_1 int4 ); Thanks for taking a look, --Martin =========================================================================== Martin Weinberg Phone: (413) 545-3821 Dept. of Physics and Astronomy FAX: (413) 545-2117/0648 530 Graduate Research Tower weinberg@astro.umass.edu University of Massachusetts http://www.astro.umass.edu/~weinberg/ Amherst, MA 01003-4525
Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
> Tom Lane wrote on Sat, 09 Oct 1999 11:54:34 EDT
>>> FATAL 1: Memory exhausted in AllocSetAlloc()
>>
>> Hmm. What is the exact declaration of the table?
>>
>> The only explanation I can think of offhand is that the output
>> conversion function for one of the column types is leaking memory...
>> copy.c itself looks to be pretty careful not to.
> The table def is:
> CREATE TABLE psc (
> hemis text,
> date date,
> scan int2,
> id int4,
> ra float4,
> [ lots more fields of these same types ]
Hmm, nothing unusual there. I made up a dummy table containing these
column types, filled it with 16 meg of junk data, and copied in and
out without observing any process memory usage growth at all, under
both current sources and 6.5.2. I also used gdb to set a breakpoint
at AllocSetAlloc, and checked that the inner loop of the copy wasn't
allocating anything it didn't free. So there's no obvious memory
leakage bug here. (It'd be pretty surprising if there was, really,
for such commonly used data types.)
I'm now thinking that there must be either a problem specific to your
platform, or some heretofore unnoticed problem with copying from a
multi-segment (ie, multi-gigabyte) table. I don't have enough disk
space to check the latter theory here...
Can you prepare a debugger backtrace showing what the backend is doing
when it gets the error? If you're not familiar with gdb, it'd go
something like this:
1. Build & install postgres with debugging symbols enabled ("make CUSTOM_COPT=-g all").
2. Start gdb on the postgres executable, eg "gdb /usr/local/pgsql/bin/postgres".
3. Fire up the copy-out operation as usual. (I assume this takes long enough that you have plenty of time for the
nexttwo steps ;-))
4. Use ps or top to find out the process number of the backend handling the session.
5. Attach to that process number in gdb:(gdb) attach NNNN
6. Set a breakpoint at elog, and let the backend continue running:(gdb) break elog(gdb) continue
7. When the breakpoint is hit, get a backtrace:Breakpoint 1, elog ...(gdb) bt After copying & pasting the resulting
printout,you can "quit" to get out of gdb.
regards, tom lane
Tom,
I am attaching the backtrace. This one simultaneously generated
this kernel message from the md driver:
raid0_map bug: hash->zone0==NULL for block 1132810879
Bad md_map in ll_rw_block
Definitely a problem but no longer sure if it's the same one . . .
sigh.
I inserted a pause() in the beginning of elog.c so that I
could attach remotely; I'm keeping the sleeping processing
around in case there's anything else you would like me to
check.
Guess, I'm (foolishly?) pushing the envelope here with a 100GB
database on software raid.
Thanks!!!
--Martin
P.S. After the fact, I realized that my source is Oliver Elphick's
Debian 6.5.1 source package rather than a pure vanilla source.
Hope this is not a problem . . .
----------------------------------------------------------------------
(gdb) bt
#0 0x4012eb77 in pause ()
#1 0x81160e9 in elog (lev=-1, fmt=0x8146a4b "cannot read block %d of %s") at elog.c:81
#2 0x80e76ef in smgrread (which=0, reln=0x822af60, blocknum=2638753, buffer=0x44a85040 "h") at smgr.c:235
#3 0x80dd7a2 in ReadBufferWithBufferLock (reln=0x822af60, blockNum=2638753, bufferLockHeld=0) at bufmgr.c:302
#4 0x80dd682 in ReadBuffer (reln=0x822af60, blockNum=2638753) at bufmgr.c:180
#5 0x80ddf1d in ReleaseAndReadBuffer (buffer=9175, relation=0x822af60, blockNum=2638753) at bufmgr.c:954
#6 0x806ad13 in heapgettup (relation=0x822af60, tuple=0x8235374, dir=1, buffer=0x8235398, snapshot=0x8232af0,
nkeys=0,key=0x0) at heapam.c:469
#7 0x806b6bf in heap_getnext (scandesc=0x8235360, backw=0) at heapam.c:912
#8 0x8084eb3 in CopyTo (rel=0x822af60, binary=0 '\000', oids=0 '\000', fp=0x0, delim=0x813c829 "\t") at copy.c:405
#9 0x8084ce4 in DoCopy (relname=0x82350c0 "psc", binary=0 '\000', oids=0 '\000', from=0 '\000', pipe=1 '\001',
filename=0x0, delim=0x813c829 "\t") at copy.c:323
#10 0x80ea8c6 in ProcessUtility (parsetree=0x82350d8, dest=Remote) at utility.c:227
#11 0x80e8a36 in pg_exec_query_dest ( query_string=0xbfffaef4 "copy psc to STDOUT;", dest=Remote, aclOverride=0) at
postgres.c:727
#12 0x80e8944 in pg_exec_query (query_string=0xbfffaef4 "copy psc to STDOUT;") at postgres.c:656
#13 0x80e9b88 in PostgresMain (argc=11, argv=0xbffff46c, real_argc=12, real_argv=0xbffff984) at postgres.c:1647
#14 0x80d1adc in DoBackend (port=0x81ef748) at postmaster.c:1628
#15 0x80d1613 in BackendStartup (port=0x81ef748) at postmaster.c:1373
#16 0x80d0ca6 in ServerLoop () at postmaster.c:823
#17 0x80d080c in PostmasterMain (argc=12, argv=0xbffff984) at postmaster.c:616
#18 0x80a4597 in main (argc=12, argv=0xbffff984) at main.c:93
Tom Lane wrote on Sat, 09 Oct 1999 14:42:56 EDT
>Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
>> Tom Lane wrote on Sat, 09 Oct 1999 11:54:34 EDT
>>>> FATAL 1: Memory exhausted in AllocSetAlloc()
>>>
>>> Hmm. What is the exact declaration of the table?
>>>
>>> The only explanation I can think of offhand is that the output
>>> conversion function for one of the column types is leaking memory...
>>> copy.c itself looks to be pretty careful not to.
>
>> The table def is:
>
>> CREATE TABLE psc (
>> hemis text,
>> date date,
>> scan int2,
>> id int4,
>> ra float4,
>> [ lots more fields of these same types ]
>
>Hmm, nothing unusual there. I made up a dummy table containing these
>column types, filled it with 16 meg of junk data, and copied in and
>out without observing any process memory usage growth at all, under
>both current sources and 6.5.2. I also used gdb to set a breakpoint
>at AllocSetAlloc, and checked that the inner loop of the copy wasn't
>allocating anything it didn't free. So there's no obvious memory
>leakage bug here. (It'd be pretty surprising if there was, really,
>for such commonly used data types.)
>
>I'm now thinking that there must be either a problem specific to your
>platform, or some heretofore unnoticed problem with copying from a
>multi-segment (ie, multi-gigabyte) table. I don't have enough disk
>space to check the latter theory here...
>
>Can you prepare a debugger backtrace showing what the backend is doing
>when it gets the error? If you're not familiar with gdb, it'd go
>something like this:
>
>1. Build & install postgres with debugging symbols enabled
> ("make CUSTOM_COPT=-g all").
>2. Start gdb on the postgres executable, eg
> "gdb /usr/local/pgsql/bin/postgres".
>3. Fire up the copy-out operation as usual. (I assume this takes long
> enough that you have plenty of time for the next two steps ;-))
>4. Use ps or top to find out the process number of the backend handling
> the session.
>5. Attach to that process number in gdb:
> (gdb) attach NNNN
>6. Set a breakpoint at elog, and let the backend continue running:
> (gdb) break elog
> (gdb) continue
>7. When the breakpoint is hit, get a backtrace:
> Breakpoint 1, elog ...
> (gdb) bt
> After copying & pasting the resulting printout, you can "quit" to
> get out of gdb.
>
> regards, tom lane
>
>************
>
Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
> I am attaching the backtrace. This one simultaneously generated
> this kernel message from the md driver:
> raid0_map bug: hash->zone0==NULL for block 1132810879
> Bad md_map in ll_rw_block
> Definitely a problem but no longer sure if it's the same one . . .
> sigh.
Looks like it is not the same. As you can see, the error message that
elog is about to report is "cannot read <block#> of <file>", which isn't
too surprising given the kernel notice:
> #1 0x81160e9 in elog (lev=-1, fmt=0x8146a4b "cannot read block %d of %s")
> at elog.c:81
If this read failure is reproducible then you will need to get that
taken care of before we can make any progress on the original problem.
But it might be a transient failure --- why don't you just start the
copy over again to see?
regards, tom lane
Hi Tom, I got the backtrace with ""Memory exhausted in AllocSetAlloc()" this time. The process has a virtual image size of 103840 which is consistent with SHMMAX + the text and stack size (in case this fact is of any use) . . . Again, I've saved the process in case checking any symbols would be helpful. --Martin ---------------------------------------------------------------------- (gdb) bt #0 0x4012eb77 in pause () #1 0x81160e9 in elog (lev=1, fmt=0x814f05d "Memory exhausted in AllocSetAlloc()") at elog.c:81 #2 0x811949e in AllocSetAlloc (set=0x8232fb0, size=875628846) at aset.c:273 #3 0x8119a13 in PortalHeapMemoryAlloc (this=0x81efbd8, size=875628846) at portalmem.c:264 #4 0x8119732 in MemoryContextAlloc (context=0x81efbd8, size=875628846) at mcxt.c:230 #5 0x810ebf1 in textout (vlena=0x4106182c) at varlena.c:190 #6 0x808508c in CopyTo (rel=0x822af08, binary=0 '\000', oids=0 '\000', fp=0x0, delim=0x813c829 "\t") at copy.c:421 #7 0x8084ce4 in DoCopy (relname=0x8235068 "psc", binary=0 '\000', oids=0 '\000', from=0 '\000', pipe=1 '\001', filename=0x0, delim=0x813c829 "\t") at copy.c:323 #8 0x80ea8c6 in ProcessUtility (parsetree=0x8235080, dest=Remote) at utility.c:227 #9 0x80e8a36 in pg_exec_query_dest ( query_string=0xbfffb274 "copy psc to STDOUT;", dest=Remote, aclOverride=0) at postgres.c:727 #10 0x80e8944 in pg_exec_query (query_string=0xbfffb274 "copy psc to STDOUT;") at postgres.c:656 #11 0x80e9b88 in PostgresMain (argc=11, argv=0xbffff7ec, real_argc=12, real_argv=0xbffffd04) at postgres.c:1647 #12 0x80d1adc in DoBackend (port=0x81ef748) at postmaster.c:1628 #13 0x80d1613 in BackendStartup (port=0x81ef748) at postmaster.c:1373 #14 0x80d0ca6 in ServerLoop () at postmaster.c:823 #15 0x80d080c in PostmasterMain (argc=12, argv=0xbffffd04) at postmaster.c:616 #16 0x80a4597 in main (argc=12, argv=0xbffffd04) at main.c:93 (gdb) Tom Lane wrote on Sun, 10 Oct 1999 11:59:53 EDT >Martin Weinberg <weinberg@osprey.astro.umass.edu> writes: >> I am attaching the backtrace. This one simultaneously generated >> this kernel message from the md driver: > >> raid0_map bug: hash->zone0==NULL for block 1132810879 >> Bad md_map in ll_rw_block > >> Definitely a problem but no longer sure if it's the same one . . . >> sigh. > >Looks like it is not the same. As you can see, the error message that >elog is about to report is "cannot read <block#> of <file>", which isn't >too surprising given the kernel notice: > >> #1 0x81160e9 in elog (lev=-1, fmt=0x8146a4b "cannot read block %d of %s") >> at elog.c:81 > >If this read failure is reproducible then you will need to get that >taken care of before we can make any progress on the original problem. >But it might be a transient failure --- why don't you just start the >copy over again to see? > > regards, tom lane > >************ >
Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
> I got the backtrace with ""Memory exhausted in
> AllocSetAlloc()" this time.
> #4 0x8119732 in MemoryContextAlloc (context=0x81efbd8, size=875628846)
> at mcxt.c:230
> #5 0x810ebf1 in textout (vlena=0x4106182c) at varlena.c:190
> #6 0x808508c in CopyTo (rel=0x822af08, binary=0 '\000', oids=0 '\000',
> fp=0x0, delim=0x813c829 "\t") at copy.c:421
OK, that shoots down the "memory leak" theory. It sure looks like
what you've got is corrupt data: textout is reading a length word of
875628846 (plus or minus a couple bytes) from what is supposed to be
a text datum. Obviously that's not right. Next question is how
it got that way.
I think it's pretty likely that the original cause is the kernel disk
driver or disk hardware flakiness that we already have evidence for.
However, I hate passing the buck like that, so I'm willing to continue
digging if you are.
> Again, I've saved the process in case checking any symbols
> would be helpful.
You should look at the source tuple location info in CopyTo ---
something like(gdb) f 6 -- frame 6, ie, CopyTo(gdb) p i -- get column number(gdb) p *tuple --
printcontents of HeapTupleData(gdb) p *tuple->t_data -- print contents of HeapTupleHeaderData
The last is mainly to find out the tuple's OID for possible future
reference. What we want right now is the tuple location info,
tuple->t_self, which will give us a block number (bi_hi and bi_lo in
that struct are the high and low 16 bits of the block number). Then,
if you can use dd and od to get a hex dump of that block from the
relation's data files, we can see what's really on disk there.
(Remember that the "blocks" are 8K each; also, if you get an offset
beyond 1 gig, then it's going to be in one of the continuation files
"psc.1", "psc.2", etc --- one gig apiece.)
It would also be useful to look at the contents of the disk block as
sitting in memory in the backend, to see if they are the same as what
you read using dd; I would not be too surprised to find they are not.
The t_data pointer should be pointing into a disk buffer in Postgres'
shared memory block, but offhand I'm not sure what's the easiest way to
discover the starting address of that buffer using gdb. (Can any other
hackers lend a hand here?)
regards, tom lane
Hi Tom,
Tom Lane wrote on Sun, 10 Oct 1999 21:33:00 EDT
>
>I think it's pretty likely that the original cause is the kernel disk
>driver or disk hardware flakiness that we already have evidence for.
>However, I hate passing the buck like that, so I'm willing to continue
>digging if you are.
Honestly, I'm inclined to agree but I'd like to know for sure before
go buy a hardware raid controller (or give up trying to build a
database this large with Linux altogether). The "coincidence" that's
haunting me here is that I used pgsql on a 12GB database of the same
sort with no trouble for about 6 months. All of this started when I
tried to load 60GB. And after loading the table, I index it and
exercise it and everything is fine. Twice now, this problem has
arisen when I've tried to backup the table with a "copy". The first
time, I wiped out the raid array, got the latest kernel with the
up-to-date raid patches and rebuilt (takes a while . . .). Same thing
again. Of course, this copy hits the disks pretty hard, so maybe it's
not so coincidental. Anyway, ruling out a pgsql problem would be
progress.
>> Again, I've saved the process in case checking any symbols
>> would be helpful.
>
>You should look at the source tuple location info in CopyTo ---
>something like
> (gdb) f 6 -- frame 6, ie, CopyTo
> (gdb) p i -- get column number
> (gdb) p *tuple -- print contents of HeapTupleData
> (gdb) p *tuple->t_data -- print contents of HeapTupleHeaderData
>
>The last is mainly to find out the tuple's OID for possible future
>reference. What we want right now is the tuple location info,
>tuple->t_self, which will give us a block number (bi_hi and bi_lo in
>that struct are the high and low 16 bits of the block number). Then,
>if you can use dd and od to get a hex dump of that block from the
>relation's data files, we can see what's really on disk there.
>(Remember that the "blocks" are 8K each; also, if you get an offset
>beyond 1 gig, then it's going to be in one of the continuation files
>"psc.1", "psc.2", etc --- one gig apiece.)
>
Ok done. Here's what I find:
(gdb) p i
$1 = 48
(gdb) p *tuple
$2 = {t_len = 352, t_self = {ip_blkid = {bi_hi = 24, bi_lo = 26279}, ip_posid = 19}, t_data = 0x41061710}
(gdb) p *tuple->t_data
$3 = {t_oid = 37497689, t_cmin = 0, t_cmax = 0, t_xmin = 17943, t_xmax
= 0, t_ctid = {ip_blkid = {bi_hi = 24, bi_lo = 26279}, ip_posid = 19}, t_natts = 63, t_infomask = 2307, t_hoff = 40
'(',t_bits = "<FF><FF><FF><FF>"}
Now, check me to make sure I've followed you correctly:
Since 1GB of blocks is 0x20000, this data in the 13th GB.
The offset into the 13th is 26279.
So I did:
dd if=psc.12 skip=26279 count=1 bs=8k | od -t x > ~/dump.hex
I'm not sure what I'm looking for in dump.hex. The first hand full
of lines are:
0000000 01840064 20002000 02c09ea0 02809d60
0000020 02c09c00 02989ab4 02c09954 02989808
0000040 028096c8 02809588 02c09428 02c092c8
0000060 02c09168 02c09008 02c08ea8 02988d5c
0000100 02c08bfc 02c08a9c 0280895c 02588830
0000120 02c086d0 02c08570 02588444 02c082e4
0000140 02c08184 00000000 00000000 00000000
0000160 00000000 00000000 00000000 00000000
*
0000600 00000000 023c2b5d 00000000 00000000
0000620 00004617 00000000 66a70018 003f0017
0000640 ff280903 ffffffff 000fffff 00000005
0000660 00000073 fffffd95 000000ac 00003d2b
.
.
.
--Martin
===========================================================================
Martin Weinberg Phone: (413) 545-3821
Dept. of Physics and Astronomy FAX: (413) 545-2117/0648
530 Graduate Research Tower weinberg@astro.umass.edu
University of Massachusetts http://www.astro.umass.edu/~weinberg/
Amherst, MA 01003-4525
Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:
> Ok done. Here's what I find:
> (gdb) p i
> $1 = 48
> (gdb) p *tuple
> $2 = {t_len = 352, t_self = {ip_blkid = {bi_hi = 24, bi_lo = 26279},
> ip_posid = 19}, t_data = 0x41061710}
> (gdb) p *tuple->t_data
> $3 = {t_oid = 37497689, t_cmin = 0, t_cmax = 0, t_xmin = 17943, t_xmax
> = 0,
> t_ctid = {ip_blkid = {bi_hi = 24, bi_lo = 26279}, ip_posid = 19},
> t_natts = 63, t_infomask = 2307, t_hoff = 40 '(', t_bits = "<FF><FF><FF><FF>"}
Looks good. For fun you might try "select * from psc where oid = 37497689"
and see if it succeeds or not on a "retail" retrieval of the problem tuple.
> Now, check me to make sure I've followed you correctly:
> Since 1GB of blocks is 0x20000, this data in the 13th GB.
> The offset into the 13th is 26279.
> So I did:
> dd if=psc.12 skip=26279 count=1 bs=8k | od -t x > ~/dump.hex
Looks right to me.
> I'm not sure what I'm looking for in dump.hex.
Could you send the whole dump? I can figure this stuff out by hand but
I'm not sure I can explain it to someone else. (The relevant data
structure declarations are in various files in src/include/storage/ and
src/include/access/ if you want to look for yourself.)
regards, tom lane
Tom Lane wrote on Mon, 11 Oct 1999 10:59:25 EDT > >Looks good. For fun you might try "select * from psc where oid = 37497689" >and see if it succeeds or not on a "retail" retrieval of the problem tuple. Yes . . . the backend dies with status 11. Could this be that I can't do this until "release" the other process since it seems to have gobbled all the shared memory? >Could you send the whole dump? I can figure this stuff out by hand but >I'm not sure I can explain it to someone else. (The relevant data >structure declarations are in various files in src/include/storage/ and >src/include/access/ if you want to look for yourself.) Here it is: 0000000 01840064 20002000 02c09ea0 02809d60 0000020 02c09c00 02989ab4 02c09954 02989808 0000040 028096c8 02809588 02c09428 02c092c8 0000060 02c09168 02c09008 02c08ea8 02988d5c 0000100 02c08bfc 02c08a9c 0280895c 02588830 0000120 02c086d0 02c08570 02588444 02c082e4 0000140 02c08184 00000000 00000000 00000000 0000160 00000000 00000000 00000000 00000000 * 0000600 00000000 023c2b5d 00000000 00000000 0000620 00004617 00000000 66a70018 003f0017 0000640 ff280903 ffffffff 000fffff 00000005 0000660 00000073 fffffd95 000000ac 00003d2b 0000700 4375bc7b c142851c 4024fe3b 41cb436f 0000720 3df5c28f 3df5c28f 0000002d c0e851ec 0000740 0000000a 31313131 00003131 416ec49c 0000760 41676873 41672b02 3cfdf3b6 3d1fbe77 0001000 3da7ef9e 416ec49c 41676873 41672b02 0001020 3fc8f5c3 3f866666 3f91eb85 438015c3 0001040 445407ae 44b6f429 00010001 00000001 0001060 416ecccd 41661893 416476c9 3d810625 0001100 3de147ae 3e48b439 00000000 00000000 0001120 00000000 00000007 00303030 00000007 0001140 00303030 00000007 00303030 0000000a 0001160 30303030 00003030 0000000a 30303030 0001200 00003030 0000000a 30303030 00003030 0001220 00000008 36363030 00000008 36363030 0001240 00000008 36333030 bd2c0831 bd1ba5e3 0001260 bced9168 00000000 00000011 35373055 0001300 36393030 35373237 00000032 3ee147ae 0001320 41873333 417e6666 3eeb851f 3c75c28f 0001340 3ef33333 023c2b5c 00000000 00000000 0001360 00004617 00000000 66a70018 003f0016 0001400 ff280903 ffffffff 000fffff 00000005 0001420 00000073 fffffd95 000000ac 00003d2c 0001440 4375b28f c14283ee 4023590c 41cb80be 0001460 3e851eb8 3e4ccccd 0000000b 43011eb8 0001500 0000000a 31313131 00003131 418226e9 0001520 417d4396 41764dd3 3db43958 3df9db23 0001540 3e3851ec 418226e9 417d4396 41764dd3 0001560 3fb47ae1 3f4ccccd 3f6147ae 437fbae1 0001600 445437ae 44b6e000 00010001 00000001 0001620 418047ae 4181126f 4178ed91 3e49ba5e 0001640 3e8ccccd 3e418937 00000000 00000000 0001660 00000000 00000007 00303030 00000007 0001700 00303030 00000007 00303030 0000000a 0001720 30303030 00003030 0000000a 30303030 0001740 00003030 0000000a 30303030 00003030 0001760 00000008 36323030 00000008 36303030 0002000 00000008 35303130 bd2c0831 bd1ba5e3 0002020 bced9168 00000000 00000011 35373055 0002040 36393030 37343037 00000034 3d8f5c29 0002060 41980000 418d999a 3ee147ae 3edeb852 0002100 3f600000 023c2b5b 00000000 00000000 0002120 00004617 00000000 66a70018 003f0015 0002140 ff280903 edbefbff 000e1fff 00000005 0002160 00000073 fffffd95 000000ac 00003d2e 0002200 4375af05 c1427b74 4022dec2 41cb9919 0002220 3e570a3d 3e428f5c 0000005d 4331c51f 0002240 0000000a 30313031 00003030 41871062 0002260 4181645a 4180f5c3 3e126e98 3e1db22d 0002300 41871062 4181645a 4185624e 3f7851ec 0002320 3fa8f5c3 437fc7ae 445463d7 40d4cccd 0002340 00010001 4188851f 417d1eb8 3e9a1cac 0002360 3e656042 00000000 00000000 00000000 0002400 00000007 00303030 00000007 00303030 0002420 00000007 006c6966 0000000a 30303030 0002440 00003030 0000000a 30303030 00003030 0002460 0000000a 30303030 00003030 00000008 0002500 36303030 00000008 36303030 00000005 0002520 00000030 bd2c0831 bd1ba5e3 bced9168 0002540 00000000 3f358106 3d5d2f1b 3f4353f8 0002560 023c2b5a 00000000 00000000 00004617 0002600 00000000 66a70018 003f0014 ff280903 0002620 ffffffff 000fffff 00000005 00000073 0002640 fffffd95 000000ac 00003d2f 4375c250 0002660 c14279bb 40261fbc 41cb231d 3df5c28f 0002700 3df5c28f 0000005a c2aee148 0000000a 0002720 31313131 00003131 415c6666 4154c083 0002740 41531aa0 3cc49ba6 3ccccccd 3d178d50 0002760 415c6666 4154c083 41531aa0 3f666666 0003000 3f933333 3f7851ec 43802000 4454299a 0003020 44b6bbd7 00010001 00000001 415c7efa 0003040 4154bc6a 41527ae1 3cbc6a7f 3d8d4fdf 0003060 3d7df3b6 00000000 00000000 00000000 0003100 00000007 00303030 00000007 00303030 0003120 00000007 00303030 0000000a 30303030 0003140 00003030 0000000a 30303030 00003030 0003160 0000000a 30303030 00003030 00000008 0003200 36363030 00000008 36363030 00000008 0003220 36363030 bd2c0831 bd1ba5e3 bced9168 0003240 00000000 00000011 35373055 36393030 0003260 30313437 00000037 3f0a3d71 4180cccd 0003300 41700000 3ef4bc6a 3dd2f1aa 3f14bc6a 0003320 023c2b59 00000000 00000000 00004617 0003340 00000000 66a70018 003f0013 ff280903 0003360 ffffffff 000fffff 00000005 00000073 0003400 fffffd95 000000ac 00003d31 4375c8ba 0003420 c1427477 402744d4 41cafd50 3e800000 0003440 3e428f5c 0000004f c32fa3d7 0000000a 0003460 31313131 00003131 41810c4a 417b4bc7 0003500 41769fbe 3d9db22d 3dd70a3d 3e395810 0003520 41810c4a 417b4bc7 41769fbe 3f666666 0003540 3f9c28f6 3f7851ec 437f8000 44541333 0003560 44b6e7ae 00010001 00000001 4180126f 0003600 41783958 41753f7d 3dc8b439 3e25e354 0003620 3e1ba5e3 00000000 00000000 00000000 0003640 00000007 00303030 00000007 00303030 0003660 00000007 00303030 0000000a 30303030 0003700 00003030 0000000a 30303030 00003030 0003720 0000000a 30303030 00003030 00000008 0003740 36313030 00000008 09310931 34310931 0003760 3237382e 2e343109 09393035 342e3431 0004000 00000000 00000011 35373055 36393030 0004020 35353537 00000035 3f4ccccd 4195999a 0004040 418c0000 3ed9999a 3e958106 3f378d50 0004060 023c2b58 00000000 00000000 00004617 0004100 00000000 66a70018 003f0012 ff280903 0004120 edbefbff 000e1fff 00000005 00000073 0004140 fffffd95 000000ac 00003d32 4375abb4 0004160 c1427133 40227432 41cbb0a2 3e570a3d 0004200 3e428f5c 000000a2 435f599a 0000000a 0004220 30313031 00003030 41860c4a 41820c4a 0004240 4174b852 3e116873 3e3851ec 41860c4a 0004260 41820c4a 4177ba5e 3f4f5c29 3fa00000 0004300 43800000 44544b85 40df0a3d 00010001 0004320 41861eb8 41818312 3e395810 3ebbe76d 0004340 00000000 00000000 00000000 00000007 0004360 00303030 00000007 00303030 00000007 0004400 006c6966 0000000a 30303030 00003030 0004420 0000000a 30303030 00003030 0000000a 0004440 30303030 00003030 00000008 36303030 0004460 00000008 36303030 00000005 00000030 0004500 bd2c0831 bd1ba5e3 bced9168 00000000 0004520 3f000000 3f760419 3fbb020c 023c2b57 0004540 00000000 00000000 00004617 00000000 0004560 66a70018 003f0011 ff280903 ffffffff 0004600 000e1fff 00000005 00000073 fffffd95 0004620 000000ac 00003d38 4375b2a2 c14260bd 0004640 4023d6b6 41cb8b2a 3df5c28f 3df5c28f 0004660 00000056 4300147b 0000000a 31313131 0004700 00003131 4177a5e3 416f53f8 4168dd2f 0004720 3d48b439 3d6d9168 3da9fbe7 4177a5e3 0004740 416f53f8 4168dd2f 3f7ae148 3f9851ec 0004760 3f70a3d7 437f547b 44543c29 44b6bd71 0005000 00010001 00000001 4178c49c 416f4fdf 0005020 41678d50 3d810625 3e2f1aa0 3dba5e35 0005040 00000000 00000000 00000000 00000007 0005060 00303030 00000007 00303030 00000007 0005100 00303030 0000000a 30303030 00003030 0005120 0000000a 30303030 00003030 0000000a 0005140 30303030 00003030 00000008 36363030 0005160 00000008 36333030 00000008 36303030 0005200 bd2c0831 bd1ba5e3 bced9168 00000000 0005220 3f051eb8 3eced917 3f6c8b44 023c2b56 0005240 00000000 00000000 00004617 00000000 0005260 66a70018 003f0010 ff280903 ffffffff 0005300 000fffff 00000005 00000073 fffffd95 0005320 000000ac 00003d3b 4375c079 c1425ae2 0005340 40263c43 41cb37f5 3df5c28f 3df5c28f 0005360 0000005a c278a3d7 0000000a 31313131 0005400 00003131 413e0c4a 4133eb85 4131e354 0005420 3cb43958 3cbc6a7f 3cd4fdf4 413e0c4a 0005440 4133eb85 4131e354 3f19999a 3f400000 0005460 3ee66666 4380ab85 445420a4 44b71614 0005500 00010001 00000001 413da9fc 41341062 0005520 41319db2 3c75c28f 3cf5c28f 3c9374bc 0005540 00000000 00000000 00000000 00000007 0005560 00303030 00000007 00303030 00000007 0005600 00303030 0000000a 30303030 00003030 0005620 0000000a 30303030 00003030 0000000a 0005640 30303030 00003030 00000008 35353130 0005660 00000008 36363030 00000008 35353130 0005700 bd2c0831 bd1ba5e3 bced9168 00000000 0005720 00000011 35373055 36393030 36363337 0005740 00000038 3f170a3d 41700000 41566666 0005760 3f220c4a 3e020c4a 3f428f5c 023c2b55 0006000 00000000 00000000 00004617 00000000 0006020 66a70018 003f000f ff280903 ffffffff 0006040 000fffff 00000005 00000073 fffffd95 0006060 000000ac 00003d3e 4375c67b c1425599 0006100 40275009 41cb14aa 3df5c28f 3df5c28f 0006120 0000002d c310c51f 0000000a 31313131 0006140 00003131 41732f1b 41660000 41636042 0006160 3d23d70a 3d178d50 3d89374c 41732f1b 0006200 41660000 41636042 3f8b851f 3f4a3d71 0006220 3f666666 437ff0a4 44541ccd 44b6f148 0006240 00010001 00000001 4172624e 41668b44 0006260 416147ae 3d03126f 3ddd2f1b 3ddf3b64 0006300 00000000 00000000 00000000 00000007 0006320 00303030 00000007 00303030 00000007 0006340 00303030 0000000a 30303030 00003030 0006360 0000000a 30303030 00003030 0000000a 0006400 30303030 00003030 00000008 36363030 0006420 00000008 35353130 00000008 36333030 0006440 bd2c0831 bd1ba5e3 bced9168 00000000 0006460 00000011 35373055 36393030 35303537 0006500 00000030 3faccccd 41973333 4189999a 0006520 3f52f1aa 3e27ef9e 3f7ced91 023c2b54 0006540 00000000 00000000 00004617 00000000 0006560 66a70018 003f000e ff280903 edbefbff 0006600 000fffff 00000005 00000073 fffffd95 0006620 000000ac 00003d45 4375bb2e c142481a 0006640 40259ad4 41cb5e49 3e19999a 3e19999a 0006660 0000002d 412947ae 0000000a 30313031 0006700 00003030 41826666 4179374c 4180872b 0006720 3db851ec 3db22d0e 41826666 4179374c 0006740 41850625 3f95c28f 3f9c28f6 437fb0a4 0006760 44540333 40d33333 00010001 418320c5 0007000 417ce560 3ea2d0e5 3ea8f5c3 00000000 0007020 00000000 00000000 00000007 00303030 0007040 00000007 00303030 00000007 006c6966 0007060 0000000a 30303030 00003030 0000000a 0007100 30303030 00003030 0000000a 30303030 0007120 00003030 00000008 36313030 00000008 0007140 36303030 00000005 00000030 bd2c0831 0007160 bd1ba5e3 bced9168 00000000 00000011 0007200 35373055 36393030 34343237 00000038 0007220 3f3851ec 419a6666 418b3333 3f395810 0007240 befae148 3e6f9db2 023c2b53 00000000 0007260 00000000 00004617 00000000 66a70018 0007300 003f000d ff280903 ffffffff 000fffff 0007320 00000005 00000073 fffffd95 000000ac 0007340 00003d48 4375c3cc c1424254 40272014 0007360 41cb2b20 3df5c28f 3df5c28f 0000002d 0007400 c2d7b852 0000000a 31313131 00003131 0007420 41681893 415f9db2 415d374c 3ced9168 0007440 3d03126f 3d3c6a7f 41681893 415f9db2 0007460 415d374c 3f733333 3fb33333 3f947ae1 0007500 437fae14 4453fb85 44b6f6b8 00010001 0007520 00000001 41674fdf 415f851f 415bced9 0007540 3c03126f 3d9374bc 3ddb22d1 00000000 0007560 00000000 00000000 00000007 00303030 0007600 00000007 00303030 00000007 00303030 0007620 0000000a 30303030 00003030 0000000a 0007640 30303030 00003030 0000000a 30303030 0007660 00003030 00000008 36363030 00000008 0007700 36363030 00000008 35343130 bd2c0831 0007720 bd1ba5e3 bced9168 00000000 00000011 0007740 35373055 36393030 35343437 00000031 0007760 3f6147ae 41873333 417ccccd 3f07ae14 0010000 3e19999a 3f2e147b 023c2b52 00000000 0010020 00000000 00004617 00000000 66a70018 0010040 003f000c ff280903 ffffffff 000fffff 0010060 00000005 00000073 fffffd95 000000ac 0010100 00003d4a 4375ad5e c14240f3 4023636f 0010120 41cbb55a 3df5c28f 3df5c28f 0000005a 0010140 43487ae1 0000000a 31313131 00003131 0010160 41609ba6 4158dd2f 4156353f 3cdd2f1b 0010200 3ce56042 3d23d70a 41609ba6 4158dd2f 0010220 4156353f 3f88f5c3 3f8b851f 3f828f5c 0010240 437fe666 44542852 44b6b5c3 00010001 0010260 00000001 4160a3d7 415778d5 4155c6a8 0010300 3cbc6a7f 3d872b02 3dc08312 00000000 0010320 00000000 00000000 00000007 00303030 0010340 00000007 00303030 00000007 00303030 0010360 0000000a 30303030 00003030 0000000a 0010400 30303030 00003030 0000000a 30303030 0010420 00003030 00000008 36363030 00000008 0010440 36363030 00000008 36363030 bd2c0831 0010460 bd1ba5e3 bced9168 00000000 00000011 0010500 35373055 36393030 38323936 00000036 0010520 3f2b851f 4185999a 41766666 3ef7ced9 0010540 3e29fbe7 3f266666 023c2b51 00000000 0010560 00000000 00004617 00000000 66a70018 0010600 003f000b ff280903 ffffffff 000fffff 0010620 00000005 00000073 fffffd95 000000ac 0010640 00003d4e 4375ab2d c142384d 40232374 0010660 41cbc580 3df5c28f 3df5c28f 0000005a 0010700 4366a148 0000000a 31313131 00003131 0010720 4173126f 416b0625 41666a7f 3d408312 0010740 3d5d2f1b 3da5e354 4173126f 416b0625 0010760 41666a7f 3fae147b 3faa3d71 3f95c28f 0011000 43800148 445438f6 44b6e3d7 00010001 0011020 00000001 41711eb8 4168f1aa 41659db2 0011040 3d591687 3df7ced9 3dba5e35 00000000 0011060 00000000 00000000 00000007 00303030 0011100 00000007 00303030 00000007 00303030 0011120 0000000a 30303030 00003030 0000000a 0011140 30303030 00003030 0000000a 30303030 0011160 00003030 00000008 36363030 00000008 0011200 36353030 00000008 36323030 bd2c0831 0011220 bd1ba5e3 bced9168 00000000 00000011 0011240 35373055 36393030 35373836 00000035 0011260 3f63d70a 418a6666 41833333 3f00c49c 0011300 3e9374bc 3f4a7efa 023c2b50 00000000 0011320 00000000 00004617 00000000 66a70018 0011340 003f000a ff280903 ffffffff 000fffff 0011360 00000005 00000073 fffffd95 000000ac 0011400 00003d4f 4375c0b4 c1423820 4026bf0a 0011420 41cb414c 3df5c28f 3df5c28f 0000005a 0011440 c282a3d7 0000000a 31313131 00003131 0011460 415ba1cb 415378d5 4153126f 3cc49ba6 0011500 3ccccccd 3d1374bc 415ba1cb 415378d5 0011520 4153126f 3f866666 3f570a3d 3f428f5c 0011540 43805c29 445417ae 44b6eeb8 00010001 0011560 00000001 415afdf4 4153f3b6 4154ac08 0011600 3cdd2f1b 3d5d2f1b 3d0b4396 00000000 0011620 00000000 00000000 00000007 00303030 0011640 00000007 00303030 00000007 00303030 0011660 0000000a 30303030 00003030 0000000a 0011700 30303030 00003030 0000000a 30303030 0011720 00003030 00000008 35353130 00000008 0011740 36363030 00000008 36363030 bd2c0831 0011760 bd1ba5e3 bced9168 00000000 00000011 0012000 35373055 36393030 33373337 00000034 0012020 3f88f5c3 417b3333 416ccccd 3f028f5c 0012040 3ccccccd 3f08f5c3 023c2b4f 00000000 0012060 00000000 00004617 00000000 66a70018 0012100 003f0009 ff280903 ffffffff 000fffff 0012120 00000005 00000073 fffffd95 000000ac 0012140 00003d51 4375bd58 c1423676 402634e3 0012160 41cb5674 3e051eb8 3e051eb8 0000002d 0012200 c1993333 0000000a 31313131 00003131 0012220 41780000 41706a7f 4172dd2f 3d48b439 0012240 3d50e560 3e16872b 41780000 41706a7f 0012260 4172dd2f 3f68f5c3 3fc28f5c 3f5c28f6 0012300 437ff0a4 44540a3d 44b70a8f 00010001 0012320 00000001 41770625 41779db2 416dbe77 0012340 3db43958 3ded9168 3df9db23 00000000 0012360 00000000 00000000 00000007 00303030 0012400 00000007 00303030 00000007 00303030 0012420 0000000a 30303030 00003030 0000000a 0012440 30303030 00003030 0000000a 30303030 0012460 00003030 00000008 36353030 00000008 0012500 36303030 00000008 36303030 bd2c0831 0012520 bd1ba5e3 bced9168 00000000 00000011 0012540 35373055 36393030 37393237 00000036 0012560 3f3851ec 418d999a 4184cccd 3ef2b021 0012600 be1cac08 3ea45a1d 023c2b4e 00000000 0012620 00000000 00004617 00000000 66a70018 0012640 003f0008 ff280903 ffffffff 000e1fff 0012660 00000005 00000073 fffffd95 000000ac 0012700 00003d52 4375c128 c1423492 4026dedb 0012720 41cb3f9a 3e8f5c29 3e851eb8 00000051 0012740 c28f23d7 0000000a 31313131 00003131 0012760 4182e76d 417a5604 41796042 3dba5e35 0013000 3dced917 3e560419 4182e76d 417a5604 0013020 41796042 3f9ae148 3f63d70a 3f428f5c 0013040 437fc51f 44542d71 44b6dae1 00010001 0013060 00000001 41839375 4178cccd 417a3d71 0013100 3edcac08 3df1a9fc 3e818937 00000000 0013120 00000000 00000000 00000007 00303030 0013140 00000007 00303030 00000007 00303030 0013160 0000000a 30303030 00003030 0000000a 0013200 30303030 00003030 0000000a 30303030 0013220 00003030 00000008 35313130 00000008 0013240 36303030 00000008 36303030 bd2c0831 0013260 bd1ba5e3 bced9168 00000000 3f378d50 0013300 3d75c28f 3f46e979 023c2b4d 00000000 0013320 00000000 00004617 00000000 66a70018 0013340 003f0007 ff280903 ffffffff 000e1fff 0013360 00000005 00000073 fffffd95 000000ac 0013400 00003d55 4375cc2c c1423065 4028c522 0013420 41cafd30 3df5c28f 3df5c28f 00000056 0013440 c35f028f 0000000a 31313131 00003131 0013460 417ec49c 41735c29 416e5a1d 3d9374bc 0013500 3d9374bc 3dced917 417ec49c 41735c29 0013520 416e5a1d 3f733333 3f75c28f 3f95c28f 0013540 43804148 4453feb8 44b6f0f6 00010001 0013560 00000001 417be354 4172c8b4 4170624e 0013600 3db43958 3e5c28f6 3e841893 00000000 0013620 00000000 00000000 00000007 00303030 0013640 00000007 00303030 00000007 00303030 0013660 0000000a 30303030 00003030 0000000a 0013700 30303030 00003030 0000000a 30303030 0013720 00003030 00000008 36333030 00000008 0013740 36323030 00000008 36303030 bd2c0831 0013760 bd1ba5e3 bced9168 00000000 3f36872b 0014000 3ea04189 3f8353f8 023c2b4c 00000000 0014020 00000000 00004617 00000000 66a70018 0014040 003f0006 ff280903 edbefbff 000fffff 0014060 00000005 00000073 fffffd95 000000ac 0014100 00003d56 4375c913 c1422f27 402844e1 0014120 41cb109b 3e3851ec 3e2e147b 00000078 0014140 c33470a4 0000000a 30313031 00003030 0014160 4183d4fe 418076c9 417cf9db 3dced917 0014200 3e116873 4183d4fe 418076c9 4182020c 0014220 3f99999a 3f7851ec 437f2e14 445410a4 0014240 40d9999a 00010001 4184c28f 4184c8b4 0014260 3e820c4a 3e947ae1 00000000 00000000 0014300 00000000 00000007 00303030 00000007 0014320 00303030 00000007 006c6966 0000000a 0014340 30303030 00003030 0000000a 30303030 0014360 00003030 0000000a 30303030 00003030 0014400 00000008 36313030 00000008 36303030 0014420 00000005 00000030 bd2c0831 bd1ba5e3 0014440 bced9168 00000000 00000011 35373055 0014460 36393030 33363537 00000036 3e8a3d71 0014500 4191999a 418f3333 3ed78d50 3e7ced91 0014520 3f2b020c 023c2b4b 00000000 00000000 0014540 00004617 00000000 66a70018 003f0005 0014560 ff280903 ffffffff 000fffff 00000005 0014600 00000073 fffffd95 000000ac 00003d58 0014620 4375b5f4 c1422d49 4025180d 41cb86b3 0014640 3df5c28f 3df5c28f 0000002d 42a4e666 0014660 0000000a 31313131 00003131 416c28f6 0014700 4164ac08 4164872b 3cf5c28f 3d1374bc 0014720 3d8d4fdf 416c28f6 4164ac08 4164872b 0014740 3f5eb852 3fa00000 3f47ae14 437fcf5c 0014760 44542f5c 44b6fa3d 00010001 00000001 0015000 416cf5c3 41643d71 416251ec 3cf5c28f 0015020 3d79db23 3df5c28f 00000000 00000000 0015040 00000000 00000007 00303030 00000007 0015060 00303030 00000007 00303030 0000000a 0015100 30303030 00003030 0000000a 30303030 0015120 00003030 0000000a 30303030 00003030 0015140 00000008 36363030 00000008 36363030 0015160 00000008 35333130 bd2c0831 bd1ba5e3 0015200 bced9168 00000000 00000011 35373055 0015220 36393030 34323137 00000034 3ef5c28f 0015240 41826666 417b3333 3eef9db2 3c1374bc 0015260 3ef43958 023c2b4a 00000000 00000000 0015300 00004617 00000000 66a70018 003f0004 0015320 ff280903 edbefbff 000fffff 00000005 0015340 00000073 fffffd95 000000ac 00003d5b 0015360 4375c246 c1422b6b 40272e84 41cb3b94 0015400 3e6147ae 3e4ccccd 00000049 c2add1ec 0015420 0000000a 30313031 00003030 418570a4 0015440 41812f1b 417e0419 3df7ced9 3e147ae1 0015460 418570a4 41812f1b 4182999a 3f51eb85 0015500 3f5eb852 438007ae 44540e14 40d051ec 0015520 00010001 41859ba6 41802d0e 3e25e354 0015540 3ec5a1cb 00000000 00000000 00000000 0015560 00000007 00303030 00000007 00303030 0015600 00000007 006c6966 0000000a 30303030 0015620 00003030 0000000a 30303030 00003030 0015640 0000000a 30303030 00003030 00000008 0015660 36303030 00000008 36303030 00000005 0015700 00000030 bd2c0831 bd1ba5e3 bced9168 0015720 00000000 00000011 35373055 36393030 0015740 39303437 00000039 3eb851ec 419b3333 0015760 41926666 3f083127 3e8b4396 3f4dd2f2 0016000 023c2b49 00000000 00000000 00004617 0016020 00000000 66a70018 003f0003 ff280903 0016040 ffffffff 000fffff 00000005 00000073 0016060 fffffd95 000000ac 00003d5f 4375c992 0016100 c14225e5 40287a31 41cb1070 3f028f5c 0016120 3f028f5c 0000005a c33b3852 0000000a 0016140 31313131 00003131 4187147b 41835c29 0016160 4180a3d7 3e189375 3e49ba5e 3e947ae1 0016200 4187147b 41835c29 4180a3d7 3f9ae148 0016220 3f451eb8 3f947ae1 437f75c3 44540ccd 0016240 44b6e948 00010001 00000001 418af5c3 0016260 418022d1 41a50000 3ea9fbe7 3e9a9fbe 0016300 410e353f 00000000 00000000 00000000 0016320 00000007 00303030 00000007 00303030 0016340 00000007 00303030 0000000a 30303030 0016360 00003030 0000000a 30303030 00003030 0016400 0000000a 30303030 00003030 00000008 0016420 36303030 00000008 36303030 00000008 0016440 36303030 bd2c0831 bd1ba5e3 bced9168 0016460 00000000 00000011 35373055 36393030 0016500 34373537 00000039 3f266666 4198cccd 0016520 418f3333 3eee147b 3eae147b 3f4e147b 0016540 023c2b48 00000000 00000000 00004617 0016560 00000000 66a70018 003f0002 ff280903 0016600 ffffffff 000e1fff 00000005 00000073 0016620 fffffd95 000000ac 00003d61 4375b6b0 0016640 c1422463 40255671 41cb84f3 3e6b851f 0016660 3e6147ae 00000047 4290bd71 0000000a 0016700 31313131 00003131 41847ae1 4179d2f2 0016720 4177a9fc 3de147ae 3dc28f5c 3e52f1aa 0016740 41847ae1 4179d2f2 4177a9fc 3f400000 0016760 3f91eb85 3f970a3d 437fbae1 44543852 0017000 44b6e052 00010001 00000001 41839ba6 0017020 41781062 41770625 3e52f1aa 3e818937 0017040 3ed6872b 00000000 00000000 00000000 0017060 00000007 00303030 00000007 00303030 0017100 00000007 00303030 0000000a 30303030 0017120 00003030 0000000a 30303030 00003030 0017140 0000000a 30303030 00003030 00000008 0017160 36303030 00000008 36313030 00000008 0017200 36303030 bd2c0831 bd1ba5e3 bced9168 0017220 00000000 3f722d0e 3e0a3d71 3f8a5e35 0017240 023c2b47 00000000 00000000 00004617 0017260 00000000 66a70018 003f0001 ff280903 0017300 ffffffff 000fffff 00000005 00000073 0017320 fffffd95 000000ac 00003d62 4375b331 0017340 c14221b7 4024c9cd 41cb9b43 3ea8f5c3 0017360 3e75c28f 0000004d 42f0e666 0000000a 0017400 31313131 00003131 4182b22d 417ced91 0017420 417bc28f 3dc8b439 3ddd2f1b 3e4ed917 0017440 4182b22d 417ced91 417bc28f 3f7ae148 0017460 3fa3d70a 3fa28f5c 437fc51f 44542c29 0017500 44b6fd71 00010001 00000001 41808937 0017520 4179f3b6 4173ef9e 3dcccccd 3e4ed917 0017540 3e872b02 00000000 00000000 00000000 0017560 00000007 00303030 00000007 00303030 0017600 00000007 00303030 0000000a 30303030 0017620 00003030 0000000a 30303030 00003030 0017640 0000000a 30303030 00003030 00000008 0017660 36303030 00000008 36313030 00000008 0017700 36303030 bd2c0831 bd1ba5e3 bced9168 0017720 00000000 00000011 35373055 36393030 0017740 32363037 00000035 3e8f5c29 41966666 0017760 418d999a 3f076c8b 3d958106 3f1a1cac 0020000