From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: hirose.masay-01@jp.fujitsu.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17421: Core dump in ECPGdo() when calling PostgreSQL API
 from 32-bit client for RHEL8
In-reply-to: <YhtsqXFtjC86HdeM@paquier.xyz>
References: <17421-790ff887e3188874@postgresql.org>
 <YhtsqXFtjC86HdeM@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Sun, 27 Feb 2022 21:20:57 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2360629.1645979458.1@sss.pgh.pa.us>
Date: Sun, 27 Feb 2022 11:30:58 -0500
Message-ID: <2360630.1645979458@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2360630.1645979458%40sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> Hm.  Could you isolate that in a self-contained test case?  Based on
> this trace, it looks like "message" is NULL, which may be possible
> because pqInternalNotice() missed something?  I would not bet on
> errorMessage being NULL, but there may be holes..

Yeah.  It seems likely that this is a longstanding ecpglib bug
that was previously masked by platform snprintfs not crashing
on printf("%s", NULL).  If so, it's masked again in 12.8 and
later (cf 3779ac62d), but it's still a bug in that ecpg won't
print anything useful when this edge condition --- whatever it
is --- happens.  So, could we see a test case?

			regards, tom lane