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
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
> infreq
On Sun, 17 Sep 2000, Dave Rolsky wrote:
> On Sat, 16 Sep 2000, Ian Kallen wrote:
>
> > 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
On Sat, 16 Sep 2000, Ian Kallen wrote:
> 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
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 d