[You might want to take this off-list.]
Pavesi, Valdemar (NSN - US/Boca Raton) writes:
> My problem was the global variable gHomeDnCacheList that was deleted.
Global variables can't "deleted," except by removing the definition
from the source code itself.
At a guess, what you mean is that the storage pointed to by your
global variable was freed, which is quite a different thing.
libumem's auditing mechanism can tell you where and when it was freed.
> I
> saw a lot of corruptions that was detected by libumem.
> I was just trying to understand why it cannot be detected by libumem
> ,but now it is clear.
I don't understand. Are you saying that libumem detected problems or
that it didn't detect them? The above seems to say both.
It is able to detect corrupted memory, but:
(a) It doesn't know whether having a global pointing to freed
storage is by design or a mistake (not everyone clears things to
NULL after freeing), so that alone won't trigger any report from
libumem or mdb.
(b) Depending on the corruption you encounter, it may be quite
difficult to relate it back to an actual cause. Memory
corruption is like that.
> I am trying to use watchmalloc.so.1
I don't understand this, either. Watchmalloc and libumem are *both*
replacement implementations of the dynamic memory allocator. You
can't use both at the same time.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
