I wanted to follow up on this: our intermitten problem with corrupted
32nd & 64th byte data was, at least outwardly, fixed by recompiling perl
and rebuilding mod_perl. The only remaining performance issues I'm
dealing with I'm looking at IO::File to blame, I'm going to comb through
%INC to find who's loading it and see if I can completely eliminate
those now!
Doug MacEachern wrote:
>
> On Sat, 16 Sep 2000, Ian Kallen wrote:
>
> >
> > I've seen some of the 'perl -V' outputs on this list over the years. Most
> > people have usermymalloc=n but I've a seen a number of Solaris cases that
> > have usemymalloc=y
> >
> > I have a system on Solaris 2.6 with usemymalloc=y and I have a very
> > infrequent bug that usually manifests iteslef as corrupted data at the
> > 64th byte (it can also happen at the 32nd byte!). It doesn't seem to
> > happen ever in single process mode but I have some data objects that
> > will consistently demonstrate this behavior with Apache forked (the bug
> > survives apache shutdowns/startups, so it's not just an errant child).
> > The other pieces of the puzzle: latest DBI, DBD::Oracle, Oracle 8.1.5
> >
> > So, my question for this group: why would I want usemymalloc=y on Solaris
> > 2.6? Besides having to rebuild a somewhat complex mod_perl compile, I'm
> > not looking forward to rebuilding all libraries with XS code so any
> > insight as to the ins and outs of compiling w/ and w/o usemymalloc would
> > be much appreciated!
> > thanks,
>
> solaris system malloc will degrade your Perl performance a great deal.
> i'd be surprised if the bug is caused by Perl's malloc implementation.
> sounds more like buggy xs (or linked in library code) that is stepping out
> of bounds, duplicate free() or similar. purify would be the best tool to
> find the bug, but rather expensive if you don't have it already.
> can you tell us more about this data, like what structure it is, where
> it's passed around in what code?
--
Salon Internet http://www.salon.com/
Manager, Software and Systems "Livin' La Vida Unix!"
Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326
