use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)

Поиск
Список
Период
Сортировка
От Frank van Vugt
Тема use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)
Дата
Msg-id 200411270138.13700.ftm.van.vugt@foxi.nl
обсуждение исходный текст
Ответы Re: use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
L.S.

I've been using a certain pgsql function (IMMUTABLE/STRICT) happily in v7.4.6,
but when trying out v8.0.0beta5 the exact same function causes the backend to
segfault.

(Further examination revealed that a simple 'select initcap('f')' is enough to
bring the backend down......)


db=# select version();
                                 version
--------------------------------------------------------------------------
 PostgreSQL 8.0.0beta5 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66


Since this probably has to do with the db encoding, both versions of pgsql
were initdb'd using UNICODE and no-locale.

# uname -a
Linux gatefox 2.2.16 #15 Wed Feb 12 12:14:42 CET 2003 i686 unknown
(yes, fairly old, I know....)


db=# update article set full_descr = full_article_descr(id);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

OR

db=# select initcap('f');
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.



LOG:  server process (PID 31890) was terminated by signal 11
LOG:  terminating any other active server processes
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted at 2004-11-26 23:48:26 CET
LOG:  checkpoint record is at 0/2F7C3C50
LOG:  redo record is at 0/2F7C3C50; undo record is at 0/0; shutdown TRUE
LOG:  next transaction ID: 37413; next OID: 1929207
LOG:  database system was not properly shut down; automatic recovery in
progress
LOG:  record with zero length at 0/2F7C3C8C
LOG:  redo is not required
LOG:  database system is ready



(gdb) where
#0  0x4016e501 in towupper () from /lib/libc.so.6
#1  0x81a45e2 in initcap (fcinfo=0xbfffdfdc) at oracle_compat.c:312
#2  0x8110ca1 in ExecMakeFunctionResult (fcache=0x8374fe0, econtext=0x837420c,
isNull=0xbfffe1c5 "", isDone=0xbfffe0e4) at execQual.c:1038
#3  0x8111401 in ExecEvalFunc (fcache=0x8374fe0, econtext=0x837420c,
isNull=0xbfffe1c5 "", isDone=0xbfffe0e4) at execQual.c:1455
#4  0x81108cc in ExecEvalFuncArgs (fcinfo=0xbfffe134, argList=0x8374fc4,
econtext=0x837420c) at execQual.c:795
#5  0x81109c1 in ExecMakeFunctionResult (fcache=0x8374e6c, econtext=0x837420c,
isNull=0xbfffe31c "", isDone=0xbfffe23c) at execQual.c:856
#6  0x811143d in ExecEvalOper (fcache=0x8374e6c, econtext=0x837420c,
isNull=0xbfffe31c "", isDone=0xbfffe23c) at execQual.c:1477
#7  0x81108cc in ExecEvalFuncArgs (fcinfo=0xbfffe28c, argList=0x837529c,
econtext=0x837420c) at execQual.c:795
#8  0x81109c1 in ExecMakeFunctionResult (fcache=0x8374d60, econtext=0x837420c,
isNull=0xbfffe474 "", isDone=0xbfffe394) at execQual.c:856
#9  0x811143d in ExecEvalOper (fcache=0x8374d60, econtext=0x837420c,
isNull=0xbfffe474 "", isDone=0xbfffe394) at execQual.c:1477
#10 0x81108cc in ExecEvalFuncArgs (fcinfo=0xbfffe3e4, argList=0x8375574,
econtext=0x837420c) at execQual.c:795
#11 0x81109c1 in ExecMakeFunctionResult (fcache=0x8374c54, econtext=0x837420c,
isNull=0xbfffe577 "", isDone=0x0) at execQual.c:856
#12 0x811143d in ExecEvalOper (fcache=0x8374c54, econtext=0x837420c,
isNull=0xbfffe577 "", isDone=0x0) at execQual.c:1477
#13 0x8112bad in ExecEvalExprSwitchContext (expression=0x8374c54,
econtext=0x837420c, isNull=0xbfffe577 "", isDone=0x0) at execQual.c:2708
#14 0x4148247b in exec_eval_simple_expr (estate=0xbfffe700, expr=0x833c9f0,
isNull=0xbfffe577 "", rettype=0xbfffe578) at pl_exec.c:3635
#15 0x41481f5d in exec_eval_expr (estate=0xbfffe700, expr=0x833c9f0,
isNull=0xbfffe577 "", rettype=0xbfffe578) at pl_exec.c:3418
#16 0x414811a1 in exec_assign_expr (estate=0xbfffe700, target=0x836a954,
expr=0x833c9f0) at pl_exec.c:2801
#17 0x4147ef7e in exec_stmt_assign (estate=0xbfffe700, stmt=0x833ca78) at
pl_exec.c:1143
#18 0x4147ed7e in exec_stmt (estate=0xbfffe700, stmt=0x833ca78) at
pl_exec.c:1047
#19 0x4147ec9f in exec_stmts (estate=0xbfffe700, stmts=0x8352080) at
pl_exec.c:1015
#20 0x4147ebdf in exec_stmt_block (estate=0xbfffe700, block=0x836d828) at
pl_exec.c:970
#21 0x4147df03 in plpgsql_exec_function (func=0x832c980, fcinfo=0xbfffe7b8) at
pl_exec.c:336
#22 0x4147af9b in plpgsql_call_handler (fcinfo=0xbfffe7b8) at pl_handler.c:127
#23 0x8110ca1 in ExecMakeFunctionResult (fcache=0x8356ffc, econtext=0x8356de0,
isNull=0xbfffe9a0 "", isDone=0xbfffe8c0) at execQual.c:1038
#24 0x8111401 in ExecEvalFunc (fcache=0x8356ffc, econtext=0x8356de0,
isNull=0xbfffe9a0 "", isDone=0xbfffe8c0) at execQual.c:1455
#25 0x81108cc in ExecEvalFuncArgs (fcinfo=0xbfffe910, argList=0x8357140,
econtext=0x8356de0) at execQual.c:795
#26 0x81109c1 in ExecMakeFunctionResult (fcache=0x8356ef0, econtext=0x8356de0,
isNull=0xbfffea27 "", isDone=0x83598e0) at execQual.c:856
#27 0x8111401 in ExecEvalFunc (fcache=0x8356ef0, econtext=0x8356de0,
isNull=0xbfffea27 "", isDone=0x83598e0) at execQual.c:1455
#28 0x811399b in ExecTargetList (targetlist=0x8356e80, targettype=0x8357e9c,
econtext=0x8356de0, values=0x83597cc,
    nulls=0x83583c4 "  ", '\177' <repeats 41 times>, "~", '\177' <repeats 20
times>, "P\2045\b@", itemIsDone=0x83598d8, isDone=0xbfffea70)
    at execQual.c:3433
#29 0x8113ba0 in ExecProject (projInfo=0x8358508, isDone=0xbfffea70) at
execQual.c:3579
#30 0x8113c92 in ExecScan (node=0x8356d54, accessMtd=0x811b42c <SeqNext>) at
execScan.c:142
#31 0x811b4cc in ExecSeqScan (node=0x8356d54) at nodeSeqscan.c:139
#32 0x810f8ca in ExecProcNode (node=0x8356d54) at execProcnode.c:303
#33 0x810e893 in ExecutePlan (estate=0x834d70c, planstate=0x8356d54,
operation=CMD_UPDATE, numberTuples=0, direction=ForwardScanDirection,
dest=0x8343d14)
    at execMain.c:1060
#34 0x810dac9 in ExecutorRun (queryDesc=0x834d330,
direction=ForwardScanDirection, count=0) at execMain.c:226
#35 0x817a24c in ProcessQuery (parsetree=0x8326c48, plan=0x8328634,
params=0x0, dest=0x8343d14, completionTag=0xbfffecfc "") at pquery.c:173
#36 0x817b063 in PortalRunMulti (portal=0x83525d4, dest=0x8343d14,
altdest=0x8343d14, completionTag=0xbfffecfc "") at pquery.c:1023
#37 0x817a9d5 in PortalRun (portal=0x83525d4, count=2147483647,
dest=0x8343d14, altdest=0x8343d14, completionTag=0xbfffecfc "") at
pquery.c:617
#38 0x8177656 in exec_simple_query (query_string=0x832672c "update article set
full_descr = full_article_descr(id);") at postgres.c:933
#39 0x8179907 in PostgresMain (argc=4, argv=0x82dff4c, username=0x82dff24
"vugtf") at postgres.c:2986
#40 0x815379a in BackendRun (port=0x82f3090) at postmaster.c:2817
#41 0x8153015 in BackendStartup (port=0x82f3090) at postmaster.c:2453
#42 0x8151878 in ServerLoop () at postmaster.c:1198
#43 0x8151351 in PostmasterMain (argc=3, argv=0x82deaf8) at postmaster.c:917
#44 0x8127281 in main (argc=3, argv=0xbffff8f4) at main.c:268
#45 0x400d4577 in __libc_start_main () from /lib/libc.so.6




-
Best,




Frank.

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #1329: Bug in IF-ELSEIF-ELSE construct
Следующее
От: Tom Lane
Дата:
Сообщение: Re: use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)