Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rAco5-007S3t-MB for pgsql-odbc@arkaria.postgresql.org; Tue, 05 Dec 2023 21:18:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rAco4-006GjD-BH for pgsql-odbc@arkaria.postgresql.org; Tue, 05 Dec 2023 21:18:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rAco4-006Gj5-1Z for pgsql-odbc@lists.postgresql.org; Tue, 05 Dec 2023 21:18:16 +0000 Received: from pgintl.fastcrypt.com ([149.56.129.164]) by magus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rAcnw-00AHVd-BP for pgsql-odbc@postgresql.org; Tue, 05 Dec 2023 21:18:15 +0000 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by pgintl.fastcrypt.com (Postfix) with ESMTPSA id B4AFD20053 for ; Tue, 5 Dec 2023 16:18:06 -0500 (EST) Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a1c7b20f895so12508366b.2 for ; Tue, 05 Dec 2023 13:18:06 -0800 (PST) X-Gm-Message-State: AOJu0Yxosz0BQcQiFGjwNLH0iNIrIdVIZqNwzcYzN8M3Iuqt7mKJSVXe g/vI/6sewy9rtZfRzq73MsoJztDffKqb4FcrAOE= X-Google-Smtp-Source: AGHT+IFybiRlNZcRPOTYL1xjfu2v7oMkjtcoa7Hw4eHUU1/Roqt9/eTnhnvHVUR0Y6OI+JxhaOVHP/3WwLhZ0x5dbhU= X-Received: by 2002:a17:906:4a58:b0:a1c:e980:3c3 with SMTP id a24-20020a1709064a5800b00a1ce98003c3mr830356ejv.28.1701811085463; Tue, 05 Dec 2023 13:18:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cramer Date: Tue, 5 Dec 2023 16:17:48 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: during call SQLFreeHandle, the connection is broken. client can't be notified. To: LiChong <527474735@qq.com> Cc: "pgsql-odbc@postgresql.org" Content-Type: multipart/mixed; boundary="0000000000003a2466060bc9c5ac" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003a2466060bc9c5ac Content-Type: multipart/alternative; boundary="0000000000003a2465060bc9c5aa" --0000000000003a2465060bc9c5aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi LiChong, Attached is a patch which is the diff between your file and the current master There are some differences at the bottom of the file that seem to indicate that your version of the source is older than the current master. Can you confirm? Also can you send back your changes in a patch file. I used git diff to produce the attached patch Dave Cramer www.postgres.rocks On Tue, 5 Dec 2023 at 10:05, LiChong <527474735@qq.com> wrote: > =E4=BD=A0=E5=A5=BD > > > =E4=BA=8B=E5=8A=A1=E5=9C=BA=E6=99=AF=E4=B8=8B=EF=BC=8CSQLFreeHandle=E8=B0= =83=E7=94=A8=E8=BF=9B=E8=A1=8C=E4=B8=AD=EF=BC=8C=E8=BF=9E=E6=8E=A5=E6=96=AD= =E5=BC=80=EF=BC=8C=E4=BD=86=E6=98=AFSQLFreeHandle=E8=BF=94=E5=9B=9ESQL_SUCC= ESS=E3=80=82=E7=94=B1=E4=BA=8ESQLFreeHandle=E8=B0=83=E7=94=A8=E8=BF=9E=E6= =8E=A5=E6=96=AD=E5=BC=80=EF=BC=8C=E8=A7=A6=E5=8F=91cc_on_abort=EF=BC=8C=E5= =B0=86=E4=BA=8B=E5=8A=A1=E5=8F=96=E6=B6=88=EF=BC=8C=E5=9C=A8=E5=AE=A2=E6=88= =B7=E7=AB=AF=E6=89=A7=E8=A1=8Ccommit=E6=97=B6=EF=BC=8C=E6=B2=A1=E6=9C=89=E4= =B8=8E=E6=9C=8D=E5=8A=A1=E7=AB=AF=E4=BA=A4=E4=BA=92=E5=B9=B6=E4=B8=94=E8=BF= =94=E5=9B=9E=E6=88=90=E5=8A=9F=EF=BC=8C=E5=AF=BC=E8=87=B4=E5=AE=A2=E6=88=B7= =E7=AB=AF=E4=BB=A5=E4=B8=BA=E6=95=B0=E6=8D=AE=E5=B7=B2=E6=8F=90=E4=BA=A4=EF= =BC=8C=E5=AF=BC=E8=87=B4=E4=B8=A2=E6=95=B0=E6=8D=AE=E3=80=82 > > In a transaction scenario, the connection is disconnected while the > SQLFreeHandle call is in progress, but SQLFreeHandle returns SQL_SUCCESS. > Because the connection is disconnected by the SQLFreeHandle call, the > cc_on_abort is triggered, the transaction is canceled, and the client > performs a commit without interacting with the server and returning > success, causing the client to think that the data has been submitted, > resulting in data loss. > > call step: > SQLAllocHandle1 > sql1 > SQLFreeHandle1 > SQLAllocHandle2 > sql2 > SQLFreeHandle2 > commit > > during call SQLFreeHandle2=EF=BC=8C the connection is broken. client can'= t be > notified. > we modify the code, in statement.c SC_Destructor and PGAPI_FreeStmt, Is > there any other better solution to this problem? Please share your though= ts > and suggestions, thanks. > > > below is psqlodbc log, debug=3D2 > -------------- > [7f5843a3a700] bind.c[PDATA_free_params]689: leaving > [7f5843a3a700] results.c[PGAPI_MoreResults]2035: leaving 100 > [7f5843a3a700]odbcapi30.[SQLFreeHandle]250: Entering > [7f5843a3a700]statement.[PGAPI_FreeStmt]248: > entering...hstmt=3D0x7f583c044600, fOption=3D1 > [7f5843a3a700] qresult.c[QR_Destructor]344: entering > [7f5843a3a700]statement.[SC_init_Result]536: leaving(0x7f583c044600) > [7f5843a3a700]statement.[SC_Destructor]483: entering self=3D0x7f583c04460= 0, > self->result=3D(nil), self->hdbc=3D0xe27cc0 > [7f5843a3a700]connection[CC_send_query_append]1809: conn=3D0xe27cc0, > query=3D'DEALLOCATE "_PLAN0x7f583c044600"' > [7f5843a3a700]connection[CC_send_query_append]1891: query_len=3D32 > [7f5843a3a700]connection[CC_send_query_append]1935: [QLOG]PQsendQuery: > 0xdf4990 'SAVEPOINT _per_query_svp_;DEALLOCATE > "_PLAN0x7f583c044600";RELEASE _per_query_svp_' > [7f5843a3a700] qresult.c[QR_Constructor]173: entering > [7f5843a3a700] qresult.c[QR_Constructor]242: leaving 0x7f583c030380 > [7f5843a3a700]connection[handle_pgres_error]864: > PG_DIAG_SEVERITY_NONLOCALIZED=3D(null) > [7f5843a3a700]connection[handle_pgres_error]883: [QLOG] ((null)) (null) > '(null)' > [7f5843a3a700]connection[handle_pgres_error]950: error message=3Dserver > closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > (137) > [7f5843a3a700]connection[CC_on_abort]1582: entering opt=3D2 > [7f5843a3a700]connection[CC_on_abort]1604: [QLOG]PQfinish: 0xdf4990 > [7f5843a3a700] qresult.c[QR_Destructor]344: entering > [7f5843a3a700] qresult.c[QR_close_result]255: entering > [7f5843a3a700] qresult.c[QR_free_memory]479: entering fcount=3D0 > [7f5843a3a700] qresult.c[QR_free_memory]577: leaving > [7f5843a3a700] qresult.c[QR_close_result]319: leaving > [7f5843a3a700] qresult.c[QR_Destructor]348: leaving > [7f5843a3a700] bind.c[APD_free_params]643: entering self=3D0x7f583c044= 7e0 > [7f5843a3a700] bind.c[APD_free_params]655: leaving > [7f5843a3a700] bind.c[IPD_free_params]698: entering self=3D0x7f583c044= 850 > [7f5843a3a700] bind.c[IPD_free_params]709: leaving > [7f5843a3a700] bind.c[PDATA_free_params]663: entering > self=3D0x7f583c044948 > [7f5843a3a700] bind.c[PDATA_free_params]689: leaving > [7f5843a3a700]statement.[SC_Destructor]526: leaving > [7f5843a3a700]odbcapi30.[SQLEndTran]171: Entering > [7f5843a3a700] execute.c[PGAPI_Transact]1208: entering hdbc=3D0xe27cc0, > henv=3D(nil) > [7f5843a3a700]odbcapi30.[SQLAllocHandle]40: Entering > [7f5843a3a700]statement.[PGAPI_AllocStmt]189: entering... > > Best Wishes > ------------------------------ > LiChong > 527474735@qq.com > > > > --0000000000003a2465060bc9c5aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0LiChong,

Attached is a patch wh= ich is the diff between your file and the current master

There are some differences at the bottom of the file that seem to in= dicate that your version of the source is older than the current master. Ca= n you confirm?

Also can you send back your changes= in a patch file.

I used git diff to produce the a= ttached patch=C2=A0
Dave Cramerwww.postgres.rocks


On Tue, 5 Dec 2023 a= t 10:05, LiChong <527474735@qq.com> wrote:
=E4=BD=A0=E5=A5=BD

=E4=BA=8B=E5=8A=A1=E5= =9C=BA=E6=99=AF=E4=B8=8B=EF=BC=8CSQLFreeHandle=E8=B0=83=E7=94=A8=E8=BF=9B= =E8=A1=8C=E4=B8=AD=EF=BC=8C=E8=BF=9E=E6=8E=A5=E6=96=AD=E5=BC=80=EF=BC=8C=E4= =BD=86=E6=98=AFSQLFreeHandle=E8=BF=94=E5=9B=9ESQL_SUCCESS=E3=80=82=E7=94=B1= =E4=BA=8ESQLFreeHandle=E8=B0=83=E7=94=A8=E8=BF=9E=E6=8E=A5=E6=96=AD=E5=BC= =80=EF=BC=8C=E8=A7=A6=E5=8F=91cc_on_abort=EF=BC=8C=E5=B0=86=E4=BA=8B=E5=8A= =A1=E5=8F=96=E6=B6=88=EF=BC=8C=E5=9C=A8=E5=AE=A2=E6=88=B7=E7=AB=AF=E6=89=A7= =E8=A1=8Ccommit=E6=97=B6=EF=BC=8C=E6=B2=A1=E6=9C=89=E4=B8=8E=E6=9C=8D=E5=8A= =A1=E7=AB=AF=E4=BA=A4=E4=BA=92=E5=B9=B6=E4=B8=94=E8=BF=94=E5=9B=9E=E6=88=90= =E5=8A=9F=EF=BC=8C=E5=AF=BC=E8=87=B4=E5=AE=A2=E6=88=B7=E7=AB=AF=E4=BB=A5=E4= =B8=BA=E6=95=B0=E6=8D=AE=E5=B7=B2=E6=8F=90=E4=BA=A4=EF=BC=8C=E5=AF=BC=E8=87= =B4=E4=B8=A2=E6=95=B0=E6=8D=AE=E3=80=82

In a trans= action scenario, the connection is disconnected while the SQLFreeHandle cal= l is in progress, but SQLFreeHandle returns SQL_SUCCESS. Because the connec= tion is disconnected by the SQLFreeHandle call, the cc_on_abort is triggere= d, the transaction is canceled, and the client performs a commit without in= teracting with the server and returning success, causing the client to thin= k that the data has been submitted, resulting in data loss.

call step:<= /span>
SQLAllocHandle1
sql1
SQLFreeHandle1
SQLAllocHandle2
sql2
SQLFreeHandle2
c= ommit

during=C2=A0call SQLFreeHandle2=EF=BC=8C the= connection=C2=A0is broken. client can't=C2=A0be=C2=A0n= otified.
we modify the code, in statement.c=C2=A0SC_Destru= ctor and PGAPI_FreeStmt,=C2=A0=C2=A0Is there any other better solution to this problem? Please share your th= oughts and suggestions, thanks.


<= div>below is psqlodbc log, = debug=3D2
--------------
[7f5843a3a700]=C2= =A0 =C2=A0 bind.c[PDATA_free_params]689: leaving
[7f5843a3a700] r= esults.c[PGAPI_MoreResults]2035: leaving 100
[7f5843a3a700]odbcap= i30.[SQLFreeHandle]250: Entering
[7f5843a3a700]statement.[PGAPI_F= reeStmt]248: entering...hstmt=3D0x7f583c044600, fOption=3D1
[7f58= 43a3a700] qresult.c[QR_Destructor]344: entering
[7f5843a3a700]sta= tement.[SC_init_Result]536: leaving(0x7f583c044600)
[7f5843a3a700= ]statement.[SC_Destructor]483: entering self=3D0x7f583c044600, self->res= ult=3D(nil), self->hdbc=3D0xe27cc0
[7f= 5843a3a700]connection[CC_send_query_append]1809: conn=3D0xe27cc0, query=3D&= #39;DEALLOCATE "_PLAN0x7f583c044600"'
[7f5843a3a700]connection[CC_send_query_append]1891: query= _len=3D32
[7f5843a3a700]connection= [CC_send_query_append]1935: [QLOG]PQsendQuery: 0xdf4990 'SAVEPOINT _per= _query_svp_;DEALLOCATE "_PLAN0x7f583c044600";RELEASE _per_query_s= vp_'
[7f5843a3a700] qresult.c[= QR_Constructor]173: entering
[7f58= 43a3a700] qresult.c[QR_Constructor]242: leaving 0x7f583c030380
=
[7f5843a3a700]connection[handle_pgres_error]86= 4: PG_DIAG_SEVERITY_NONLOCALIZED=3D(null)
[7f5843a3a700]connection[handle_pgres_error]883: [QLOG] ((null)) (null) '(null)'
[7f5843a3a700]connection[handle_pgres_erro= r]950: error message=3Dserver closed the connection unexpectedly
This probably means the server terminat= ed abnormally
before o= r while processing the request.
(137)
[7f5843a3a700]connectio= n[CC_on_abort]1582: entering opt=3D2
[7f5843a3a700]connection[CC_on_abort]1604: [QLOG]PQfinish: 0xdf4990
[7f5843a3a700] qresult.c[QR_Destructor]344: entering
[7f5843a3a700] qresult.c[QR_close_result]255: entering
[7f5843a3= a700] qresult.c[QR_free_memory]479: entering fcount=3D0
[7f5843a3= a700] qresult.c[QR_free_memory]577: leaving
[7f5843a3a700] qresul= t.c[QR_close_result]319: leaving
[7f5843a3a700] qresult.c[QR_Dest= ructor]348: leaving
[7f5843a3a700]=C2=A0 =C2=A0 bind.c[APD_free_p= arams]643: entering self=3D0x7f583c0447e0
[7f5843a3a700]=C2=A0 = =C2=A0 bind.c[APD_free_params]655: leaving
[7f5843a3a700]=C2=A0 = =C2=A0 bind.c[IPD_free_params]698: entering self=3D0x7f583c044850
[7f5843a3a700]=C2=A0 =C2=A0 bind.c[IPD_free_params]709: leaving
= [7f5843a3a700]=C2=A0 =C2=A0 bind.c[PDATA_free_params]663: entering self=3D0= x7f583c044948
[7f5843a3a700]=C2=A0 =C2=A0 bind.c[PDATA_free_param= s]689: leaving
[7f5843a3a700]statement.[SC_Destructor]526: leavin= g
[7f5843a3a700]odbcapi30.[SQLEndTran]171= : Entering
[7f5843a3a700] execute.= c[PGAPI_Transact]1208: entering hdbc=3D0xe27cc0, henv=3D(nil)
<= div>[7f5843a3a700]odbcapi30.[SQLAllocHandle]40: Entering
[7f5843a= 3a700]statement.[PGAPI_AllocStmt]189: entering...
 --0000000000003a2465060bc9c5aa-- --0000000000003a2466060bc9c5ac Content-Type: application/octet-stream; name="statement.c.patch" Content-Disposition: attachment; filename="statement.c.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lpsud8a30 ZGlmZiAtLWdpdCBhL3N0YXRlbWVudC5jIGIvc3RhdGVtZW50LmMKaW5kZXggZjQ1Y2Q3OS4uMGRm NTVkNCAxMDA2NDQKLS0tIGEvc3RhdGVtZW50LmMKKysrIGIvc3RhdGVtZW50LmMKQEAgLTI5Niw3 ICsyOTYsMTAgQEAgUEdBUElfRnJlZVN0bXQoSFNUTVQgaHN0bXQsCiAJCWlmIChzdG10LT5leGVj dXRlX3BhcmVudCkKIAkJCXN0bXQtPmV4ZWN1dGVfcGFyZW50LT5leGVjdXRlX2RlbGVnYXRlID0g TlVMTDsKIAkJLyogRGVzdHJveSB0aGUgc3RhdGVtZW50IGFuZCBmcmVlIGFueSByZXN1bHRzLCBj dXJzb3JzLCBldGMuICovCi0JCVNDX0Rlc3RydWN0b3Ioc3RtdCk7CisJCS8vU0NfRGVzdHJ1Y3Rv cihzdG10KTsKKwkJLyppZiB0aGUgY29ubmVjdGlvbiB3YXMgZ2l2ZSB1cCxyZXR1cm4gU1FMX0VS Uk9SLiovCisJCWlmKFNDX0Rlc3RydWN0b3Ioc3RtdCkgPT0gRkFMU0UpCisJCQlyZXR1cm4gU1FM X0VSUk9SOwogCX0KIAllbHNlIGlmIChmT3B0aW9uID09IFNRTF9VTkJJTkQpCiAJCVNDX3VuYmlu ZF9jb2xzKHN0bXQpOwpAQCAtNDc3LDYgKzQ4MCw3IEBAIFNDX0NvbnN0cnVjdG9yKENvbm5lY3Rp b25DbGFzcyAqY29ubikKIGNoYXIKIFNDX0Rlc3RydWN0b3IoU3RhdGVtZW50Q2xhc3MgKnNlbGYp CiB7CisJY2hhciBjUmV0ID0gVFJVRTsKIAlDU1RSIGZ1bmMJPSAiU0NfRGVzdHJ1Y3RvciI7CiAJ UVJlc3VsdENsYXNzCSpyZXMgPSBTQ19nZXRfUmVzdWx0KHNlbGYpOwogCkBAIC00OTgsNiArNTAy LDEyIEBAIFNDX0Rlc3RydWN0b3IoU3RhdGVtZW50Q2xhc3MgKnNlbGYpCiAKIAlTQ19pbml0aWFs aXplX3N0bXRzKHNlbGYsIFRSVUUpOwogCisJaWYoc2VsZi0+aGRiYyAmJiAhc2VsZi0+aGRiYy0+ cHFjb25uKQorCXsKKwkJU0Nfc2V0X2Vycm9yKHNlbGYsIFNUTVRfQ09NTVVOSUNBVElPTl9FUlJP UiwgImNvbm5lY3Rpb24gZXJyb3IuIiwgZnVuYyk7CisJCWNSZXQgPSBGQUxTRTsKKwl9CisKICAg ICAgICAgLyogRnJlZSB0aGUgcGFyc2VkIHRhYmxlIGluZm9ybWF0aW9uICovCiAJU0NfaW5pdGlh bGl6ZV9jb2xzX2luZm8oc2VsZiwgRkFMU0UsIFRSVUUpOwogCkBAIC01MjUsNyArNTM1LDcgQEAg U0NfRGVzdHJ1Y3RvcihTdGF0ZW1lbnRDbGFzcyAqc2VsZikKIAogCU1ZTE9HKDAsICJsZWF2aW5n XG4iKTsKIAotCXJldHVybiBUUlVFOworCXJldHVybiBjUmV0OwogfQogCiB2b2lkCkBAIC0yMzA0 LDcgKzIzMTQsNiBAQCBNWUxPRyhERVRBSUxfTE9HX0xFVkVMLCAiISFTQ19mZXRjaCByZXR1cm4g PSVkXG4iLCByZXQpOwogCQl7CiAJCQljaGFyCQkJZmV0Y2hbMTI4XTsKIAkJCVFSZXN1bHRDbGFz cyAJKmxhc3QgPSBOVUxMLCAqcmVzOwotCQkJQk9PTAkJCXJlZmN1cnNvcl9mb3VuZCA9IEZBTFNF OwogCiAJCQkvKiBJdGVyYXRlIHRoZSBjb2x1bW5zIGluIHRoZSByZXN1bHQgdG8gbG9vayBmb3Ig cmVmY3Vyc29ycyAqLwogCQkJbnVtY29scyA9IFFSX051bVJlc3VsdENvbHMocmhvbGQuZmlyc3Qp OwpAQCAtMjMxOSwxMiArMjMyOCw3IEBAIE1ZTE9HKERFVEFJTF9MT0dfTEVWRUwsICIhIVNDX2Zl dGNoIHJldHVybiA9JWRcbiIsIHJldCk7CiAJCQkJCQlicmVhazsKIAkJCQkJfQogCi0JCQkJCXJl ZmN1cnNvcl9mb3VuZCA9IFRSVUU7CiAJCQkJCVNUUl9UT19OQU1FKHNlbGYtPmN1cnNvcl9uYW1l LCBRUl9nZXRfdmFsdWVfYmFja2VuZF90ZXh0KHJob2xkLmZpcnN0LCAwLCBpKSk7Ci0JCQkJCS8q IFNraXAgTlVMTCByZWZjdXJzb3JzIChhbGxvd3MgcHJvY2VkdXJlIHRvIHJldHVybiBhIHZhcmlh YmxlIG51bWJlciBvZiByZXN1bHRzKSAqLwotCQkJCQlpZiAoIVNDX2N1cnNvcl9pc192YWxpZChz ZWxmKSkKLQkJCQkJCWNvbnRpbnVlOwotCiAJCQkJCVNDX3NldF9mZXRjaGN1cnNvcihzZWxmKTsK IAkJCQkJcWkucmVzdWx0X2luID0gTlVMTDsKIAkJCQkJcWkuY3Vyc29yID0gU0NfY3Vyc29yX25h bWUoc2VsZik7CkBAIC0yMzQ1LDIzICsyMzQ5LDE5IEBAIE1ZTE9HKERFVEFJTF9MT0dfTEVWRUws ICIhIVNDX2ZldGNoIHJldHVybiA9JWRcbiIsIHJldCk7CiAJCQkJCQkJUVJfY29uY2F0KGxhc3Qs IHJlcyk7CiAJCQkJCQkJc2VsZi0+bXVsdGlfc3RhdGVtZW50ID0gVFJVRTsKIAkJCQkJCX0KLQkJ CQkJCWxhc3QgPSByZXM7CiAJCQkJCQlpZiAoIVFSX2NvbW1hbmRfbWF5YmVfc3VjY2Vzc2Z1bChy ZXMpKQogCQkJCQkJewogCQkJCQkJCVNDX3NldF9lcnJvcmluZm8oc2VsZiwgcmVzLCAwKTsKKwkJ CQkJCQlRUl9EZXN0cnVjdG9yKHJob2xkLmZpcnN0KTsKIAkJCQkJCQlicmVhazsKIAkJCQkJCX0K KworCQkJCQkJbGFzdCA9IHJlczsKIAkJCQkJfQogCQkJCX0KIAkJCX0KLQkJCWlmIChyZWZjdXJz b3JfZm91bmQpCi0JCQl7Ci0JCQkJLyogRGlzY2FyZCBvcmlnaW5hbCByZXN1bHQgKi8KLQkJCQlp ZiAoTlVMTCA9PSBsYXN0KQotCQkJCQlTQ19zZXRfUmVzdWx0KHNlbGYsIFFSX0NvbnN0cnVjdG9y KCkpOwkvKiByZXR1cm4gZW1wdHkgcmVzdWx0ICovCi0JCQkJZWxzZQotCQkJCQlRUl9EZXN0cnVj dG9yKHJob2xkLmZpcnN0KTsKLQkJCX0KKwkJCWlmIChsYXN0KQorCQkJCVFSX0Rlc3RydWN0b3Io cmhvbGQuZmlyc3QpOwogCQl9CiAJfQogY2xlYW51cDoK --0000000000003a2466060bc9c5ac--