Re: [HACKERS] Another nasty cache problem

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(at)newn(dot)cam(dot)ac(dot)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