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

From: Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
To: pgsql-bugs(at)postgresql(dot)org
Subject: use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)
Date: 2004-11-27 00:38:13
Message-ID: 200411270138.13700.ftm.van.vugt@foxi.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2004-11-27 01:07:46 Re: use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)
Previous Message Fernando Aguada 2004-11-26 18:42:15 Postmaster fails for postgresql-8.0.0-beta5 on Windows 2000 sp4