Re: IMAP MUA and filtering

[Brian May <bam@debian.org>]

>>>>> "Brendan" == Brendan Cully <brendan@kublai.com> writes:

    Brendan> I'd recommend in 1.3 you switch to IMAP urls, in which
    Brendan> case the syntax is imaps://host/ rather than
    Brendan> imap://host/. But the old {host/ssl} should continue to
    Brendan> work - it's a bug if it doesn't.

{host/ssl} simply beeps.

neither

imap://host/

or 

imaps://host/

work ("is not a mailbox"). Weird.
 
{host}INBOX works fine.

I wonder if my version was replaced with a version that doesn't support
SSL somewhere along the line (eg. updates to potato replacing the
version I installed from woody).


    Brendan> yeah, none too helpful: 

Yuck. This is the case I hate. It looks like your stack is getting
corrupted somewhere along the line, otherwise it should
always have "main" at the top.

This is typically caused by a buffer over run error. The only way I
have found to diagnose these problems is to single step all the way
through, and check the stack and/or local variables at each stack
frame each time. (anyone have any better ideas?)

Looking at the raw hex dump of the stack might help too, if you have
too much spare time <grin>.

(don't get confused via certain compiler optimisations; For instance I
found out the hard way that the compiler doesn't bother to maintain
local register variables if they aren't referenced anymore...)

    Brendan> The debugger does work for some binaries - I did a quick
    Brendan> helloworld test. I'd guess it's a bug in dynamic linking,
    Brendan> probably due to some difference between the machine the
    Brendan> libraries were compiled on and my own. So I'm going to
    Brendan> recompile the libraries named in ldd ./mutt from the
    Brendan> debian source packages and see if that helps - then it's
    Brendan> recompile libc and finally gdb. So it might be a little
    Brendan> while...

Could be the case, I am somewhat skeptical though.

    Brendan> OTOH maybe it's because I'm using libc6-i686 - I'll try
    Brendan> uninstalling that and see if it helps...

Yes. I would try that. My quick'n'dirty guess is that the problem
occurs inside 

0x401788e4 in encode_table () from /lib/i686/libc.so.6

and that the program probably crashes when it tries to return to the
calling program because the return address on the stack is corrupted.

    Brendan> Things used to work on my old homebrew machine, oddly now
    Brendan> that I've fully debianised (since my hard drive crashed)
    Brendan> I get these little glitches...

-- 
Brian May <bam@debian.org>