1.1.29 dccm still dumps core

On Wed, Feb 19, 2003 at 08:31:11AM -0700, Vernon Schryver wrote:
> 
> Is there any chance that changes to Makefiles or something else prevented
> the replacement of the 1.1.28 version of dccm with the 1.1.29 version?

I don't think so:

# ll libexec/dccm+ core 
-rw-------   1 daemon   other    4230888 Feb 18 17:49 core
-rwxr-xr-x   1 bin      bin      1482752 Feb 18 13:19 libexec/dccm+

$ ll -t dcc*/dccm/dccm
-rwxr-xr-x   1 mills    cserv    1482752 Feb 18 13:19 dcc-dccd-1.1.29/dccm/dccm
-rwxr-xr-x   1 mills    cserv    1482752 Feb 17 19:48 dcc-dccd-1.1.28/dccm/dccm
-rwxr-xr-x   1 mills    cserv    1482752 Feb 16 09:33 dcc-dccd-1.1.27/dccm/dccm
-rwxr-xr-x   1 mills    cserv     389960 Jan  8 21:09 dcc-dccd-1.1.18/dccm/dccm
-rwxr-xr-x   1 mills    cserv     475500 Sep 25 13:36 dcc-dccd-1.1.13/dccm/dccm
-rwxr-xr-x   1 mills    cserv     461132 Mar 23  2002 dcc-dccd-1.0.52/dccm/dccm

> Without -g, it's hard to tell but that stack trace looks the same
> as the problem with 1.1.28.  Sven's test message that caused 1.1.28
> crash works with the current version.  I've looked at the code several
> times but do not see anything that should cause the crash.

It is compiled with `-g', but I haven't figured out how to do source-
level debugging.  It's not something I generally need.  My code always
works the first time!  However, I do have some further information.

First, the stack trace:
_memcpy() + b8
dcc_ck_fuz1(130e50,fd2036d8,400,fd2036d8,400,0) + 608
ck_body_sub(130e50,2bfbbd,4d8c,ffffffff,33,33) + 128
dcc_ck_body(130e50,2bfb38,4e3d,1,ff1bd194,fd2039a0) + 8f0
dccm_body(2bfae8,2bfb38,4e3d,22ee8,100,cfb80) + 1dc

It's segfaulting in _memcpy() as a pointer runs past the end
of a segment.  Here's the machine code:

pc    ff0f06a8 _memcpy+0xb8:    ldd     [%g1], %f2
npc   ff0f06ac _memcpy+0xbc:    add     %g1, 0x8, %g1
                _memcpy+0xc0:   sub     %o2, 0x8, %o2
                _memcpy+0xc4:   subcc   %o4, 0x8, %o4

Register %g1 contains 2ea000.  Here's the segment:

/ map
b1 =            ce000 e1 =            fa000 f1 =            26ee8 `core'
b2 =            fa000 e2 =           2ea000 f2 =            52ee8 `core'

The problem seems to be with the parameters for ck_body_sub().  The
buffer pointer is 2bfbbd and the length is 4d8c.  Adding them together
extends past the end of the segment.

Here's a piece of the buffer:

2bfbbd/256c
2bfbbd:         --=CF94944C4EBC4EC4A6DE_98B3_7F4A_86BF
                Content-Type: text/plain;charset="iso-8859-1"
                Content-Transfer-Encoding: Quoted-Printable




                MUSIC DVD
                PUNK-O-RAMA THE MOVIES VOL 1
                PANTY RAID!
                FABULOUS DISASTER
                ASS COBRA
                TURBONEGRO
                LUCKY 7
                Lucky 7
                NO


-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-