stack corruption in the webservice code

Thiago Macieira thiago at macieira.org
Tue Dec 10 12:20:43 UTC 2013


On terça-feira, 10 de dezembro de 2013 11:00:42, Linus Torvalds wrote:
> > Valgrind is able to catch them. It will tell you that you're accessing a
> > memory block freed inside ~QByteArray.
> 
> Even if the compiler decides to internally just allocate it on the
> stack because it can see the whole scope?
> 
> But I guess those conversions aren't inlined etc, so the compiler is
> unlikely to really grok the code well enough to be smart.

The compiler can't do that. Even if everything were inline, I've never seen a 
compiler smart enough to convert a malloc() / free() pair to alloca() / nil. 
It would have to prove that there's no side-effects to doing that that and I 
doubt it can (it can't prove that malloc has no extra side-effects). This 
particular code also requires realloc().

And it has to prove the pointer never escapes the scope, which in this case 
I'm sure it can't do, since it will get lost by QByteArray's reference 
counting.

Besides, everything is not inline, like you said. The toLocal8Bit() call needs 
to check a global variable to see what codec the locale uses and will transfer 
control there. The only case that could ever conceivably be inlined is 
toLatin1(), because the size of the string is known (no realloc() necessary) 
and the operation is fairly simple.

And I still need to optimise toLatin1() because my assumptions proved false 
when I was optimising toUtf8() with H. Peter Anvin about a month ago.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20131210/2dc8689d/attachment.sig>


More information about the subsurface mailing list