Le 05/12/2011 14:46, Steven Schveighoffer a écrit :
> On Sat, 03 Dec 2011 12:43:08 -0500, Marco Leise <marco.le...@gmx.de> wrote:
>
>> Am 03.12.2011, 10:01 Uhr, schrieb Benjamin Thaut
>> <c...@benjamin-thaut.de>:
>>
>>> Thanks, That doesn't sound to bad. If I manage to get a non leaking
>>> non gc version of d-runtime working would there be any interest in that?
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>
>> That would be most interesting! How do you imagine this could work
>> though? As an example D array slices work on GC memory and you can
>> have dozens of slices on the same memory block. Would these memory
>> blocks be reference counted then?
>
> D array appending operations require a GC. You'd have to avoid them.
> This should be possible with some changes to druntime (just find all the
> cases and remove them).
>
> But what's difficult is finding leaks which don't have any anchor to
> search for. For example, how do you search for code that allocates an
> array and *doesn't* deallocate it?
>
> It's definitely an interesting and worthwhile project.
>
> -Steve
You can modify malloc and free so that :
1) malloc stores in a hash map {address => source file + line & size},
2) free deletes the entry with key address if it exists
At any time, you can check what has not been released by printing the
content of the hashmap .
I did that in C once, in a project where I couldn't use Valgrind.
