I have a full core , and libumem does not show us the corruption by ::umem_status
# mdb core.2033 Loading modules: [ ld.so.1 libumem.so.1 libc.so.1 libuutil.so.1 ] > ::umem_verify Cache Name Addr Cache Integrity umem_magazine_1 4e6028 clean umem_magazine_3 4e6468 clean umem_magazine_7 4e68a8 clean umem_magazine_15 4e9028 clean umem_magazine_31 4e9468 clean umem_magazine_47 4e98a8 clean umem_magazine_63 4ea028 clean umem_magazine_95 4ea468 clean umem_magazine_143 4ea8a8 clean umem_slab_cache 4ed028 clean umem_bufctl_cache 4ed468 clean umem_bufctl_audit_cache 4ed8a8 clean umem_alloc_8 4ef028 clean umem_alloc_16 4ef468 clean umem_alloc_32 4ef8a8 clean umem_alloc_48 4f3028 clean umem_alloc_64 4f3468 clean umem_alloc_80 4f38a8 clean umem_alloc_96 4f6028 clean umem_alloc_112 4f6468 clean umem_alloc_128 4f68a8 clean umem_alloc_160 4f8028 clean umem_alloc_192 4f8468 clean umem_alloc_224 4f88a8 clean umem_alloc_256 4fb028 clean umem_alloc_320 4fb468 clean umem_alloc_384 4fb8a8 clean umem_alloc_448 4fe028 clean umem_alloc_512 4fe468 clean umem_alloc_640 4fe8a8 clean umem_alloc_768 500028 clean umem_alloc_896 500468 clean umem_alloc_1152 5008a8 clean umem_alloc_1344 503028 clean umem_alloc_1600 503468 clean umem_alloc_2048 5038a8 clean umem_alloc_2688 506028 clean umem_alloc_4096 506468 clean umem_alloc_8192 5068a8 clean umem_alloc_12288 508028 clean umem_alloc_16384 508468 clean > ::umem_status Status: ready and active Concurrency: 8 Logs: transaction=128k content=128k Message buffer: > $C fffffd7fffdea360 libc.so.1`strlen+0x40() fffffd7fffdea4c0 libc.so.1`sprintf+0xcd() fffffd7fffdea8e0 libsig.so`_Z14sighdl_getpathv+0x59() fffffd7fffdead20 libsig.so`_Z11sighdl_corev+0x49() fffffd7fffdead50 libsig.so`_Z14sighdl_handleri+0xb5() fffffd7fffdead60 libc.so.1`__sighndlr+6() fffffd7fffdeadd0 libc.so.1`call_user_handler+0x252() fffffd7fffdeae00 libc.so.1`sigacthandler+0xde(b, 0, fffffd7fffdeae20) fffffd7fffdeb260 libstdc++.so.6.0.8`_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base+0xa() fffffd7fffdeb300 libSoapBaseO.so`_ZNSt8_Rb_treeISsSt4pairIKSs14XdmHomeDnCacheESt10_Select 1stIS3_ESt4lessISsESaIS3_EE13insert_uniqueESt17_Rb_tr ee_iteratorIS3_ERKS3_+0x28f() Thanks! Valdemar -----Original Message----- From: ext James Carlson [mailto:james.d.carl...@sun.com] Sent: Tuesday, March 17, 2009 12:18 PM To: Pavesi, Valdemar (NSN - US/Boca Raton) Cc: mdb-discuss at opensolaris.org Subject: RE: [mdb-discuss] How can libumem detect that a global variable wasdeleted? [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
