[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemacs-devel] [PATCH] Shut up valgrind
From: |
François Revol |
Subject: |
Re: [Qemacs-devel] [PATCH] Shut up valgrind |
Date: |
Fri, 24 Jan 2014 03:53:53 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 |
On 24/01/2014 02:03, Charles Gordon wrote:
> On 23 janv. 2014, at 14:40, François Revol <address@hidden> wrote:
>
>> On 23/01/2014 14:02, Charles Gordon wrote:
>>> Hi Francois,
>>>
>>> I just committed a large patch to fix this issue among other malloc related
>>> inconsistencies.
>>> valgrind was right, it was a bug!
>>> qe_mallocz would have cleared the allocated structure, but you used malloc
>>> in haiku.cpp to allocate it :(
>>> valgrind rules!
>>
>> Actually I ran it on GNU/Linux since valgrind isn't available yet on
>> Haiku... (I just started the port).
>> The X11 code did use qe_mallocz, but I didn't check the tty code though.
>
> Then this issue is unresolved.
> I fixed most memory leaks using valgrind, but I cannot test x11 on Linux for
> the moment.
It seems to be fixed here.
I believe it's the qe_malloc in tty.c at font creation that you changed
to qe_mallocz.
On Linux both X11 and tty support are built, so it probably initialized
the tty display regardless.
As for the --free-all option, I don't see the need, if you want to free
at exit then do it, but there is no need for an option :p
It makes a difference:
==450== in use at exit: 934,064 bytes in 894 blocks
vs.
==451== in use at exit: 71,025 bytes in 497 blocks
But it frees a little too much maybe:
==451== Invalid read of size 8
==451== at 0x41B104: main (qe.c:8111)
==451== Address 0x647b1f0 is 0 bytes inside a block of size 24 free'd
==451== at 0x4C2A70C: free (vg_replace_malloc.c:468)
==451== by 0x41B12B: main (qe.c:8112)
So I'd say just don't bother.
François.