pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org, Aleksander Alekseev <aleksander@timescale.com>
Cc: dhyan@nataraj.su
Subject: Re: BUG #18708: regex problem: (?:[^\d\D]){0} asserts with "lp->nouts == 0 && rp->nins == 0"
Date: Sun, 17 Nov 2024 01:26:38 -0500
Message-ID: <2988928.1731824798@sss.pgh.pa.us> (raw)
In-Reply-To: <2958975.1731817729@sss.pgh.pa.us>
References: <18708-f94f2599c9d2c005@postgresql.org>
	<CAJ7c6TMPSrcbzkX0ePnNTbh7M22hRiPfD0KOcW4L9YjdbnF0Ug@mail.gmail.com>
	<2242483.1731627374@sss.pgh.pa.us>
	<2344149.1731636867@sss.pgh.pa.us>
	<CAJ7c6TMXLaoBB6GmgkkSRH_WoLxqSU_K6ORnw9rP+3JexuKSMQ@mail.gmail.com>
	<CAJ7c6TP+0MHu7t3QDdXHMf1DW9r56qnyr_7NsTQOB5+pKQEkcg@mail.gmail.com>
	<2631851.1731715737@sss.pgh.pa.us>
	<661fd81b-f069-8f30-1a41-e195c57449b4@gmail.com>
	<2745175.1731772978@sss.pgh.pa.us>
	<7dd96d86-bac0-4879-2555-276d2ef4a8db@gmail.com>
	<2958975.1731817729@sss.pgh.pa.us>

I wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> (Un)fortunately, tern (which is also a ppc animal) has produced the same
>> failure:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2024-11-16%2022%3A00%3A12

> Yeah, I saw that.  Even more confused now about what it could be.

After testing on hornet's host, it seems that this is a pre-existing
issue that we didn't happen to hit before.  Since the regex
'[^\d\D]' is unsatisfiable, it collapses to nothing (start state,
end state, and no arcs) in the first cleanup() call in optimize().
Then fixempties() counts the number of in-arcs and gets zero,
and then it does

	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;

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.

			regards, tom lane





view thread (16+ messages)  latest in thread

Message-ID: <2988928.1731824798@sss.pgh.pa.us>
Permalink:  ../2988928.1731824798@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2988928.1731824798@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, exclusion@gmail.com, aleksander@timescale.com, dhyan@nataraj.su
  Subject: Re: BUG #18708: regex problem: (?:[^\d\D]){0} asserts with "lp->nouts == 0 && rp->nins == 0"
  In-Reply-To: <2988928.1731824798@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox