Crash during elog.c...
От | Jim C. Nasby |
---|---|
Тема | Crash during elog.c... |
Дата | |
Msg-id | 20051104193522.GS9989@pervasive.com обсуждение исходный текст |
Ответы |
Re: Crash during elog.c...
Re: Crash during elog.c... |
Список | pgsql-hackers |
My client (same one with the slru.c issue) has had 3 of these in the past day... The backtrace: Program terminated with signal 11, Segmentation fault. (gdb) bt #0 0x0000003b8946fb20 in strlen () from /lib64/tls/libc.so.6 #1 0x0000003b894428dc in vfprintf () from /lib64/tls/libc.so.6 #2 0x0000003b89461ba4 in vsnprintf () from /lib64/tls/libc.so.6 #3 0x00000000004ff420 in appendStringInfoVA (str=0x7fbfffde30, fmt=0x65f59e "%s", args=0x7fbfffdb50) at stringinfo.c:125 #4 0x00000000004ff746 in appendStringInfo (str=0x7fbfffde30, fmt=0x65f59e "%s") at stringinfo.c:75 #5 0x00000000005d3a26 in log_line_prefix (buf=0x7fbfffde30) at elog.c:1425 #6 0x00000000005d4beb in EmitErrorReport () at elog.c:1465 #7 0x00000000005d4345 in errfinish (dummy=Variable "dummy" is not available. ) at elog.c:382 #8 0x000000000056625f in exec_simple_query ( query_string=0x89e760 "update summary_clicks set clicks = t.clicks, impressions= t.impressions, dollars = t.dollars from pending_summary_clicks_2005_11_02 t where summary_clicks.listingindex= t.listingindex and summary_cl"...) at postgres.c:1030 #9 0x0000000000567bb3 in PostgresMain (argc=4, argv=0x846380, username=0x846350 "iacm") at postgres.c:3007 #10 0x000000000053acf0 in ServerLoop () at postmaster.c:2836 #11 0x000000000053c3f4 in PostmasterMain (argc=5, argv=0x843530) at postmaster.c:918 #12 0x000000000050806f in main (argc=5, argv=0x843530) at main.c:268 (gdb) f 3 #3 0x00000000004ff420 in appendStringInfoVA (str=0x7fbfffde30, fmt=0x65f59e "%s", args=0x7fbfffdb50) at stringinfo.c:125 125 nprinted = vsnprintf(str->data + str->len, avail, fmt, args); (gdb) print *str $39 = {data = 0x848030 "2005-11-04 00:01:02 EST|2005-11-04 00:00:08 EST|216.187.113.78(39476)|didit|", len = 76, maxlen =256, cursor = 0} Asserts are on, but for performance reasons the memory checking stuff is commented out. The good news is there's been no slru.c asserts... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: