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.
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 :) 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 >>
