The killer query was:
select crsids.surname,"tblPerson"."Surname" from crsids,"tblPerson" where crsids.usn="tblPerson"."USN"::int4;
and the reason for the SIGSEGV, is that somehow, text_int4(text *string) in
src/backend/utils/adt/int.c is called with string=(text *)0x0, so obviously
this is a problem!
crsids.usn is integer, "tblPerson"."USN" is varchar(9).
Oddly enough, text_int4 is called from fmgr.c:136 which is in the case
statement for n_arguments=2, yet that should be 1
(gdb) print {FmgrInfo}0x8221a30
$4 = {fn_addr = 0x80f9dbc <text_int4>, fn_plhandler = 0, fn_oid = 1620, fn_nargs = 1}
unless gdb is reporting the wrong line number. values->data[0]=0=string.
I have a backtrace and a pretty printed copy of the query tree if useful...
Still trying to make a small test case...
Any suggestions appreciated!
Cheers,
Patrick
(source of 31st Jan)
On Sat, Feb 05, 2000 at 12:18:29PM -0500, Tom Lane wrote:
> Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> >> Is there anything in the postmaster log?
>
> > DEBUG: Data Base System is in production state at Fri Feb 4 17:11:05 2000
> > Server process (pid 3588) exited with status 11 at Fri Feb 4 17:14:57 2000
>
> > But no core file ... so who knows what the sigsegv comes from. (don't worry
> > coredumpsize unlimited)
>
> There sure oughta be a corefile after a SIGSEGV. Hmm. How are you
> starting the postmaster --- is it from a system startup script?
> It might work better to start it from an ordinary user process.
> I discovered the other day on a Linux box that the system just plain
> would not dump a core file from a process started by root, even though
> the process definitely had nonzero "ulimit -c" and had set its euid
> to a nonprivileged userid. But start the same process by hand from an
> unprivileged login, and it would dump a core file. Weird. Dunno if
> your platform behaves the same way, but it's worth trying.
>
> regards, tom lane