Обсуждение: use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)

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.

Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
> (Further examination revealed that a simple 'select initcap('f')' is
> enough to bring the backend down......)

Works for me in unicode encoding + C locale on a couple different platforms.

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

Possibly a bug in your old glibc version?

Can anyone else reproduce this?

> (gdb) where
> #0  0x4016e501 in towupper () from /lib/libc.so.6
> #1  0x81a45e2 in initcap (fcinfo=0xbfffdfdc) at oracle_compat.c:312

Since towupper takes an integer not a pointer, it's hard to see why a
crash within it wouldn't be a bug in towupper rather than being blamable
on bad supplied data.

            regards, tom lane

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

BTW, would you confirm that that means

u=# show server_encoding;
 server_encoding
-----------------
 UNICODE
(1 row)

u=# show lc_ctype;
 lc_ctype
----------
 C
(1 row)

u=#

            regards, tom lane

> Possibly a bug in your old glibc version?

Could be, a quick search does reveal some reports on a problem with the
combination of glibc 2.1.3 an towupper.

I'll look into the possibility of upgrading libc, but given the source of
oracle_compat.c, would it be possible to get the v7.4.6 behaviour back for
the time being by fiddling the #define USE_WIDE_UPPER_LOWER ? Or maybe by
using some specific configure option?


> BTW, would you confirm that that means

It does:

db=# show server_encoding;
 server_encoding
-----------------
 UNICODE
(1 row)

db=# show lc_ctype;
 lc_ctype
----------
 C
(1 row)



Hopefully some other Slackware / Debian user can confirm the segfault?





--
Best,




Frank.

Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
> I'll look into the possibility of upgrading libc, but given the source of
> oracle_compat.c, would it be possible to get the v7.4.6 behaviour back for
> the time being by fiddling the #define USE_WIDE_UPPER_LOWER ?

Yeah, IIRC it should be a one-liner kind of change to force the
non-towupper fallback.  If this turns out to be a widespread bug we
might have to consider making configure know about it :-(

            regards, tom lane