Thread: 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 abnormallyand possibly corrupted shared memory. I have rolled back the current transaction and am going to terminateyour 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@nooper.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@nooper.com - http://nooper.com
Attachment
"Thomas O'Dowd" <tom@nooper.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@nooper.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@nooper.com - http://nooper.com
"Thomas O'Dowd" <tom@nooper.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