Content-Type: multipart/mixed; boundary="------------eEo5P9j9zDRcFvL1VG6L71zb"
Message-ID: <5eba3ea5-ae13-aab2-35d6-cd3e58dab08b@gmail.com>
Date: Sat, 16 Sep 2023 20:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #18070: Assertion failed when processing error from plpy's
 iterator
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs@lists.postgresql.org
References: <18070-ab9c171cbf4ebb0f@postgresql.org>
 <9fa9c154-d084-07de-8224-aab7fc8a119e@gmail.com>
 <ZQVm8KponTxqj8G3@paquier.xyz> <3920993.1694874885@sss.pgh.pa.us>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <3920993.1694874885@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/5eba3ea5-ae13-aab2-35d6-cd3e58dab08b%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------eEo5P9j9zDRcFvL1VG6L71zb
Content-Type: multipart/alternative;
 boundary="------------cWWVj1UQzMPjcEyR7dL6Vz4V"

--------------cWWVj1UQzMPjcEyR7dL6Vz4V
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

16.09.2023 17:34, Tom Lane wrote:
> Michael Paquier<michael@paquier.xyz>  writes:
>> On Fri, Sep 15, 2023 at 08:00:00PM +0300, Alexander Lakhin wrote:
>>> +        /*
>>> +         * When we have no detail from the error data, an exception message,
>>> +         * if not empty, goes in the detail.
>>> +         */
>>> +        if (detail == NULL && xmsg != NULL)
>>> 		detail = xmsg;
>> Yeah, I think that you're right here to enforce the use of a DETAIL
>> message if it exists instead of the xmsg.
> I dunno about that.  We're trying to shove three pounds of stuff into
> a two-pound sack, which isn't going to work perfectly in any case,
> but I'm not sure this is the right priority order for the available
> strings.

Thanks for looking at this!

> In the original example with an infinite-recursion error, what we
> end up with at the point of the Assert is
>
> (gdb) i locals
> save_errno = 2
> xmsg = 0x666a8d8 "spiexceptions.StatementTooComplex: error fetching next item from iterator"
> tbmsg = 0x666ace8 "Traceback (most recent call last):"
> tb_depth = 1
> emsg = {data = 0x666b0f8 "error fetching next item from iterator", len = 38,
>    maxlen = 1024, cursor = 0}
> exc = 0x18fd448
> val = 0x7f1fefe39e88
> tb = 0x7f1fef858608
> primary = 0x666b0f8 "error fetching next item from iterator"
> sqlerrcode = 16777477
> detail = 0x7f1fefe21920 "spiexceptions.StatementTooComplex: stack depth limit exceeded"
> hint = 0x7f1ffd5c6f78 "Increase the configuration parameter \"max_stack_depth\" (currently 2048kB), after ensuring the platform's stack depth limit is adequate."
> query = 0x0
> position = 0
> schema_name = 0x0
> table_name = 0x0
> column_name = 0x0
> datatype_name = 0x0
>
> Clearly, "detail" offers the key insight here and we don't want to
> lose it; but xmsg seems rather duplicative of the fmt string
> (which is what is reflected into emsg and primary here).
>
> On the other hand, in Alexander's newer test case we find
>
> (gdb) i locals
> save_errno = 2
> xmsg = 0x191ef50 "spiexceptions.WrongObjectType: cannot open relation \"tst\""
> tbmsg = 0x191f360 "Traceback (most recent call last):"
> tb_depth = 1
> emsg = {data = 0x191f770 "error fetching next item from iterator", len = 38,
>    maxlen = 1024, cursor = 0}
> exc = 0x18f02f8
> val = 0x7f1fefda7e88
> tb = 0x7f1fefcfd3c8
> primary = 0x191f770 "error fetching next item from iterator"
> sqlerrcode = 151027844
> detail = 0x7f1fefe1fa20 "This operation is not supported for composite types."
> hint = 0x0
> query = 0x7f1fefcfc3c0 "SELECT * FROM tst"
> position = 15
> schema_name = 0x0
> table_name = 0x0
> column_name = 0x0
> datatype_name = 0x0
>
> Here, xmsg seems strictly more useful than fmt, but the patch as
> proposed would discard xmsg.
>
> I wonder if we shouldn't simply say the rule is that xmsg, if set,
> overrides fmt.  This'd likely have some impact on existing test
> cases, but perhaps the net result would be no worse?

When looking for a representative query for a regression test, I've
also discovered that the result is not always appealing.

Yes, for the case "SELECT * FROM some_type" you mentioned, with the patched
version we get "detail" from the underlying exception:
DETAIL:  This operation is not supported for composite types.

But without the patch we get "message":
DETAIL:  spiexceptions.WrongObjectType: cannot open relation "tst"

In this case the difference is minor, but I would prefer to get a message
with the relation name.
I've tested another case, with to_date():
                 ereturn(escontext, -1,
(errcode(ERRCODE_INVALID_DATETIME_FORMAT),
                                  errmsg("invalid value \"%s\" for \"%s\"",
                                                 copy, node->key->name),
                                  errdetail("Value must be an integer.")));

With the patched version, the error produced by:
CREATE FUNCTION python_error_detail() RETURNS SETOF text AS $$
   plan = plpy.prepare("SELECT to_date('DD', 'DD') d")
   for row in plpy.cursor(plan):
     yield row['d']
$$ LANGUAGE plpython3u;

SELECT python_error_detail();

looks as follows:
  ERROR:  error fetching next item from iterator
  DETAIL:  Value must be an integer.
  CONTEXT:  Traceback (most recent call last):
  PL/Python function "python_error_detail"

I can't say that the detail info "Value must be an integer" is useful here.

So if we omit the exception message, while keeping the detail, we loose a
higher importance level of information in the stack (or a sack):
1) plpy_elog message
2) underlying exception message
3) underlying exception detail
4) underlying exception hint

I also thought about omitting the underlying exception detail, thus just
doing mapping:
"plpy_elog message" -> message,
"underlying exception message" -> detail,
"underlying exception hint" -> hint,
but it seems that presenting a hint without an intermediate level of
information (detail) could look weird in some cases too.

So my next idea was to concatenate "underlying exception message" +
"underlying exception detail" and to put the result in the detail.

It seems that it works pretty well, e.g. for the case with to_date(), we get:
SELECT python_error_detail();
ERROR:  error fetching next item from iterator
DETAIL:  spiexceptions.InvalidDatetimeFormat: invalid value "DD" for "DD"
Value must be an integer.
CONTEXT:  Traceback (most recent call last):
PL/Python function "python_error_detail"

(I've confirmed that all these strings are localized correctly.)

With the stack overflow case, the function PLy_elog() called recursively,
so the output looks like:
SELECT pyfunc();
ERROR:  error fetching next item from iterator
DETAIL:  spiexceptions.StatementTooComplex: error fetching next item from iterator
spiexceptions.StatementTooComplex: error fetching next item from iterator

...
spiexceptions.StatementTooComplex: error fetching next item from iterator
spiexceptions.StatementTooComplex: error fetching next item from iterator
spiexceptions.StatementTooComplex: stack depth limit exceeded
HINT:  Increase the configuration parameter "max_stack_depth" (currently 2048kB), after ensuring the platform's stack 
depth limit is adequate.
CONTEXT:  Traceback (most recent call last):
PL/Python function "pyfunc"

This lengthy output is similar to what we get with a recursion in plperl,
so I don't consider this as an issue, but may be we could just check
the length of an error message before concatenation...

Please look at the v2 patch, which contains an addition to regression tests for the master.
If you agree with this approach, I'll make patches for back branches as well...

Best regards,
Alexander
--------------cWWVj1UQzMPjcEyR7dL6Vz4V
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello,<br>
      <br>
      16.09.2023 17:34, Tom Lane wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:3920993.1694874885@sss.pgh.pa.us">
      <pre class="moz-quote-pre" wrap="">Michael Paquier <a class="moz-txt-link-rfc2396E" href="mailto:michael@paquier.xyz">&lt;michael@paquier.xyz&gt;</a> writes:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">On Fri, Sep 15, 2023 at 08:00:00PM +0300, Alexander Lakhin wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">+        /*
+         * When we have no detail from the error data, an exception message,
+         * if not empty, goes in the detail.
+         */
+        if (detail == NULL &amp;&amp; xmsg != NULL)
		detail = xmsg;
</pre>
        </blockquote>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Yeah, I think that you're right here to enforce the use of a DETAIL
message if it exists instead of the xmsg.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I dunno about that.  We're trying to shove three pounds of stuff into
a two-pound sack, which isn't going to work perfectly in any case,
but I'm not sure this is the right priority order for the available
strings.</pre>
    </blockquote>
    <br>
    Thanks for looking at this!<br>
    <br>
    <blockquote type="cite" cite="mid:3920993.1694874885@sss.pgh.pa.us">
      <pre class="moz-quote-pre" wrap="">
In the original example with an infinite-recursion error, what we
end up with at the point of the Assert is

(gdb) i locals
save_errno = 2
xmsg = 0x666a8d8 "spiexceptions.StatementTooComplex: error fetching next item from iterator"
tbmsg = 0x666ace8 "Traceback (most recent call last):"
tb_depth = 1
emsg = {data = 0x666b0f8 "error fetching next item from iterator", len = 38, 
  maxlen = 1024, cursor = 0}
exc = 0x18fd448
val = 0x7f1fefe39e88
tb = 0x7f1fef858608
primary = 0x666b0f8 "error fetching next item from iterator"
sqlerrcode = 16777477
detail = 0x7f1fefe21920 "spiexceptions.StatementTooComplex: stack depth limit exceeded"
hint = 0x7f1ffd5c6f78 "Increase the configuration parameter \"max_stack_depth\" (currently 2048kB), after ensuring the platform's stack depth limit is adequate."
query = 0x0
position = 0
schema_name = 0x0
table_name = 0x0
column_name = 0x0
datatype_name = 0x0

Clearly, "detail" offers the key insight here and we don't want to
lose it; but xmsg seems rather duplicative of the fmt string
(which is what is reflected into emsg and primary here).

On the other hand, in Alexander's newer test case we find

(gdb) i locals
save_errno = 2
xmsg = 0x191ef50 "spiexceptions.WrongObjectType: cannot open relation \"tst\""
tbmsg = 0x191f360 "Traceback (most recent call last):"
tb_depth = 1
emsg = {data = 0x191f770 "error fetching next item from iterator", len = 38, 
  maxlen = 1024, cursor = 0}
exc = 0x18f02f8
val = 0x7f1fefda7e88
tb = 0x7f1fefcfd3c8
primary = 0x191f770 "error fetching next item from iterator"
sqlerrcode = 151027844
detail = 0x7f1fefe1fa20 "This operation is not supported for composite types."
hint = 0x0
query = 0x7f1fefcfc3c0 "SELECT * FROM tst"
position = 15
schema_name = 0x0
table_name = 0x0
column_name = 0x0
datatype_name = 0x0

Here, xmsg seems strictly more useful than fmt, but the patch as
proposed would discard xmsg.

I wonder if we shouldn't simply say the rule is that xmsg, if set,
overrides fmt.  This'd likely have some impact on existing test
cases, but perhaps the net result would be no worse?</pre>
    </blockquote>
    <br>
    When looking for a representative query for a regression test, I've<br>
    also discovered that the result is not always appealing.<br>
    <br>
    Yes, for the case "SELECT * FROM some_type" you mentioned, with the
    patched<br>
    version we get "detail" from the underlying exception:<br>
    DETAIL:  This operation is not supported for composite types.<br>
    <br>
    But without the patch we get "message":<br>
    DETAIL:  spiexceptions.WrongObjectType: cannot open relation "tst"<br>
    <br>
    In this case the difference is minor, but I would prefer to get a
    message<br>
    with the relation name.<br>
    I've tested another case, with to_date():<br>
                    ereturn(escontext, -1,<br>
                                   
    (errcode(ERRCODE_INVALID_DATETIME_FORMAT),<br>
                                     errmsg("invalid value \"%s\" for
    \"%s\"",<br>
                                                    copy,
    node-&gt;key-&gt;name),<br>
                                     errdetail("Value must be an
    integer.")));<br>
    <br>
    With the patched version, the error produced by:<br>
    CREATE FUNCTION python_error_detail() RETURNS SETOF text AS $$<br>
      plan = plpy.prepare("SELECT to_date('DD', 'DD') d")<br>
      for row in plpy.cursor(plan):<br>
        yield row['d']<br>
    $$ LANGUAGE plpython3u;<br>
    <br>
    SELECT python_error_detail();<br>
    <br>
    looks as follows:<br>
     ERROR:  error fetching next item from iterator<br>
     DETAIL:  Value must be an integer.<br>
     CONTEXT:  Traceback (most recent call last):<br>
     PL/Python function "python_error_detail"<br>
    <br>
    I can't say that the detail info "Value must be an integer" is
    useful here.<br>
    <br>
    So if we omit the exception message, while keeping the detail, we
    loose a<br>
    higher importance level of information in the stack (or a sack):<br>
    1) plpy_elog message<br>
    2) underlying exception message<br>
    3) underlying exception detail<br>
    4) underlying exception hint<br>
    <br>
    I also thought about omitting the underlying exception detail, thus
    just<br>
    doing mapping:<br>
    "plpy_elog message" -&gt; message,<br>
    "underlying exception message" -&gt; detail,<br>
    "underlying exception hint" -&gt; hint,<br>
    but it seems that presenting a hint without an intermediate level of<br>
    information (detail) could look weird in some cases too.<br>
    <br>
    So my next idea was to concatenate "underlying exception message" +<br>
    "underlying exception detail" and to put the result in the detail.<br>
    <br>
    It seems that it works pretty well, e.g. for the case with
    to_date(), we get:<br>
    SELECT python_error_detail();<br>
    ERROR:  error fetching next item from iterator<br>
    DETAIL:  spiexceptions.InvalidDatetimeFormat: invalid value "DD" for
    "DD"<br>
    Value must be an integer.<br>
    CONTEXT:  Traceback (most recent call last):<br>
    PL/Python function "python_error_detail"<br>
    <br>
    (I've confirmed that all these strings are localized correctly.)<br>
    <br>
    With the stack overflow case, the function PLy_elog() called
    recursively,<br>
    so the output looks like:<br>
    SELECT pyfunc();<br>
    ERROR:  error fetching next item from iterator<br>
    DETAIL:  spiexceptions.StatementTooComplex: error fetching next item
    from iterator<br>
    spiexceptions.StatementTooComplex: error fetching next item from
    iterator<br>
    <br>
    ...<br>
    spiexceptions.StatementTooComplex: error fetching next item from
    iterator<br>
    spiexceptions.StatementTooComplex: error fetching next item from
    iterator<br>
    spiexceptions.StatementTooComplex: stack depth limit exceeded<br>
    HINT:  Increase the configuration parameter "max_stack_depth"
    (currently 2048kB), after ensuring the platform's stack depth limit
    is adequate.<br>
    CONTEXT:  Traceback (most recent call last):<br>
    PL/Python function "pyfunc"<br>
    <br>
    This lengthy output is similar to what we get with a recursion in
    plperl,<br>
    so I don't consider this as an issue, but may be we could just check<br>
    the length of an error message before concatenation...<br>
    <br>
    Please look at the v2 patch, which contains an addition to
    regression tests for the master.<br>
    If you agree with this approach, I'll make patches for back branches
    as well...<br>
    <br>
    Best regards,<br>
    Alexander<span style="font-family:monospace"><br>
    </span>
  </body>
</html>

--------------cWWVj1UQzMPjcEyR7dL6Vz4V--

--------------eEo5P9j9zDRcFvL1VG6L71zb
Content-Type: text/x-patch; charset=UTF-8; name="v2-01-fix-plpy_elog.patch"
Content-Disposition: attachment; filename="v2-01-fix-plpy_elog.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3NyYy9wbC9wbHB5dGhvbi9leHBlY3RlZC9wbHB5dGhvbl9lcnJvci5v
dXQgYi9zcmMvcGwvcGxweXRob24vZXhwZWN0ZWQvcGxweXRob25fZXJyb3Iub3V0CmluZGV4
IDlhZjdlYTcyOTIuLjMzYjY0YTA2MDQgMTAwNjQ0Ci0tLSBhL3NyYy9wbC9wbHB5dGhvbi9l
eHBlY3RlZC9wbHB5dGhvbl9lcnJvci5vdXQKKysrIGIvc3JjL3BsL3BscHl0aG9uL2V4cGVj
dGVkL3BscHl0aG9uX2Vycm9yLm91dApAQCAtNDQ1LDMgKzQ0NSwxNyBAQCBQTC9QeXRob24g
ZnVuY3Rpb24gIm5vdGljZV9vdXRlcmZ1bmMiCiAgICAgICAgICAgICAgICAgMQogKDEgcm93
KQogCisvKiBXaGVuIGFuIGVycm9yIGxvZ2dlZCB3aXRoIGFuIHVuZGVybHlpbmcgZXhjZXB0
aW9uLCB0aGUgZGV0YWlsIHNob3VsZAorKiAgY29udGFpbiBhIGRldGFpbCBtZXNzYWdlIGZy
b20gdGhlIGV4Y2VwdGlvbgorKi8KK0NSRUFURSBGVU5DVElPTiBweXRob25fZXJyb3JfZGV0
YWlsKCkgUkVUVVJOUyBTRVRPRiB0ZXh0IEFTICQkCisgIHBsYW4gPSBwbHB5LnByZXBhcmUo
IlNFTEVDVCB0b19kYXRlKCdERCcsICdERCcpIGQiKQorICBmb3Igcm93IGluIHBscHkuY3Vy
c29yKHBsYW4pOgorICAgIHlpZWxkIHJvd1snZCddCiskJCBMQU5HVUFHRSBwbHB5dGhvbjN1
OworU0VMRUNUIHB5dGhvbl9lcnJvcl9kZXRhaWwoKTsKK0VSUk9SOiAgZXJyb3IgZmV0Y2hp
bmcgbmV4dCBpdGVtIGZyb20gaXRlcmF0b3IKK0RFVEFJTDogIHNwaWV4Y2VwdGlvbnMuSW52
YWxpZERhdGV0aW1lRm9ybWF0OiBpbnZhbGlkIHZhbHVlICJERCIgZm9yICJERCIKK1ZhbHVl
IG11c3QgYmUgYW4gaW50ZWdlci4KK0NPTlRFWFQ6ICBUcmFjZWJhY2sgKG1vc3QgcmVjZW50
IGNhbGwgbGFzdCk6CitQTC9QeXRob24gZnVuY3Rpb24gInB5dGhvbl9lcnJvcl9kZXRhaWwi
CmRpZmYgLS1naXQgYS9zcmMvcGwvcGxweXRob24vZXhwZWN0ZWQvcGxweXRob25fZXJyb3Jf
NS5vdXQgYi9zcmMvcGwvcGxweXRob24vZXhwZWN0ZWQvcGxweXRob25fZXJyb3JfNS5vdXQK
aW5kZXggN2ZlODY0YTFhNS4uOWNkMGM2NmM1NSAxMDA2NDQKLS0tIGEvc3JjL3BsL3BscHl0
aG9uL2V4cGVjdGVkL3BscHl0aG9uX2Vycm9yXzUub3V0CisrKyBiL3NyYy9wbC9wbHB5dGhv
bi9leHBlY3RlZC9wbHB5dGhvbl9lcnJvcl81Lm91dApAQCAtNDQ1LDMgKzQ0NSwxNyBAQCBQ
TC9QeXRob24gZnVuY3Rpb24gIm5vdGljZV9vdXRlcmZ1bmMiCiAgICAgICAgICAgICAgICAg
MQogKDEgcm93KQogCisvKiBXaGVuIGFuIGVycm9yIGxvZ2dlZCB3aXRoIGFuIHVuZGVybHlp
bmcgZXhjZXB0aW9uLCB0aGUgZGV0YWlsIHNob3VsZAorKiAgY29udGFpbiBhIGRldGFpbCBt
ZXNzYWdlIGZyb20gdGhlIGV4Y2VwdGlvbgorKi8KK0NSRUFURSBGVU5DVElPTiBweXRob25f
ZXJyb3JfZGV0YWlsKCkgUkVUVVJOUyBTRVRPRiB0ZXh0IEFTICQkCisgIHBsYW4gPSBwbHB5
LnByZXBhcmUoIlNFTEVDVCB0b19kYXRlKCdERCcsICdERCcpIGQiKQorICBmb3Igcm93IGlu
IHBscHkuY3Vyc29yKHBsYW4pOgorICAgIHlpZWxkIHJvd1snZCddCiskJCBMQU5HVUFHRSBw
bHB5dGhvbjN1OworU0VMRUNUIHB5dGhvbl9lcnJvcl9kZXRhaWwoKTsKK0VSUk9SOiAgZXJy
b3IgZmV0Y2hpbmcgbmV4dCBpdGVtIGZyb20gaXRlcmF0b3IKK0RFVEFJTDogIHNwaWV4Y2Vw
dGlvbnMuSW52YWxpZERhdGV0aW1lRm9ybWF0OiBpbnZhbGlkIHZhbHVlICJERCIgZm9yICJE
RCIKK1ZhbHVlIG11c3QgYmUgYW4gaW50ZWdlci4KK0NPTlRFWFQ6ICBUcmFjZWJhY2sgKG1v
c3QgcmVjZW50IGNhbGwgbGFzdCk6CitQTC9QeXRob24gZnVuY3Rpb24gInB5dGhvbl9lcnJv
cl9kZXRhaWwiCmRpZmYgLS1naXQgYS9zcmMvcGwvcGxweXRob24vcGxweV9lbG9nLmMgYi9z
cmMvcGwvcGxweXRob24vcGxweV9lbG9nLmMKaW5kZXggN2M2MjdlYWNmYi4uYzg4NDkwYmY1
MCAxMDA2NDQKLS0tIGEvc3JjL3BsL3BscHl0aG9uL3BscHlfZWxvZy5jCisrKyBiL3NyYy9w
bC9wbHB5dGhvbi9wbHB5X2Vsb2cuYwpAQCAtNDcsNiArNDcsNyBAQCBQTHlfZWxvZ19pbXBs
KGludCBlbGV2ZWwsIGNvbnN0IGNoYXIgKmZtdCwuLi4pCiAJY2hhcgkgICAqdGJtc2c7CiAJ
aW50CQkJdGJfZGVwdGg7CiAJU3RyaW5nSW5mb0RhdGEgZW1zZzsKKwlTdHJpbmdJbmZvRGF0
YSBkZXRhaWxzdHI7CiAJUHlPYmplY3QgICAqZXhjLAogCQkJICAgKnZhbCwKIAkJCSAgICp0
YjsKQEAgLTYyLDYgKzYzLDggQEAgUEx5X2Vsb2dfaW1wbChpbnQgZWxldmVsLCBjb25zdCBj
aGFyICpmbXQsLi4uKQogCWNoYXIJICAgKmRhdGF0eXBlX25hbWUgPSBOVUxMOwogCWNoYXIJ
ICAgKmNvbnN0cmFpbnRfbmFtZSA9IE5VTEw7CiAKKwlkZXRhaWxzdHIuZGF0YSA9IE5VTEw7
CisKIAlQeUVycl9GZXRjaCgmZXhjLCAmdmFsLCAmdGIpOwogCiAJaWYgKGV4YyAhPSBOVUxM
KQpAQCAtMTAzLDEyICsxMDYsMTkgQEAgUEx5X2Vsb2dfaW1wbChpbnQgZWxldmVsLCBjb25z
dCBjaGFyICpmbXQsLi4uKQogCQl9CiAJCXByaW1hcnkgPSBlbXNnLmRhdGE7CiAKLQkJLyog
U2luY2Ugd2UgaGF2ZSBhIGZvcm1hdCBzdHJpbmcsIHdlIGNhbm5vdCBoYXZlIGEgU1BJIGRl
dGFpbC4gKi8KLQkJQXNzZXJ0KGRldGFpbCA9PSBOVUxMKTsKLQotCQkvKiBJZiB0aGVyZSdz
IGFuIGV4Y2VwdGlvbiBtZXNzYWdlLCBpdCBnb2VzIGluIHRoZSBkZXRhaWwuICovCi0JCWlm
ICh4bXNnKQorCQkvKgorCQkgKiBJZiB0aGVyZSdzIGFuIGV4Y2VwdGlvbiBtZXNzYWdlLCBp
dCBnb2VzIHRvIHRoZSBkZXRhaWwsCisJCSAqIHByZXBlbmRlZCB0byB0aGUgZXhpc3Rpbmcg
ZGV0YWlsIG1lc3NhZ2UsIGlmIGFueS4KKwkJICovCisJCWlmIChkZXRhaWwgPT0gTlVMTCkK
IAkJCWRldGFpbCA9IHhtc2c7CisJCWVsc2UgaWYgKHhtc2cgIT0gTlVMTCkgeworCQkJaW5p
dFN0cmluZ0luZm8oJmRldGFpbHN0cik7CisJCQlhcHBlbmRTdHJpbmdJbmZvU3RyaW5nKCZk
ZXRhaWxzdHIsIHhtc2cpOworCQkJYXBwZW5kU3RyaW5nSW5mb0NoYXIoJmRldGFpbHN0ciwg
J1xuJyk7CisJCQlhcHBlbmRTdHJpbmdJbmZvU3RyaW5nKCZkZXRhaWxzdHIsIGRldGFpbCk7
CisJCQlkZXRhaWwgPSBkZXRhaWxzdHIuZGF0YTsKKwkJfQogCX0KIAllbHNlCiAJewpAQCAt
MTQxLDYgKzE1MSw4IEBAIFBMeV9lbG9nX2ltcGwoaW50IGVsZXZlbCwgY29uc3QgY2hhciAq
Zm10LC4uLikKIAl7CiAJCWlmIChmbXQpCiAJCQlwZnJlZShlbXNnLmRhdGEpOworCQlpZiAo
ZGV0YWlsc3RyLmRhdGEpCisJCQlwZnJlZShkZXRhaWxzdHIuZGF0YSk7CiAJCWlmICh4bXNn
KQogCQkJcGZyZWUoeG1zZyk7CiAJCWlmICh0Ym1zZykKZGlmZiAtLWdpdCBhL3NyYy9wbC9w
bHB5dGhvbi9zcWwvcGxweXRob25fZXJyb3Iuc3FsIGIvc3JjL3BsL3BscHl0aG9uL3NxbC9w
bHB5dGhvbl9lcnJvci5zcWwKaW5kZXggMTFmMTRlYzVhNy4uNTU0ZWIzNTBiNSAxMDA2NDQK
LS0tIGEvc3JjL3BsL3BscHl0aG9uL3NxbC9wbHB5dGhvbl9lcnJvci5zcWwKKysrIGIvc3Jj
L3BsL3BscHl0aG9uL3NxbC9wbHB5dGhvbl9lcnJvci5zcWwKQEAgLTM0NCwzICszNDQsMTQg
QEAgJCQgTEFOR1VBR0UgcGxweXRob24zdTsKIFxzZXQgU0hPV19DT05URVhUIGFsd2F5cwog
CiBTRUxFQ1Qgbm90aWNlX291dGVyZnVuYygpOworCisvKiBXaGVuIGFuIGVycm9yIGxvZ2dl
ZCB3aXRoIGFuIHVuZGVybHlpbmcgZXhjZXB0aW9uLCB0aGUgZGV0YWlsIHNob3VsZAorKiAg
Y29udGFpbiBhIGRldGFpbCBtZXNzYWdlIGZyb20gdGhlIGV4Y2VwdGlvbgorKi8KK0NSRUFU
RSBGVU5DVElPTiBweXRob25fZXJyb3JfZGV0YWlsKCkgUkVUVVJOUyBTRVRPRiB0ZXh0IEFT
ICQkCisgIHBsYW4gPSBwbHB5LnByZXBhcmUoIlNFTEVDVCB0b19kYXRlKCdERCcsICdERCcp
IGQiKQorICBmb3Igcm93IGluIHBscHkuY3Vyc29yKHBsYW4pOgorICAgIHlpZWxkIHJvd1sn
ZCddCiskJCBMQU5HVUFHRSBwbHB5dGhvbjN1OworCitTRUxFQ1QgcHl0aG9uX2Vycm9yX2Rl
dGFpbCgpOwo=

--------------eEo5P9j9zDRcFvL1VG6L71zb--