On 5/26/2010 8:18 AM, aiwaniuk at instytut.com.pl wrote:
> On Tue, May 25, 2010 at 09:49:19AM -0400, Steve Singer wrote:
>> > segfault at 273936 ip 00007f359f4f4c40 sp 00007f359b982698 error 4 in
>> > libc-2.9.so[7f359f474000+168000]
>> 
>> Can you rub gdb against a core file, or start slony up inside of gdb, so 
>> we can get a stack trace of what slon was doing went it died?
>> 
>> (from a build with debugging symbols would be even more useful)
> 
> i've faced the same problem while replicating postgres8.3 using slony
> 2.0.3
> subscribe operation had finisher successfully, but then while synchronizing
> tables i still have segfaults. backtrace has shown
> 
> #0  0xb7761f93 in strlen () from /lib/libc.so.6
> #1  0x0805e35d in slon_appendquery_int (dsp=0xb4b11a38, fmt=0x8068af5
> "_log_%d_",ap=0xb42fe1cc "\f`Ä´\022ˇ\t\b\036ˇ\t\b0Ĺ„\006\b\020ˇ\t\b\022ˇ\t\b\036ˇ\t\b\214ă/´đ\vÄ
´\b\fÄ
´\002")   at /usr/include/bits/string3.h:52
> #2  0x0805e7d7 in snprintf (conn=0xb4b11a38) at /usr/include/bits/stdio2.h:65
> #3  db_checkSchemaVersion (conn=0xb4b11a38) at dbutils.c:311
> #4  0x08051f75 in sync_helper (cdata=0xb4c4600c) at remote_worker.c:4993

There are things that make me believe this stack itself is mangled 
already to a point where it is useless for tracing purposes.

1) sync_helper() of 1.2.15 does not call db_checkSchemaVersion() on line 
4993. It performs a slon_mkquery() to build the query string to select 
from sl_log_2.

2) slon_appendquery_int() is definitely not located in string3.h and 
should never be called from snprintf() anyway.

Reading through the release notes of versions later than 1.2.15 this one 
from 1.2.20 strikes me as particular suspicious:

> Fix problem with logging where vsnprintf would, with very large output, 
 > clobber the byte after malloc()ed output

I suggest upgrading to current 1.2.21 ASAP and in the meantime, try to 
run with a very low debug level.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin