<<< Date Index >>>     <<< Thread Index >>>

Re: mutt freezes when fed high character in header



On Wed, Jul 04, 2007 at 06:00:14PM +0200, Christian Ebert wrote:
> * Derek Martin on Wednesday, July 04, 2007 at 10:21:08 -0400:
> > On Wed, Jul 04, 2007 at 03:46:37PM +0200, Christian Ebert wrote:
> >> I understand, and -- layman's speak here -- the change in iconv
> >> might've been in the /library/ not the program, but perhaps there
> >> is some way to catch what the library says from Mutt like old
> >> iconv, the program, does.
> > 
> > There isn't.  The library becomes part of the program by dynamically
> > linking the code from the library into Mutt's executable program, but
> > mutt has no control over what it does...  If the library decides to go
> > into an endless loop,
> 
> But iconv, the program, uses the same broken library and doesn't
> go into a loop, or detects the loop in the lib, and error-exits
> immediately.

But this is meaningless.  The iconv program exists for one purpose
only: to convert data between two different encodings.  Mutt is a much
more complicated program, and it may be that the iconv library is
broken in such a way that when mutt calls its functions, it overwrites
other variables in mutt that cause it to return from a function call
to an address that has unknown code in it, which just happens to be an
endless loop, or who knows what...  There are numerous possibilities.
It is very possible that the way the iconv program's data structures
are arranged, being generally fewer and more simplistic,  do not
overwrite any return addresses on the stack, or whatever.  It doesn't
mean there's no bug; it just means the programmer got lucky.  Sort of.

If you've ever taken a computer science class at a school where there
were multiple different kinds of machines, you've probably seen a
similar phenomenon.  A student writes code for an exercise, compiles
and runs it, and it works.  Then the professor does the same thing on
a different machine, and it doesn't.  The program has a bug, but by
coincidence, the execution environment where the student ran the
program just didn't happen to tweak the bug.  End result: student
still gets an F (or at least, not an A).  

[In case it's not obvious, this has happened to me. As it turns out,
in this particular case I did still get an A, because I was able to
show that the bug was due to a standard C library call returning a
different value on the two different architectures.  Over time,
standards change... see the (Linux) manpage for sprintf() for an
example.]

> > The problem here isn't Mutt's fault in any way,
> 
> I wasn't accusing Mutt.

I know you're not, but you have it stuck in your head that Mutt can do
something about a bug in a library, and that's just not possible.
[Note: I'm relying on the analysis of others being correct that this
is a bug in iconv, I have not attempted to verify this myself.
Assuming that's correct, it is not possible in any practical way for
mutt to work around.]

> > and the solution is to update your libiconv to one that's not
> > broken.
> 
> Unfortunately there's nothing that tells an unexperienced user
> that it is iconv's fault. 

That's why we have mutt-users and mutt-dev. :)

> and will just say: oh, Mutt freezes, without telling me
> anything, I'll just use that other mailer which doesn't freeze.

And if that mailer uses iconv, they'll probably run into the bug with
that mailer too.  :)

> > That's a solution that's much easier --
> 
> depending on the experience of the user

It doesn't depend on the user's experience.  Finding out that you have
a broken iconv and replacing it is inherently simpler than coding a
workaround which is impossible to write, no matter how much experience
you have.  ;-)


-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

Attachment: pgpmLguX0fhD6.pgp
Description: PGP signature