Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values - Mailing list pgsql-bugs

Peter Geoghegan wrote:

> Does the crash always have ucol_strcollUseLatin1UTF8() in its backtrace?

AFAICS, yes.

The test that iterates over collations produces two kinds of core files,
some of them are 289MB large, some others are 17GB large.
shared_buffers is only 128MB and work_mem 128MB,
so 289MB is not surprising but 17GB seems excessive.
The box has 16GB of physical mem and 8GB of swap.

I haven't checked all core files because they exhaust the disk
space before completion of the test, but a typical backtrace for
the biggest ones looks like the following, with the segfaults
happening in memcpy:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memcpy_sse2_unaligned ()   at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:35
(gdb) #0  __memcpy_sse2_unaligned ()   at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:35
#1  0x00007fc1db02be6b in memcpy (__len=8589934592, __src=0x7fbc6f4a2010,   __dest=<optimized out>) at
/usr/include/x86_64-linux-gnu/bits/string3.h:51
#2  ucol_CEBuf_Expand (ci=<optimized out>, status=0x7ffd90777128,   b=0x7ffd907751e0) at ucol.cpp:7009
#3  UCOL_CEBUF_PUT (status=0x7ffd90777128, ci=0x7ffd90776460, ce=1493173509,   b=0x7ffd907751e0) at ucol.cpp:7022
#4  ucol_strcollRegular (sColl=sColl@entry=0x7ffd90776460,   tColl=tColl@entry=0x7ffd90776610,
status=status@entry=0x7ffd90777128)  at ucol.cpp:7163 
#5  0x00007fc1db031177 in ucol_strcollRegularUTF8 (coll=0x1371af0,   source=source@entry=0x273d379 "콗喩zx㎍",
sourceLength=sourceLength@entry=11,target=<optimized out>,   targetLength=targetLength@entry=8,
status=status@entry=0x7ffd90777128)  at ucol.cpp:8023 
#6  0x00007fc1db032d36 in ucol_strcollUseLatin1UTF8 (status=<optimized out>,   tLen=<optimized out>, target=<optimized
out>,sLen=<optimized out>,   source=<optimized out>, coll=<optimized out>) at ucol.cpp:8108 
#7  ucol_strcollUTF8_52 (coll=<optimized out>,   source=source@entry=0x273d379 "콗喩zx㎍", sourceLength=<optimized out>,
sourceLength@entry=11,target=<optimized out>,   target@entry=0x273d409 "쳭喩zz", targetLength=targetLength@entry=8,
status=status@entry=0x7ffd90777128)at ucol.cpp:8770 
#8  0x00000000007cc7b4 in varstrfastcmp_locale (x=41145208, y=41145352,   ssup=<optimized out>) at varlena.c:2139
#9  0x0000000000817138 in ApplySortAbbrevFullComparator (ssup=0x136bd98,   isNull2=<optimized out>, datum2=<optimized
out>,isNull1=<optimized out>,    datum1=<optimized out>) at 
../../../../src/include/utils/sortsupport.h:263
#10 comparetup_datum (a=0x7fc1c642d210, b=0x7fc1c642d228,    state=<optimized out>) at tuplesort.c:4350
#11 0x0000000000815aef in qsort_tuple (a=0x7fc1c642d210, n=<optimized out>,    n@entry=2505,
cmp_tuple=cmp_tuple@entry=0x817030<comparetup_datum>,    state=state@entry=0x136bb88) at qsort_tuple.c:104 
#12 0x0000000000815c1f in qsort_tuple (a=0x7fc1c6413020, n=<optimized out>,    n@entry=5279,
cmp_tuple=cmp_tuple@entry=0x817030<comparetup_datum>,    state=state@entry=0x136bb88) at qsort_tuple.c:191 
#13 0x0000000000815c1f in qsort_tuple (a=0x7fc1c63f27e8, n=<optimized out>,    n@entry=103353,
cmp_tuple=cmp_tuple@entry=0x817030<comparetup_datum>,    state=state@entry=0x136bb88) at qsort_tuple.c:191 
#14 0x0000000000815c1f in qsort_tuple (a=0x7fc1c5f423c8, n=<optimized out>,    n@entry=503456,
cmp_tuple=cmp_tuple@entry=0x817030<comparetup_datum>,    state=state@entry=0x136bb88) at qsort_tuple.c:191 
#15 0x0000000000815c1f in qsort_tuple (a=0x7fc1c34ae048, n=<optimized out>,    cmp_tuple=0x817030 <comparetup_datum>,
state=state@entry=0x136bb88)  at qsort_tuple.c:191 
#16 0x000000000081873b in tuplesort_sort_memtuples (   state=state@entry=0x136bb88) at tuplesort.c:3410
#17 0x0000000000818907 in dumpbatch (alltuples=0 '\000', state=0x136bb88)   at tuplesort.c:3087
#18 dumptuples (state=state@entry=0x136bb88,    alltuples=alltuples@entry=0 '\000') at tuplesort.c:2970
#19 0x0000000000818b81 in puttuple_common (state=state@entry=0x136bb88,    tuple=tuple@entry=0x7ffd90777470) at
tuplesort.c:1719
#20 0x000000000081a6f1 in tuplesort_putdatum (state=0x136bb88,    val=<optimized out>, isNull=<optimized out>) at
tuplesort.c:1558
#21 0x00000000005e91ec in advance_aggregates (   aggstate=aggstate@entry=0x13731f8, pergroup=pergroup@entry=0x1376008,
 pergroups=0x0) at nodeAgg.c:1023 
#22 0x00000000005eac03 in agg_retrieve_direct (aggstate=0x13731f8)   at nodeAgg.c:2402
#23 ExecAgg (node=node@entry=0x13731f8) at nodeAgg.c:2117
#24 0x00000000005e2378 in ExecProcNode (node=node@entry=0x13731f8)   at execProcnode.c:539
#25 0x00000000005ddf1e in ExecutePlan (execute_once=<optimized out>,    dest=0x132f368, direction=<optimized out>,
numberTuples=0,   sendTuples=<optimized out>, operation=CMD_SELECT,    use_parallel_mode=<optimized out>,
planstate=0x13731f8,estate=0x1372fe8)   at execMain.c:1693 
#26 standard_ExecutorRun (queryDesc=0x1350938, direction=<optimized out>,    count=0, execute_once=<optimized out>) at
execMain.c:362
#27 0x00000000006f924c in PortalRunSelect (portal=portal@entry=0x1362d98,    forward=forward@entry=1 '\001', count=0,
count@entry=9223372036854775807,   dest=dest@entry=0x132f368) at pquery.c:932 
#28 0x00000000006fa5f0 in PortalRun (portal=0x1362d98,    count=9223372036854775807, isTopLevel=<optimized out>,
run_once=<optimizedout>, dest=0x132f368, altdest=0x132f368,    completionTag=0x7ffd90777990 "") at pquery.c:773 
#29 0x00000000006f7da1 in exec_execute_message (max_rows=9223372036854775807,    portal_name=<optimized out>) at
postgres.c:1984
#30 PostgresMain (argc=3, argv=0x7fffffffffffffff, dbname=0x12cb288 "mlists",    username=0x132f368 "") at
postgres.c:4153
#31 0x000000000047803f in BackendRun (port=0x12c4f30) at postmaster.c:4357
#32 BackendStartup (port=0x12c4f30) at postmaster.c:4029
#33 ServerLoop () at postmaster.c:1753
#34 0x0000000000692a82 in PostmasterMain (argc=argc@entry=3,    argv=argv@entry=0x129d330) at postmaster.c:1361
#35 0x0000000000478f8e in main (argc=3, argv=0x129d330) at main.c:228


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs