1.1.29 dccm still dumps core

> From: Gary Mills <mills@cc.UManitoba.CA>

> > Okay, I figured out how to get `dbx' to work.  Is this better?
>
> Here are a couple more variable dumps, along with code segments:

That helps, but I don't see the cause of the problem.

 - This problem is distinct from the previous two.  This problem is 
    related ignoring noise in URLs like HTTP://ignore.stuff.whatever.ws/
    What should be happening is that a few bytes of URL should be sliding
    up in the buffer, such as copying "stuff.whatever" over a buffer
    containing "ignore.stuff.whatever"

 - I don't know enough about SPARC stack frames to deduce the args to
    memcpy (memmove).  My inferences make no sense.
       + memcpy should have two pointers after 0x131000 among its
          registers and stack frame, but I see only one.
       + It is a surprising that it is using an 8-byte-aligned
          part of bcopy/memcpy/..., since the lengths should be small
          and the pointers usually not aligned.  If it really is trying
          to use 0x131273 as an 8-byte aligned address in %g1, then
          it is crazy and is the cause of the fault instead of
          a bad pointer. 

 - I've tried contstructing a mail message from the fragments of the
     buffer that dbx says ck_fuz1() was given.  Nothing fails it.

The best thing would be to find a copy of the message.  The fragment
looks like spam, so it or something very similar might be available.
I don't see it in my traps, my news.admin.net-abuse.sightings spool 
directory, or Googles archive of news.admin.net-abuse.sightings.

Has someone else seen bulk mentioning shock.com.au?

Second best would be to get all 1014 bytes of the buffer given ckfuz1().
I've forgotten how to use dbx, except that differs from gdb.  Something like
  up
  up
  p buf
or perhaps
  x /1024c buf
would work in gdb.
The problem with "p buf" in gdb and these stack dumps in dbx
is that the debugger is trimming its output.  If the 0x131273 in
the __align_cpy_1() stack frame is not noise, then I suspect
the URL that is triggering the crash is near the end of the 1014 bytes 
given ckfuz1().


thanks,
Vernon Schryver    vjs@rhyolite.com