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.96) (envelope-from ) id 1wDjXj-003I6i-0T for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Apr 2026 13:47:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wDjXi-009yc0-1I for pgsql-hackers@arkaria.postgresql.org; Fri, 17 Apr 2026 13:47:34 +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.96) (envelope-from ) id 1wDjXi-009ybq-0F for pgsql-hackers@lists.postgresql.org; Fri, 17 Apr 2026 13:47:34 +0000 Received: from mail-yw1-x1132.google.com ([2607:f8b0:4864:20::1132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wDjXf-00000001fBy-45MR for pgsql-hackers@postgresql.org; Fri, 17 Apr 2026 13:47:33 +0000 Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-7b4ee3a88e1so6032667b3.1 for ; Fri, 17 Apr 2026 06:47:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776433649; cv=none; d=google.com; s=arc-20240605; b=Q6H1J7APecMjZ9RvBWwGtHjGX2Y8Ac/oCnz0F6w0Lm4p3xTYqt54rxjiPWnZxDe2tX NzpbeK29ZmOmmLouM6AAqnN0ykflozRGnYQT/co21/hiBdrUBwNWOYJFK4JY/133F6/B wDN3IgAwJn5WzyGl0BNMds9vQa67yyZ6zghRkiisMwVE3iKTSEVzNyiCa9pvmSugpqpN CT0oHSNXnU1O1LJ8G2bvDjg7d8Qqi9ii4bXqySBPSxwCOzLsvTbjmnVwcatr/47SZUQ0 AfmhpA7jGxDK491sONDsPq/S7uHPjAM+EmBv99RuIy+CfyagSBw59JWsQlMKDf99yKCY Y5wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=DxRFnAqW3G6aJIkvrxa8Jq+wpTk5cyAsB7YTusA74GM=; fh=dL0A5gz9hAqUpLeEAhznxrouVFZro37e4dbO2gm4P2w=; b=HprPtmX3Wzl1qNZPudhPayAGplx398gxVhwxu/FbgY0nRYf8fzLjQhd9NGXQ+OOhcd ocMC5llbtmH2zN/mPCvnVBLWhK15MydM8QjYWubUFUDd5QdnV+kcdzUpLKNL8vH/MLa9 VCdyLys4xGAVk1LSzqhK+xBja/o/cEcbf6BFllu+6uS8+06GtEN73nGjO1ur98nQxRFO Uy9ZxfN9fXADoP8rOv/Ge9fNWlIZQX2mou4SV6SiV/JJ0w16r+LjeGasTWxheCQZpGk/ CTd6eDY0u3ZCZ9nlam8+FOx9fdY/80qL6Sha3SwN8Rgn/uKtjzHlNDa2m5gp+PujZDdQ FwaQ==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776433649; x=1777038449; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DxRFnAqW3G6aJIkvrxa8Jq+wpTk5cyAsB7YTusA74GM=; b=FXDHX+j5Mua1AMiNjeXMpAs3YhPdsaEzevA8izbb4sfobXAoyX6HRrWbssjSSFnQwp ET5pPFGU9DRZ2r7IXzkC63zp6oZH0IHH199aYNXsR7GTQLSADxPg0bT/M/EbD0mFIUgU BNz2tkHHfsYvb0yRRpQeZTAzu9Y1nOuNqRbZ7bEggg6rBDfhZpKMuT+tS/UmKm4qjWLW iH9oSkrwog7F1u71DdL2ON8ggdm8XeGTLFNn3SJGq/+43w4xDh0LYZQA7SYwZj3ttHtc qyi1Px9DfzGNwa44B97dBQgpaq1PY8VaLxeLF4VamdbE9JBFwG6DVnE0MEVlRVR+33He 44pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776433649; x=1777038449; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DxRFnAqW3G6aJIkvrxa8Jq+wpTk5cyAsB7YTusA74GM=; b=jFUuf8d6NYJRTvCH2FvxZtU/L+d6hsxRJgOVMX/2rjOJ+TNqC+P+KwZVEkeouBxuSZ JoS6RApM+rmWcZRdaO9ZGFDqGyGLJSE6018qzrODvlXwsUvE0i7XdCDQggXvvju67c9H 8UQtUy2rH0fKdD8pCw7ipjWCX6Q0wITVCK++V/FFEUAiVDCbocUIQJhYEAKzrsuQyonJ oFiLXrE2kQOoKuu8Q+4iVxklFmx62KrzhVUOubD50g58tXZo1CEN5R+tYIRQXM4Hb0io ENuISHz2VJPaWIzqWC1B7drQkO2vzBtH1o+b6w2JiuoHJn8Qr+8brAzYPZGcNXmQdxtU hSbg== X-Gm-Message-State: AOJu0YzTBNQvoOv22X+UDn5rY1j/NvRs4WECc5ZCRLG3coxbcvwEMKZB mCcm4E9Dp8Zpde87HT5KDjyXcwACeEDG0gBF+ZXd89Ml9E4UyyIOGVJCfqqec7cMx9DHE8g+mAD oGkpklCcMqnvmo8RZjIJ4eifXxDRemrM= X-Gm-Gg: AeBDiet79tFKgBUwYDBfp/tkt2VFjOjF5IZMvlIpUCBKzSY292I4wF79DOvwEC+RShe Xuof74gzaLFKch/YUodXiE4nOCPxtyDSwlinXSIdPmnRrRiSJ7vA6bYvOTjOqQCzAfk5BIDzfCK sDvhupcgUzFgq3uuENRZ1STdn0Tu/7DjC/b0jDc3f4B7ZajNRX5t536IFa7ytg7xmyIEnEVWo2d GYIrfKkyi9h9ZRc7g0ONNT/TlWSZ8zu2tPXZioKFRonYX3QIqMg5i5iWK73yJ0FMkB1d+mVuJNf ofRWmcfLACWEa9BX43w= X-Received: by 2002:a05:690c:289:b0:7b7:400a:8712 with SMTP id 00721157ae682-7b9ecf13863mr30805247b3.22.1776433649478; Fri, 17 Apr 2026 06:47:29 -0700 (PDT) MIME-Version: 1.0 References: <0f462532-9790-4334-b503-4ee522225820@iki.fi> In-Reply-To: From: Ayush Tiwari Date: Fri, 17 Apr 2026 19:17:18 +0530 X-Gm-Features: AQROBzCBFs8ykthljnrrmrFBOsMz_rLnIDyfcQX1mwB-WDieM9HmsgPODKxouXI Message-ID: Subject: Re: [PATCH] postmaster: fix stale PM_STARTUP comment To: Heikki Linnakangas Cc: pgsql-hackers@postgresql.org, "noah@leadboat.com" Content-Type: multipart/mixed; boundary="000000000000a53278064fa83097" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a53278064fa83097 Content-Type: multipart/alternative; boundary="000000000000a53277064fa83095" --000000000000a53277064fa83095 Content-Type: text/plain; charset="UTF-8" Hi, On Wed, 15 Apr 2026 at 23:31, Ayush Tiwari wrote: > Hi > > On Wed, 15 Apr 2026 at 22:21, Heikki Linnakangas wrote: > >> On 15/04/2026 16:57, Ayush Tiwari wrote: >> > Hi, >> > >> > The comment above the PM_STARTUP startup-process-failure case still says >> > that there are no other processes running yet, so the postmaster can >> just >> > exit. >> > >> > That no longer matches the current startup flow: PM_STARTUP may already >> > have auxiliary processes running by that point. The attached patch >> updates >> > that comment to describe the current behavior. >> >> Hmm, shouldn't the postmaster kill and wait for the auxiliary processes >> to exit first in that case? ISTM we need code changes here, not just >> comments. >> >> - Heikki >> >> > Yes, I agree, code change is required here. > > The proper thing is to > route this through the existing crash-handling path so the postmaster > SIGQUITs the aux children and waits for them to exit before terminating. > > I think the minimal change is: > > 1. Replace the ExitPostmaster(1) shortcut in the PM_STARTUP > startup-failure case with HandleChildCrash(), which calls > TerminateChildren(SIGQUIT) and transitions through the state > machine. Set StartupStatus = STARTUP_CRASHED so the state > machine does not try to reinitialize. > > 2. Let HandleFatalError() handle PM_STARTUP by transitioning to > PM_WAIT_BACKENDS, instead of the current Assert(false). > > The minimal fix turned out to be smaller than I first described, the existing paragraph immediately below the ExitPostmaster(1) block already handles !EXIT_STATUS_0 with StartupStatus != STARTUP_SIGNALED correctly (sets STARTUP_CRASHED and HandleChildCrash). So, likely fix would be: 1. Deleting the PM_STARTUP ExitPostmaster(1) shortcut, and letting execution fall through to the next stanza. 2. Replacing the Assert(false) for PM_STARTUP in HandleFatalError() with a fall-through to UpdatePMState(PM_WAIT_BACKENDS). Verification that I did for patch: On a fresh initdb'd cluster, I zeroed out the first WAL segment to force the startup process to FATAL at StartupXLOG, then ran PG in foreground under strace. Before (master): LOG: startup process (PID N) exited with exit code 1 LOG: aborting startup due to startup process failure LOG: database system is shut down strace of the postmaster PID shows 0 kill() calls to children before exit_group(1). Checkpointer, bgwriter and io workers were running at the time of the failure and were orphaned. After (patched): LOG: startup process (PID N) exited with exit code 1 LOG: terminating any other active server processes PM_WAIT_BACKENDS -> PM_WAIT_DEAD_END -> PM_NO_CHILDREN> LOG: shutting down due to startup process failure LOG: database system is shut down strace shows 8 SIGQUIT deliveries (4 children, each signaled by PID and by process-group) before the postmaster's own exit_group(1). I've attached a patch, please review and let me know your thoughts. Regards, Ayush --000000000000a53277064fa83095 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Wed, 15 Apr 2= 026 at 23:31, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
Hi
On Wed, 1= 5 Apr 2026 at 22:21, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 15/04/2026 16:57, Ayush Tiwari wrot= e:
> Hi,
>
> The comment above the PM_STARTUP startup-process-failure case still sa= ys
> that there are no other processes running yet, so the postmaster can j= ust
> exit.
>
> That no longer matches the current startup flow: PM_STARTUP may alread= y
> have auxiliary processes running by that point. The attached patch upd= ates
> that comment to describe the current behavior.

Hmm, shouldn't the postmaster kill and wait for the auxiliary processes=
to exit first in that case? ISTM we need code changes here, not just
comments.

- Heikki


Yes, I agree, code change is required = here.

The proper thing is to
route this through the existing cras= h-handling path so the postmaster
SIGQUITs the aux children and waits fo= r them to exit before terminating.

I think the minimal change is:
=C2=A0 1. Replace the ExitPostmaster(1) shortcut in the PM_STARTUP
= =C2=A0 =C2=A0 =C2=A0startup-failure case with HandleChildCrash(), which cal= ls
=C2=A0 =C2=A0 =C2=A0TerminateChildren(SIGQUIT) and transitions throug= h the state
=C2=A0 =C2=A0 =C2=A0machine.=C2=A0 Set StartupStatus =3D STA= RTUP_CRASHED so the state
=C2=A0 =C2=A0 =C2=A0machine does not try to re= initialize.

=C2=A0 2. Let HandleFatalError() handle PM_STARTUP by tr= ansitioning to
=C2=A0 =C2=A0 =C2=A0PM_WAIT_BACKENDS, instead of the curr= ent Assert(false).


The minimal fix turned out to be smaller than I first described, the exis= ting paragraph immediately below the ExitPostmaster(1) block already handle= s !EXIT_STATUS_0 with StartupStatus !=3D STARTUP_SIGNALED correctly (sets S= TARTUP_CRASHED and HandleChildCrash). So, likely fix would be:

1. De= leting=C2=A0the PM_STARTUP ExitPostmaster(1) shortcut, and letting executio= n fall through to the next stanza.

2. Replacing th= e Assert(false) for PM_STARTUP in HandleFatalError() with a fall-through to= UpdatePMState(PM_WAIT_BACKENDS).=C2=A0

Verification that I d= id for patch:=C2=A0

On a fresh initdb'd=C2=A0cluster,= I zeroed=C2=A0out the first WAL segment to force the startup process to FA= TAL at StartupXLOG, then ran PG in foreground under strace.

Befor= e (master):
=C2=A0 LOG:=C2=A0 startup process (PID N) exited with exit code 1
=C2=A0 LOG:=C2=A0 aborting startup due to startup process failure
=C2=A0 LOG:=C2=A0 database system is shut down

=C2=A0 strace of the p= ostmaster PID shows 0 kill() calls to children before
=C2=A0 exit_group(1). Checkpointer, bgwriter and io workers were running at=
=C2=A0 the time of the failure and were orphaned.


After (p= atched):
=C2=A0 LOG:=C2=A0 startup process (PID N) exited with exit code 1
=C2=A0 LOG:=C2=A0 terminating any other active server processes
<stat= e transitions PM_STARTUP -> PM_WAIT_BACKENDS -> PM_WAIT_DEAD_END
=C2=A0=C2=A0 -> PM_NO_CHILDREN>
=C2=A0 LOG:=C2=A0 shutting down due to startup process failure
=C2=A0 LOG:=C2=A0 database system is shut down

=C2=A0 strace = shows 8 SIGQUIT deliveries (4 children, each signaled by PID
=C2=A0 and by process-group) before the postmaster's own exit_group(1).=

I've attached a patch, please review and let me know your thoug= hts.

Regards,
Ayush

--000000000000a53277064fa83095-- --000000000000a53278064fa83097 Content-Type: application/octet-stream; name="0001-postmaster-drain-aux-processes-on-startup-process-fa.patch" Content-Disposition: attachment; filename="0001-postmaster-drain-aux-processes-on-startup-process-fa.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mo2yn1ko0 RnJvbSA2MjY3YTQxNmNjNzczY2M4OGZlMTczMjI5MDg5NjExMjg3NjRjMjU0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBeXVzaCBUaXdhcmkgPGF5dXNodGl3YXJpLnNsZzAxQGdtYWls LmNvbT4KRGF0ZTogRnJpLCAxNyBBcHIgMjAyNiAxODo0OTozNCArMDUzMApTdWJqZWN0OiBbUEFU Q0hdIHBvc3RtYXN0ZXI6IGRyYWluIGF1eCBwcm9jZXNzZXMgb24gc3RhcnR1cC1wcm9jZXNzIGZh aWx1cmUKIGR1cmluZyBQTV9TVEFSVFVQCgpXaGVuIHRoZSBzdGFydHVwIHByb2Nlc3MgZXhpdHMg d2l0aCBhIG5vbi16ZXJvIHN0YXR1cyBkdXJpbmcgUE1fU1RBUlRVUCwKdGhlIHBvc3RtYXN0ZXIg Y2FsbGVkIEV4aXRQb3N0bWFzdGVyKDEpIGltbWVkaWF0ZWx5LiBCdXQgYnkgdGhlIHRpbWUKUE1f U1RBUlRVUCBpcyBhY3RpdmUsIGNoZWNrcG9pbnRlciwgYmd3cml0ZXIsIGlvIHdvcmtlcnMsIGFu ZApCZ1dvcmtlclN0YXJ0X1Bvc3RtYXN0ZXJTdGFydCBiYWNrZ3JvdW5kIHdvcmtlcnMgbWF5IGFs cmVhZHkgYmUgcnVubmluZy4KRXhpdGluZyBpbW1lZGlhdGVseSBvcnBoYW5lZCB0aGVtLgoKUm91 dGUgdGhpcyBwYXRoIHRocm91Z2ggdGhlIGV4aXN0aW5nIGNyYXNoLWhhbmRsaW5nIG1hY2hpbmVy eTogZmFsbAp0aHJvdWdoIHRvIHRoZSBmb2xsb3dpbmcgc3RhbnphIHdoaWNoIHNldHMgU3RhcnR1 cFN0YXR1cyA9IFNUQVJUVVBfQ1JBU0hFRAphbmQgY2FsbHMgSGFuZGxlQ2hpbGRDcmFzaCgpLCBj YXVzaW5nIEhhbmRsZUZhdGFsRXJyb3IoKSB0byBTSUdRVUlUIHRoZQphdXggY2hpbGRyZW4gYW5k IHRyYW5zaXRpb24gdG8gUE1fV0FJVF9CQUNLRU5EUy4gVGhlIHN0YXRlIG1hY2hpbmUgdGhlbgpk cmFpbnMgdGhyb3VnaCBQTV9XQUlUX0RFQURfRU5EIHRvIFBNX05PX0NISUxEUkVOLCB3aGVyZSB0 aGUgZXhpc3RpbmcKU1RBUlRVUF9DUkFTSEVEIGNoZWNrIGxvZ3MgJ3NodXR0aW5nIGRvd24gZHVl IHRvIHN0YXJ0dXAgcHJvY2VzcyBmYWlsdXJlJwphbmQgY2FsbHMgRXhpdFBvc3RtYXN0ZXIoMSku CgpBbHNvIHJlcGxhY2UgdGhlIEFzc2VydChmYWxzZSkgZm9yIFBNX1NUQVJUVVAgaW4gSGFuZGxl RmF0YWxFcnJvcigpIHdpdGgKYSB0cmFuc2l0aW9uIHRvIFBNX1dBSVRfQkFDS0VORFMuIFRoZSBh c3NlcnQgd2FzIGEgbGF0ZW50IGJ1ZzogYW55IGF1eApwcm9jZXNzIGNyYXNoIGR1cmluZyBQTV9T VEFSVFVQIChub3QganVzdCBzdGFydHVwLXByb2Nlc3MgZmFpbHVyZSkgd291bGQKcmVhY2ggaXQg dmlhIEhhbmRsZUNoaWxkQ3Jhc2ggLT4gSGFuZGxlRmF0YWxFcnJvci4KLS0tCiBzcmMvYmFja2Vu ZC9wb3N0bWFzdGVyL3Bvc3RtYXN0ZXIuYyB8IDI5ICsrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCiAxIGZpbGUgY2hhbmdlZCwgNSBpbnNlcnRpb25zKCspLCAyNCBkZWxldGlvbnMoLSkKCmRp ZmYgLS1naXQgYS9zcmMvYmFja2VuZC9wb3N0bWFzdGVyL3Bvc3RtYXN0ZXIuYyBiL3NyYy9iYWNr ZW5kL3Bvc3RtYXN0ZXIvcG9zdG1hc3Rlci5jCmluZGV4IGI2ZmQzMzJmMTk2Li4wMWRmMGY2MzRl MyAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvcG9zdG1hc3Rlci9wb3N0bWFzdGVyLmMKKysrIGIv c3JjL2JhY2tlbmQvcG9zdG1hc3Rlci9wb3N0bWFzdGVyLmMKQEAgLTIzMDUsMjYgKzIzMDUsMTAg QEAgcHJvY2Vzc19wbV9jaGlsZF9leGl0KHZvaWQpCiAJCQl9CiAKIAkJCS8qCi0JCQkgKiBVbmV4 cGVjdGVkIGV4aXQgb2Ygc3RhcnR1cCBwcm9jZXNzIChpbmNsdWRpbmcgRkFUQUwgZXhpdCkKLQkJ CSAqIGR1cmluZyBQTV9TVEFSVFVQIGlzIHRyZWF0ZWQgYXMgY2F0YXN0cm9waGljLiBUaGVyZSBh cmUgbm8KLQkJCSAqIG90aGVyIHByb2Nlc3NlcyBydW5uaW5nIHlldCwgc28gd2UgY2FuIGp1c3Qg ZXhpdC4KLQkJCSAqLwotCQkJaWYgKHBtU3RhdGUgPT0gUE1fU1RBUlRVUCAmJgotCQkJCVN0YXJ0 dXBTdGF0dXMgIT0gU1RBUlRVUF9TSUdOQUxFRCAmJgotCQkJCSFFWElUX1NUQVRVU18wKGV4aXRz dGF0dXMpKQotCQkJewotCQkJCUxvZ0NoaWxkRXhpdChMT0csIF8oInN0YXJ0dXAgcHJvY2VzcyIp LAotCQkJCQkJCSBwaWQsIGV4aXRzdGF0dXMpOwotCQkJCWVyZXBvcnQoTE9HLAotCQkJCQkJKGVy cm1zZygiYWJvcnRpbmcgc3RhcnR1cCBkdWUgdG8gc3RhcnR1cCBwcm9jZXNzIGZhaWx1cmUiKSkp OwotCQkJCUV4aXRQb3N0bWFzdGVyKDEpOwotCQkJfQotCi0JCQkvKgotCQkJICogQWZ0ZXIgUE1f U1RBUlRVUCwgYW55IHVuZXhwZWN0ZWQgZXhpdCAoaW5jbHVkaW5nIEZBVEFMIGV4aXQpIG9mCi0J CQkgKiB0aGUgc3RhcnR1cCBwcm9jZXNzIGlzIGNhdGFzdHJvcGhpYywgc28ga2lsbCBvdGhlciBj aGlsZHJlbiwKLQkJCSAqIGFuZCBzZXQgU3RhcnR1cFN0YXR1cyBzbyB3ZSBkb24ndCB0cnkgdG8g cmVpbml0aWFsaXplIGFmdGVyCi0JCQkgKiB0aGV5J3JlIGdvbmUuICBFeGNlcHRpb246IGlmIFN0 YXJ0dXBTdGF0dXMgaXMgU1RBUlRVUF9TSUdOQUxFRCwKKwkJCSAqIEFueSB1bmV4cGVjdGVkIGV4 aXQgKGluY2x1ZGluZyBGQVRBTCBleGl0KSBvZiB0aGUgc3RhcnR1cAorCQkJICogcHJvY2VzcyBp cyBjYXRhc3Ryb3BoaWMsIHNvIGtpbGwgb3RoZXIgY2hpbGRyZW4sIGFuZCBzZXQKKwkJCSAqIFN0 YXJ0dXBTdGF0dXMgc28gd2UgZG9uJ3QgdHJ5IHRvIHJlaW5pdGlhbGl6ZSBhZnRlciB0aGV5J3Jl CisJCQkgKiBnb25lLiAgRXhjZXB0aW9uOiBpZiBTdGFydHVwU3RhdHVzIGlzIFNUQVJUVVBfU0lH TkFMRUQsCiAJCQkgKiB0aGVuIHdlIHByZXZpb3VzbHkgc2VudCB0aGUgc3RhcnR1cCBwcm9jZXNz IGEgU0lHUVVJVDsgc28KIAkJCSAqIHRoYXQncyBwcm9iYWJseSB0aGUgcmVhc29uIGl0IGRpZWQs IGFuZCB3ZSBkbyB3YW50IHRvIHRyeSB0bwogCQkJICogcmVzdGFydCBpbiB0aGF0IGNhc2UuCkBA IC0yNzgwLDEyICsyNzY0LDkgQEAgSGFuZGxlRmF0YWxFcnJvcihRdWl0U2lnbmFsUmVhc29uIHJl YXNvbiwgYm9vbCBjb25zaWRlcl9zaWdhYnJ0KQogCQkJLyogc2hvdWxkbid0IGhhdmUgYW55IGNo aWxkcmVuICovCiAJCQlBc3NlcnQoZmFsc2UpOwogCQkJYnJlYWs7Ci0JCWNhc2UgUE1fU1RBUlRV UDoKLQkJCS8qIHNob3VsZCBoYXZlIGJlZW4gaGFuZGxlZCBpbiBwcm9jZXNzX3BtX2NoaWxkX2V4 aXQgKi8KLQkJCUFzc2VydChmYWxzZSk7Ci0JCQlicmVhazsKIAogCQkJLyogd2FpdCBmb3IgY2hp bGRyZW4gdG8gZGllICovCisJCWNhc2UgUE1fU1RBUlRVUDoKIAkJY2FzZSBQTV9SRUNPVkVSWToK IAkJY2FzZSBQTV9IT1RfU1RBTkRCWToKIAkJY2FzZSBQTV9SVU46Ci0tIAoyLjM0LjEKCg== --000000000000a53278064fa83097--