[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mutt-dev
Subject:    bug#939: Update to bug#939
From:       Daniel Eisenbud <eisenbud+mutt () cs ! swarthmore ! edu>
Date:       2002-01-30 18:16:51
[Download RAW message or body]

On Wed, Jan 30, 2002 at 11:54:12AM +0000, Dave Smith <Dave.Smith@st.com> wrote:
> On Wed, Jan 30, 2002 at 05:17:10AM -0500, eisenbud+mutt@cs.swarthmore.edu wrote:
> > OK, could you also do "print *((HEADER *)ptr->data)" and tell me what
> > that gives?  I'm curious whether this is corrupted memory or just a
> > message that occasionally slips through without a corresponding thread
> > object (which shouldn't be possible.)
> 
> (gdb) print *((HEADER *)ptr->data)
> $1 = {pgp = 2, mime = 1, flagged = 0, tagged = 0, deleted = 1,
>   changed = 1, attach_del = 0, old = 0, read = 1, expired = 0,
>   superseded = 0, replied = 0, subject_changed = 0, threaded = 1,
>   display_subject = 0, recip_valid = 1, active = 0, trash = 0,
>   zhours = 6, zminutes = 0, zoccident = 1, searched = 0, matched = 0,
>   collapsed = 0, limited = 0, num_hidden = 1, recipient = 0, pair = 0,
>   date_sent = 1012232316, received = 1012232610, offset = 0,
>   lines = 56, index = -1, msgno = 5219, virtual = 5219, score = 0,
>   env = 0x0, content = 0x0, path = 0x0, tree = 0x0, thread = 0x5b26d0,
>   data = 0x0}

Hmm, so this is actually a different crash.  But this is the same as the
pattern we saw all along: sometimes tmp->env is NULL, like here,
sometimes tmp is NULL.  tmp->env being NULL may correspond to a message
being freed but not removed from the hash table, and tmp being NULL --
may correspond to a message that got inserted into the hash table and
then went away between sorts, so it never got a thread object.  Time to
start hunting for strange code paths where things appear and disappear
without dealing with the hash tables.  This more and more makes me want
to make the hash tables completely internal to threading, and not let
anyone else touch them (which would require making IMAP merge envelopes
instead of just replacing them when it reads a full message, but that's
not that big a deal.)

Dave, the next big thing I'm curious about is not -d2 output anymore,
but whether this goes away with $strict_threads turned on.  I'll have an
updated debugging patch soon that will be able to look a little more
deeply at the problems we seem to be seeing, and if $strict_threads
makes this go away, I think I already know a good workaround (that may
even enable me to turn on the incremental rethreading code, who knows?)

-Daniel

-- 
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

"We should go forth on the shortest walk perchance, in the spirit of
undying adventure, never to return,--prepared to send back our embalmed
hearts only as relics to our desolate kingdoms."
					--Henry David Thoreau, "Walking"

[prev in list] [next in list] [prev in thread] [next in thread]