Torsten Förtsch wrote:
> On Tuesday 13 April 2010 12:49:45 Jan Schmidt wrote:
>> Tried and works. Thank you! I wonder whether this was just "not nice to
>> perl" or might it have been the root cause for infrequent memory
>> corruptions I am hunting for?
>>
> No. sv_catpvn calls SvGROW itself almost
On Tuesday 13 April 2010 12:49:45 Jan Schmidt wrote:
> Tried and works. Thank you! I wonder whether this was just "not nice to
> perl" or might it have been the root cause for infrequent memory
> corruptions I am hunting for?
>
No. sv_catpvn calls SvGROW itself almost first thing. SvGROW then allo
Torsten Förtsch wrote:
> On Tuesday 13 April 2010 11:29:49 Jan Schmidt wrote:
>> From the test logs it seems to me that mod_perl is doing something nasty
>> (but systematically) with the perl API concerning Perl_sv_catpvn().
>>
> Fixed in trunk.
>
> You may try this patch:
Tried and works. Thank
On Tuesday 13 April 2010 12:00:05 Torsten Förtsch wrote:
> svn checkout \
> https://svn.apache.org/repos/asf/perl/modperl/branches/threading \
> mod_perl-2.0
>
Oops, don't do that. It one requires a threaded perl. Yours is not.
useithreads=undef, usemultiplicity=undef
Torsten Förtsch
--
On Tuesday 13 April 2010 11:29:49 Jan Schmidt wrote:
> From the test logs it seems to me that mod_perl is doing something nasty
> (but systematically) with the perl API concerning Perl_sv_catpvn().
>
Fixed in trunk.
You may try this patch:
Index: src/modules/perl/modperl_filter.c
1. Problem Description:
I wanted to debug something different in mod_perl and thought it was a
good idea to have a debugging perl first. After compiling perl with
-Doptimize=-g and a clean rebuild of mod_perl, various tests fail under
Solaris 10.
>From the test logs it seems to me that mod_perl i