pg 7.3.2 assert statement fails. process terminated

Hi all,

PostgreSQL 7.3.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2
20020903 (Red Hat Linux 8.0 3.2-7)

One of the backends died on me with the following in the logfile...

er 127.0.0.1 SELECT: regcomp.c:331: p_ere: Assertion `!(p->next <
p->end) || ((p->next < p->end) && (*p->next) == (stop))' failed.
LOG: server process (pid 8868) was terminated by signal 6
LOG: terminating any other active server processes
WARNING: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend
died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am
going to terminate your database system connection and exit.

There is nothing before the "er 127.0.0.1" except previous older log
entries.

I'm going to try turn on some more logging to see if I can see what the
problem is. Any pointers? Known bug?

Tom.
--
Thomas O'Dowd - Got a keitai? Get Nooped!
tom(at)nooper(dot)com - http://nooper.com

Hi again,

I managed to narrow the crash down to a small regex. The database I'm
using is UTF-8 and the regex is encoded in EUC_JP. I'm attaching a
gzipped file so that the encoding information doesn't get lost somehow
in email. You should be able to gunzip the file and load the file with
either psql -f filename or using \i filename.

Is this a new bug? See attached.

Tom.

On Fri, 2003-04-18 at 11:08, Thomas O'Dowd wrote:
> Hi all,
>
> PostgreSQL 7.3.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2
> 20020903 (Red Hat Linux 8.0 3.2-7)
>
> One of the backends died on me with the following in the logfile...
>
> er 127.0.0.1 SELECT: regcomp.c:331: p_ere: Assertion `!(p->next <
> p->end) || ((p->next < p->end) && (*p->next) == (stop))' failed.
> LOG: server process (pid 8868) was terminated by signal 6
> LOG: terminating any other active server processes
> WARNING: Message from PostgreSQL backend:
> The Postmaster has informed me that some other backend
> died abnormally and possibly corrupted shared memory.
> I have rolled back the current transaction and am
> going to terminate your database system connection and exit.
>
> There is nothing before the "er 127.0.0.1" except previous older log
> entries.
>
> I'm going to try turn on some more logging to see if I can see what the
> problem is. Any pointers? Known bug?
>
> Tom.
--
Thomas O'Dowd - Got a keitai? Get Nooped!
tom(at)nooper(dot)com - http://nooper.com

"Thomas O'Dowd" <tom(at)nooper(dot)com> writes:
> I managed to narrow the crash down to a small regex. The database I'm
> using is UTF-8 and the regex is encoded in EUC_JP.

I'm wondering whether "char c" in p_ere() shouldn't be "pg_wchar c".

> Is this a new bug?

Hardly, that code didn't change in ages. (Until we replaced it all
a month or two back; but that's not in 7.3.*.)

regards, tom lane

Tom,

On Fri, 2003-04-18 at 15:03, Tom Lane wrote:
> "Thomas O'Dowd" <tom(at)nooper(dot)com> writes:
> > I managed to narrow the crash down to a small regex. The database I'm
> > using is UTF-8 and the regex is encoded in EUC_JP.
>
> I'm wondering whether "char c" in p_ere() shouldn't be "pg_wchar c".

Thanks. I just tried this and it seems to solve the problem. How do I
run regression tests on the regex stuff to ensure it doesn't break
anything else?

Tom.
--
Thomas O'Dowd - Got a keitai? Get Nooped!
tom(at)nooper(dot)com - http://nooper.com

"Thomas O'Dowd" <tom(at)nooper(dot)com> writes:
> On Fri, 2003-04-18 at 15:03, Tom Lane wrote:
>> I'm wondering whether "char c" in p_ere() shouldn't be "pg_wchar c".

> Thanks. I just tried this and it seems to solve the problem.

Okay, I've applied this patch to the REL7_3 branch (it's not relevant to
CVS tip anymore, though). Should be in 7.3.3, whenever we get around to
releasing that.

regards, tom lane