[Linux-ha-dev] cl_free: Bad magic number in object at ...

[Lars Marowsky-Bree]

On 2004-10-06T13:19:43, Lars Ellenberg <l.g.e at web.de> wrote:

> BTW,
> 	I don't see a reason to have
> 	LOG, MALLOC, STRDUP, FREE #defined in
> 	every single lib/plugins/HBcomm/*.c file.
> 	that belongs into _one_ header.
> 	same for some more code dups between all those .c files.
> 	this is asking for trouble, once someone touches that code
> 	somewhere.
> 	(I know, the answer is "patches are being accepted")

Yeah, I did it for the STONITH modules, but I did notice it's the same
everywhere else... But I didn't want to fumble over it ;-)

> 	and yes it is fine to have a plugin infrastructure that
> 	_allows_ things to be different. only it does not make so much
> 	sense (to me) if _every single user_ of it uses it the same way,
> 	it only introduces additional indirection, hiding this in
> 	idirect macros, which are not even used everywhere. iirc, this
> 	was my first impression of that code (I whined about all those
> 	different memory allocation "strategies").
> 	Afaics, there is never anything different im/exported than the
> 	PILPluginImportSet defined in pils.c line 237.
> 	So maybe explain to me why this is neccessary
> 	(I just don't see it), or rip it out.
> 	( I guess you won't accept patches to this one :-> )

It's a case of abstraction added before it was ever needed.... ;-)

I'd be in favour of not using it at all, but instead just linking
everything with cl_malloc.c and have a consistent memory allocator
between all components.

Right now, passing memory between the different components (from plugins
to cl_ to heartbeat etc) sort of sucks...


Sincerely,
    Lars Marowsky-Brée <lmb at suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company