On Tue, 20 Mar 2007, James Coleman wrote: > Hello Frank, > > With umem in debug mode it checks a redzone at the end of each buffer and > asserts if it has been changed. I have found that sufficient to find some > problems.
Those that ::umem_verify shows. > > There is more extensive firewalling in umem, from this mailing list: > http://blogs.sun.com/roller/page/peteh?entry=hidden_features_of_libumem_firewalls > UMEM_OPTIONS=backend=mmap UMEM_DEBUG=firewall=1 > > I know no more :) That's the thing I was referring to. Have used the kernel variant (KMF_FIREWALL) for debugging specific problems, but was assuming it'd be not there in umem ... What firewalling does is to put every [uk]mem_alloc'ed buffer at the end of a virtual memory mapping. Access beyond the end == BAD TRAP / SIGSEGV, right on the very instruction that goes beyond the end. With ::[uk]mem_verify, you only find out someone went past the end (it'll report the buffer as corrupted if the 'buftag' trailer got modified). With firewalling, you find exactly who/where did access past the end. If it's there, then yes, Jan, it might be a reasonable idea to try it for this specific purpose. FrankH. > > James. > > Frank Hofmann wrote: >> On Tue, 20 Mar 2007, James Coleman wrote: >> >>> >>> libumem uses fixed size pools so for example if you malloc 70 bytes umem >>> will return a buffer which is 95 bytes. So maybe there is a buffer >>> overrun. And with libumem the spare space gets clobbered. >>> But with other libraries the start of another buffer gets clobbered. >>> I think that's most likely what is happening. >> >> Is there an RFE against libumem to support a userland equivalent of >> KMF_FIREWALL ? >> >> That'd allow to nail down this specific sort of offending code red-handed, >> with a segfault on the instruction that writes beyond the end of the >> buffer, by ensuring each buffer terminates exactly at a MMU mapping >> boundary. >> >> It's as good as impossible to use on 32bit, though, as every malloc'ed >> buffer, whatever so small, gets a 4kB (x86) / 8kB (sparc) page of its own, >> uses even more virtual than physical resources :( >> >> FrankH. >> >>> >>> Use C++ stl strings instead of c char arrays maybe :) >>> >>> Try running with umem debug. preload like this: >>> UMEM_DEBUG=default UMEM_LOGGING=transaction LD_PRELOAD=libumem.so.1 <your >>> cmd> >>> ::umem_verify will check for corruption just over the end of buffers. >>> ::umem_status will show details and stack if umem exited because of buffer >>> corruption >>> >>> James. >>> >>> Jan Kopriva wrote: >>>> Hi all, >>>> >>>> I have a strange problem. A utility I am using sometimes coredumps >>>> SIGSEGV. If I use it with libumem preloaded it works perfectly. >>>> Is there any debugging technique I can use in such cases? >>>> >>>> Thanks >>>> >>>> Jan >>>> _______________________________________________ >>>> mdb-discuss mailing list >>>> mdb-discuss at opensolaris.org >>> >>> _______________________________________________ >>> mdb-discuss mailing list >>> mdb-discuss at opensolaris.org >>> > >
