Re: upper() problem in 7.0.2

From: "Christopher L(dot) Cousins" <chris(at)impulse(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Christopher L(dot) Cousins" <chris(at)impulse(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: upper() problem in 7.0.2
Date: 2000-07-06 01:04:08
Message-ID: 20000705180408.A21120@cobalt.impulse.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jul 05, 2000 at 12:03:46PM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <chris(at)impulse(dot)net> writes:
> > Using PHP4 or PHP3, the following query will ~sometimes~ cause the
> > backend to terminate. It depends the value of $searchstr and appears
> > (to me anyway) to be random. A $searchstr that causes the backend to
> > crash right now may work just fine in a few hours.
>
> > The same query issued through psql will not cause the backend to crash.
>
> > For both interfaces (psql and PHP4) the query logged (debug) is the same.
>
> That's really odd. Since you don't have a reproducible example, we'll
> have to ask you to do some more digging. Would you build the backend
> with -g, and then next time you see the problem get a stack backtrace
> from the core file left by the crashed backend?

I have been able to make the backend crash using psql. I also took a dump
of the database while I had some known values that would trigger the problem.
Because of this, I can now reload the dump (to a dummy database) at any time to
reproduce the problem.

I had to attach to the running process to get a backtrace (the core file was
too large to be written to the disk, took me a while to figure that out).

I then issued the following query using psql.
SELECT * FROM tblUser
WHERE upper(tblUser.username) LIKE upper('%asdf%')
OR upper(tblUser.gecos)
LIKE upper('%asdf%');

postgres(at)cobalt% gdb
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd2.7".
(gdb) file postgres
Reading symbols from postgres...done.
(gdb) attach 9740
Attaching to program `/usr/local/pgsql/bin/postgres', process 9740
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /usr/lib/libm.so.0.1...done.
Reading symbols from /usr/lib/libutil.so.4.5...done.
Reading symbols from /usr/lib/libtermcap.so.7.1...done.
Reading symbols from /usr/lib/libcurses.so.7.1...done.
Reading symbols from /usr/lib/libc.so.25.0...done.
0x40211fe3 in _thread_sys_nanosleep ()
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xdfbfd638 in ?? (): No such file or directory.
(gdb) bt
#0 0xdfbfd638 in ?? ()"/bin/": not in executable format: File truncated.
(gdb) bt
#0 0xdfbfd638 in ?? (): No such file or directory.
(gdb) up
#1 0x10000 in rtbuild (heap=0x1, index=0x1, natts=1, attnum=0x1, istrat=0x1, pcount=1, params=0x1, finfo=0x1,
predInfo=0x1) at rtree.c:114
114 buffer = ReadBuffer(index, P_NEW);
(gdb) up
#2 0x1 in ?? () from /usr/lib/libc.so.25.0

--

--Chris

____
Impulse Internet Services / \
____________________________/ \_____

http://www.impulse.net <chris(at)impulse(dot)net>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2000-07-06 04:48:53 Re: upper() problem in 7.0.2
Previous Message Tom Lane 2000-07-05 17:21:27 Re: problem with union and outer join using a view