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

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 (view raw or flat)
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

pgsql-bugs by date

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

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