Skip site navigation (1) Skip section navigation (2)

Re: User functions and AIX

From: darcy(at)druid(dot)net (D'Arcy J(dot)M(dot) Cain)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: User functions and AIX
Date: 2001-05-28 21:04:52
Message-ID: 20010528210452.787A91A8D@druid.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Thus spake Tom Lane
> darcy(at)druid(dot)net (D'Arcy J.M. Cain) writes:
> > I'm also not sure why these functions are involved
> > in reading the chkpass type.
> 
> Precisely my point: they're not.  That backtrace is false data.
> 
> > Hmm.  I just rebooted and reran the test (SELECT 'hello'::chkpass) and
> > it gave me a different stacktrace.  It looks like this.
> 
> > #0  0x0 in ?? () from (unknown load module)
> > #1  0xd1085a60 in chkpass_in (fcinfo=0x0) at chkpass.c:88
> > #2  0x1004b874 in OidFunctionCall3 (functionId=269952520, arg1=269952532, 
> >     arg2=269952540, arg3=269952548) at fmgr.c:1136
> > #3  0x1007f350 in stringTypeDatum (tp=0x10172694, string=0x101726a0 "pendant", 
> >     atttypmod=269952680) at parse_type.c:181
> > #4  0x10060630 in parser_typecast_constant (expr=0x10172794, 
> >     typename=0x101727a0) at parse_expr.c:876
> 
> This one I believe to the extent of the series of function calls, but
> it's still giving you wrong info about the passed parameters, which
> is pretty common if you compiled at -O2 or higher.  Try recompiling with
> "-O0 -g" if you need trustworthy parameter info from the backtrace.

Is that an AIX thing?  I generally get reasonable traces on NetBSD.

Anyway, I took your advice and now I get this.

#0  0x0 in ?? () from (unknown load module)
#1  0xd1085aac in chkpass_in (fcinfo=0x2ff1dcb8) at chkpass.c:88
#2  0x1004b874 in OidFunctionCall3 (functionId=269952520, arg1=269952532, 
    arg2=269952540, arg3=269952548) at fmgr.c:1136
#3  0x1007f350 in stringTypeDatum (tp=0x10172694, string=0x101726a0 "pendant", 
    atttypmod=269952680) at parse_type.c:181
#4  0x10060630 in parser_typecast_constant (expr=0x10172794, 
    typename=0x101727a0) at parse_expr.c:876
#5  0x10061188 in transformExpr (pstate=0x10172910, expr=0x10172920, 
    precedence=269953332) at parse_expr.c:118
#6  0x10076f28 in transformTargetEntry (pstate=0x258, node=0x5c, 
    expr=0x2ff1df70, colname=0x101729f4 "inner", resjunk=16 '\020')
    at parse_target.c:56
#7  0x10077198 in transformTargetList (pstate=0x10172ab8, 
    targetlist=0x10172ac0) at parse_target.c:158
#8  0x10093c10 in transformSelectStmt (pstate=0x10172b80, stmt=0x10172b88)
    at analyze.c:1835
#9  0x1009497c in transformStmt (pstate=0x20000890, parseTree=0x2001f43c)
    at analyze.c:226
#10 0x10094ca4 in parse_analyze (parseTree=0x100195f8, 
    parentParseState=0x200008a4) at analyze.c:86

Looking better.  It still seems to be the same error I saw to start with
though.  It seems that the loaded dynamic object can't find the address
for palloc() and so jumps to 0.  I'm sure that it is an AIX thing but
even IBM can't seem to find the problem.

-- 
D'Arcy J.M. Cain <darcy(at){druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-05-28 21:11:53
Subject: Re: [INTERFACES] remote database queries
Previous:From: Tom LaneDate: 2001-05-28 19:59:43
Subject: Re: Re: charin(), text_char() should return something else for empty input

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group