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?
