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