Re: cfservd core dumping on OSF1 V4.0 (was: snprintf.c on OSF1 V4.0)

[Andrew Stribblehill]

Quoting Ferguson, Steve <Steve.Ferguson@gedas.com> (2003-07-16 16:45:02 BST):
> Okay, I got one step further by simply renaming the system's
> /usr/ccs/lib/libdb.a and rebuilding.  No other elegant solution of cc and ld
> options would fix it (including a null -L to zero out the search path and
> using -exclude to exclude specific libraries).
> 
> I got the binaries built.  cfkey works.  cfagent works.  cfservd not so
> much.  I tried connecting to it remotely with cfrun got the usual vague
> authentication error.  Running cfservd on the DEC box in debug mode (-d2), I
> got this:
> 
> Socket caller address appears honest (xx.yy.zz.228 matches xx.yy.zz.228)
> cfservd: Socket originates from xx.yy.zz.228=bigbox.my.domain.com
> Attempting to verify honesty by looking up hostname (bigbox.my.domain.com)
> IPV4 hostnname lookup on bigbox.my.domain.com
> Stack overflow: pid 5480, proc cfservd, addr 0x1400fff18, pc 0x3ff800f0894
> Memory fault(coredump)
> 
> And cfservd dies, dumping core:
> 
> root@ahu004.abh.vw.com:cfengine# ls -al core
> -rw-------   1 root     daemon   1654784 Jul 16 11:38 core
> root@ahu004.abh.vw.com:cfengine# file core
> core:   core dump, generated from 'cfservd'
> 
> This is repeatable.  It happens consistently.
> 
> Any ideas why this would happen?  Has anyone seen this with 2.0.7p3 on an
> OSF1 V4.0 box? Lacking the ability to remotely use cfrun isn't a
> show-stopper just now, but it's going to be inconvenient.

Could you compile it with debugging symbols (CFLAGS += -g perhaps)
and give us a backtrace of the core dump?

Thanks.
-- 
DOGGER FISHER GERMAN BIGHT
EASTERLY 4 OR 5, INCREASING 5 TO 7 LATER, VEERING SOUTHERLY 4 LATER
IN SOUTH DOGGER AND SOUTH GERMAN BIGHT. THUNDERY SHOWERS LATER.
MODERATE OR GOOD, OCCASIONALLY POOR