Re: User functions and AIX

Поиск
Список
Период
Сортировка
От darcy@druid.net (D'Arcy J.M. Cain)
Тема Re: User functions and AIX
Дата
Msg-id 20010528210452.787A91A8D@druid.net
обсуждение исходный текст
Ответ на Re: User functions and AIX  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Thus spake Tom Lane
> darcy@druid.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@{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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: charin(), text_char() should return something else for empty input
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [INTERFACES] remote database queries