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

List:       kmail-devel
Subject:    Re: Bug#27707: kmail crash: delete in a special constellation
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-06-30 23:07:17
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 30 June 2001 20:46, Don Sanders wrote:
> On Saturday 30 June 2001 19:46, Marc Mutz wrote:
> > On Friday 29 June 2001 14:37, Don Sanders wrote:
> > <snip>
> >
> > > > >      if(mKey.isEmpty() || mKey.left(1) != &req_col)
> > > > > {
> > >
> > > BTW, does applying the fix to the above line you
> > > pointed out earlier make any difference? (I thought it
> > > would hide the problem).
> >
> > <snip>
> >
> > Yes, I cannot reproduce the problem now.
>
> Unfortunately I think this will just hide the problem
> rather than fix it.
>

I'm not so sure anymore. From similar(?) bugs I have fixed recently, I 
am aware of the fact that this crash may occur on executing the return 
statement in generate_key. I had this one or two times already:

A QString is generated in a subroutine and gets it's implicit copy when 
the return statement is executed. But I never had it so unstable. It 
might be related to the fact that the local variables on the stack are 
being corrupted. This might happen in the != calculation, since it 
involves the conversion of &req_col to a QString (see 
operator==(QString,char) source in $QTDIR/src/tools/qstring.cpp). Thus, 
the constructor will build a QString that runs to the next 
happen-to-be-there \0. What saves us here normally is the sole fact 
that always
mKey.left(1).length() <= QString(&req_col).length()
and thus the first test in operator==(QString,QString) is taken. It 
might be that in this special case we happen to see the same length 
(ie. *(&req_col+1) == \0) and thus the last test is taken.

But I can't see how this could really corrupt the stack and why it 
survives until the return from generate_key.

But, this stinks like stack corruption. Thus we don't see it when we 
change the stack (adding function calls before the call to 
generate_key, leaving out local variables, using another compiler?).

[compiler bug]
> > Achim, can you confirm this?
>
> It could also be a compiler bug, it would be nice if Achim
> could tell us which compiler he is using (gcc -v)

If I knew x86 assmebler, I'd take a look at the output for that 
function, but I'm only conversant in 68k assembler and that is from a 
few years back :-(

Marc

- -- 
Marc Mutz <Marc@Mutz.com>
http://marc.mutz.com/
http://www.mathematik.uni-bielefeld.de/~mmutz/
http://EncryptionHOWTO.sourceforge.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Plu83oWD+L2/6DgRArlEAJ9t/3Ic2dCX3Nz+yXJBdsLjZQJI7ACfaLpr
IgsG4HQaGLpfqrv9klQqjWw=
=1Y44
-----END PGP SIGNATURE-----
_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

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