Re: [Pocl-devel] Finding allocation errors

[Carlos S. de La L. <car...@ur...>]

>> I'm finding that many of the object allocation/deallocation routines are not
>> careful about allocation and freeing memory. I think that some reference
>> counting may be necessary, but this doesn't seem to be employed consistently.

I am aware of this... it is a consequence of always going too fast. But I agree we need to get it back to a controlled state ASAP.

> I'm not sure how it's best to implement the reference counting generically
> in C to avoid code duplication for all the different structure types.
> Probably through some set of cpp macros. E.g. POCL_RELEASE(_OBJ)
> which decrements the ref count and if it goes to zero, frees it and 
> POCL_RETAIN(_TYPE, _OBJ) which does the opposite. These macros then would assume 
> the struct has a unsigned _ref_count member. Or similar.

Sounds ok to me.

>> Should we add "magic markers" into the objects, which would help identify
>> routines accessing objects that have been freed? I am thinking in particular of
>> program, kernel, and mem objects, i.e. adding such markers to their declarations
>> in pocl_cl.h, and checking them in various places.
> 
> Valgrind should be able to spot these. In my opinion we should just run
> the test cases in valgrind and fix the leaks and references to the freed
> objects it finds instead of adding some runtime overhead (and clutter)
> to the code.

Yep, I agree with Pekka... I think the least code complexity the better (my usual point). And valgrind for sanitizing the current leaking code.

BR

Carlos