On Mon, Mar 06, 2006 at 02:55:13PM -0800, David McDaniel (damcdani) wrote: > IIRC, the original traceback showed the abort due to umem determining a > deallocation was a duplicate or invalid buffer. Preloading libCstd would > result in umem being usurped by libc, would it not? And thus the > presumed double free isnt caught. Maybe the umem noabort flag might be > worth trying, without the libCstd preload.
The umem noabort flag should only be used as a last resort; there is still an unresolved problem here. Does the program crash without libumem? Cheers, - jonathan > > -----Original Message----- > > From: tools-linking-bounces at opensolaris.org > > [mailto:tools-linking-bounces at opensolaris.org] On Behalf Of Rod Evans > > Sent: Monday, March 06, 2006 4:33 PM > > To: Milliken, Clark > > Cc: tools-linking at opensolaris.org > > Subject: Re: [tools-linking] shared lib using libCstd under java > > > > Milliken, Clark wrote: > > > Removing the -Bsymbolic option has no effect. > > > > > > I created a test prog, that just does just does a: > > > > > > dlopen(...,RTLD_NOW | RTLD_GLOBAL) and that works fine. > > > > > > Another tid-bit... > > > > > > If I LD_PRELOAD=libCstd.so.1, my crash goes away. > > > > You don't happen to have two different versions of libCstd > > being loaded in the process do you? What does a pmap of the > > core file reveal? > > > > If not, then one of the C++/iostreams experts on this alias > > will hopefully provide more information. > > > > -- > > Rod > > _______________________________________________ > > tools-linking mailing list > > tools-linking at opensolaris.org > > > _______________________________________________ > tools-linking mailing list > tools-linking at opensolaris.org -- Jonathan Adams, Solaris Kernel Development
