stack corruption in the webservice code

[Lubomir I. Ivanov]

On 10 December 2013 20:40, Thiago Macieira <thiago at macieira.org> wrote:
> On terça-feira, 10 de dezembro de 2013 10:18:07, Linus Torvalds wrote:
>> Basically, every time you convert from QString to a "normal" string,
>> you need to keep the QString around as long as that string is used. Or
>> do a strdup(). Or just not convert at all, and keep it as a QString,
>> so that the compiler will do the proper liveness analysis and keep it
>> around.
>
> Actually, you need to keep the QByteArray temporary.
>
>         QByteArray tempfileBA = tempfileQ.toLocal8Bit();
>         tempfile = tempfileBA.constData();
>
> It's the QByteArray that owns the memory block. QByteArray is basically a
> glorified on-scope-exit-call-free() object :-)
>
>> Too bad we don't get compiler warnings for things like this. And
>> apparently malloc library debugging doesn't work very well for
>> automatic C++ objects (since the compiler presumably just allocates
>> them on the stack).
>
> Valgrind is able to catch them. It will tell you that you're accessing a
> memory block freed inside ~QByteArray.
>
> The tool that Lubomir used said the memory was freed, but didn't say where.
> Valgrind does that.
>

subsurface seems to completely crash my tool here (dr. memory) in full
blown mode.
but it works OK for a mem-leak report only.
i have to use the --light flag and it misses a lot of crucial errors,
unlike valgrind which is much better in our case ATM.

lubomir
--