Dylan Carlson wrote:
> On Thu October 21 2004 08:45, Mike Frysinger wrote:
> 
>>On Thursday 21 October 2004 07:41 am, Dylan Carlson wrote:
>>
>>>Some users are reporting memory leaks during dev-lang/perl install,
>>>where it eats up all of the memory.
>>
>>using a lot of memory != memory leak
> 
> 
> I know that perl does memory leak self-tests, but I don't know if that is a 
> normal part of 'make test' or not.  Perl's not my core expertise.  It's 
> the bug reporters saying there's a memory leak, not me.  
> 
> 
>>in reality, why are you asking gentoo-dev and not the perl people
>>themselves ... they certainly can handle this question since it's been
>>asked often enough
> 
> 
> It seems they have been asked in bugzilla already.  Perhaps it would be 
> good to re-state what the problem is:  dev-lang/perl is chewing up all 
> available memory during forced self-tests upon install.
> 
> mcummings closed the bug as CANTFIX in Feb., so that's why I'm asking here.  
> It still appears to be a problem.   In my opinion, this self-test behavior 
> should be optional.  Right now, there's no choice, and there's no 
> explanation why.
> 
> Self-tests are there for users when functional problems with the perl 
> install occur after install.  Therefore one can re-install with the 
> self-tests enabled to debug, but it shouldn't be forced.  Maybe there is a 
> critical reason those tests need to be forced, but if so, that hasn't been 
> explained.

Gentoo with its plethora of compiler flags and libs is an environment 
where the Perl core regression tests really add confidence that the 
language is working properly.

That it is failing a regression test may mean that there is a real 
problem with Perl, hence don't install it.  IOW, the suggestions to skip 
the test suite is bad advice.

The way to debug this is to run the test standalone -- that way it 
outputs useful diagnostic information that may help in understanding 
where the problem is.  The failed build should leave the build 
environment behind, ie:

rock # cd /var/tmp/portage/perl-5.8.4-r1/work
rock perl-5.8.4 # ./perl lib/Config.t
1..36
ok 1 - use Config
ok 2 - Config has more than 500 entries
ok 3
ok 4 - PERL_REVISION is 5
ok 5 - PERL_SUBVERSION is defined
ok 6 - PERL_SUBVERSION is aliased to SUBVERSION
ok 7 - PERL_VERSION is defined
ok 8 - PERL_VERSION is aliased to PATCHLEVEL
ok 9 - PERL_CONFIG_SH is defined
ok 10 - PERL_CONFIG_SH is aliased to CONFIG
ok 11 - has cc
ok 12 - has ccflags
ok 13 - has no python
ok 14 - has d_fork
ok 15 - has no d_bork
ok 16 - ivsize is 4 or 8 (it is 4)
ok 17 - byteorder is 1234 or 4321 or 12345678 or 87654321 (it is 1234)
ok 18 - byteorder is as long as ivsize (which is 4)
ok 19 - has ccflags_nolargefiles
ok 20 - myconfig exported
ok 21 - config_sh exported
ok 22 - config_vars exported
ok 23 - config_re exported
ok 24 - myconfig
ok 25 - config_sh
ok 26 - config_re
ok 27 - config_vars cc
ok 28 - config_vars d_bork is UNKNOWN
ok 29 - no STORE
ok 30 - still no d_bork
ok 31 - no DELETE
ok 32 - still d_fork
ok 33 - no CLEAR
ok 34 - still d_fork
ok 35 - sig_num_init size
ok 36 - sig_name_init size


I took a look at bug 34705 but didn't see anything that might point to 
where the problem is.  The output of the test that hangs would be useful.

ds



> So I see two ways to solve this:
>  1. FEATURES=maketest.  If "maketest" isn't there, don't run the tests.
>  2. Less desireable... Run the tests except if "nomaketest" is in FEATURES.
> 
> Cheers,
> Dylan Carlson [absinthe@g.o]
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@g.o mailing list