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 >
