Horton

Re: BUG #18708: regex problem: (?:[^\d\D]){0} asserts with "lp->nouts == 0 && rp->nins == 0"

Noah Misch <noah@leadboat.com>

View thread View on postgr.es
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-bugs@lists.postgresql.org, Aleksander Alekseev <aleksander@timescale.com>, dhyan@nataraj.su
Date: 2024-11-17T16:12:10Z
Lists: pgsql-bugs 
On Sun, Nov 17, 2024 at 01:26:38AM -0500, Tom Lane wrote:
> 	arcarray = (struct arc **) MALLOC(totalinarcs * sizeof(struct arc *));
> 	if (arcarray == NULL)
> 	{
> 		NERR(REG_ESPACE);
> 		...
> 
> On a machine where malloc(0) returns NULL, this mistakenly
> thinks that's an error.
> 
> I verified that
> 
> -	if (arcarray == NULL)
> +	if (arcarray == NULL && totalinarcs != 0)
> 
> makes the failure go away, but I wonder if any other places in
> backend/regex/ are at the same hazard.  Maybe the smartest fix
> would be to put in a wrapper layer that does what pg_malloc
> does:
> 
> 	/* Avoid unportable behavior of malloc(0) */
> 	if (size == 0)
> 		size = 1;

Either of those sound reasonable.  The consequence of missing this hazard, a
deterministic ERROR, is modest.  This affects just one platform, in the oldest
branches.  There's a lack of complaints.  To me, all that would make the
one-line diff tempting.

> One other point is that this theory fails to explain why
> hornet didn't fail in the v16 branch ... oh, wait:
> v15 has 
> 
> #define MALLOC(n)		malloc(n)
> 
> where later branches have
> 
> #define MALLOC(n)		palloc_extended((n), MCXT_ALLOC_NO_OOM)
> 
> So the right answer seems to be to figure out why we didn't
> back-patch that change.

I don't recall a specific reason or see one in the discussion of commit
bea3d7e38.  It was done mainly to unblock commit db4f21e, which in turn
unblocked commit 0da096d.  The last commit is heavy, so I can understand it
skipping the back branches.  If I were making a (weak) argument against
back-patching bea3d7e38, I might cite the extra memory use from
RegexpCacheMemoryContext and children.

Commits

  1. Fix recently-exposed portability issue in regex optimization.

  2. Avoid assertion due to disconnected NFA sub-graphs in regex parsing.

  3. Fix recovery conflict SIGUSR1 handling.

  4. Redesign interrupt/cancel API for regex engine.

  5. Use MemoryContext API for regex memory management.

  6. Invent "rainbow" arcs within the regex engine.