#1 MSS-aware libc

[Laurynas Biveinis]

Submited by sf id: set

4) Is obvious that a libc compiled with MSS could help
to reduce the ammount

of false "deallocation of non-allocated blocks"
warnings that comes from
libc
functions that returs a newly allocated block. Do you
have it? what about
making it available? BTW: What about providing a libc
with modified
free/malloc functions to avoid such a warning produced
by another library?
Some kind of semaphore could be used to signal that the
next call was
already
monitored and make free/malloc monitor any other
allocation. Just wild ideas

;-)

[Laurynas Biveinis]

Logged In: YES
user_id=24239

From e-mail discussion with SET:

>I'm just hoping it won't require heavy libc source
patching, because that
>> would be a nightmare to maintain.

I think malloc/free/... can be replaced as new/delete are
replaced without messing
with the library itself. Electric Fence does it (to replace
malloc by a modified
version that mmaps the blocks and exploits the CPU
protection to detect out of
bounds writes, lamentably djgpp can't do it in the POSIX way).

[Laurynas Biveinis]

Logged In: YES
user_id=24239

From e-mail discussion with SET:

>I don't understand - if I provide MSS-enabled libc, then
all allocations
>> will be logged correctly anyways?

What I mean is that:
1) MSS currently replaces malloc calls by calls to a wrapper.
2) You won't want to do it for the whole libc ... well you
can but then the work
is bigger.
3) If you don't recompile libc with MSS and just replace
malloc/free by wrappers
that logs the info and then calls the original routines (a
very simple change in a
source file) you'll have calls from the MSS wrapper to the
libc wrapper. To
distinguish them you need a semaphore.
Of course you can just recompile libc with MSS and solve all.