|
Posted by Ilya Zakharevich on December 16, 2004, 6:21 am
Please log in for more thread options
From documentation of v2.010601:
A memory leak on the PARI stack was possible in a rare situaton:
if a PARI function returning a value which is not on stack
(very few possibilities: gnil, gun etc.) is called when no
Math::Pari temporary values are on stack, the GENs created for
the function arguments would leak.
I think some people saw this leak before, but since it was so hard to
reproduce, suffered from it silently. Please retest Math::Pari if you
had "PARI stack overflow" errors.
Thanks for your patience,
Ilya
P.S. It can take several hours for this version to propagate to CPAN.
P.P.S. Actual code to reproduce the leak is very simple; I found it
mostly by luck (or a misprint ;-). Do
$z = PARI 0;
LOOP_OVER_THIS: $x = 256*$z;
The PARI code for multiplication recognizes multiplication by
0, so it returns the globally defined constant 0, which
prohibits freeing the result of conversion of Perl value 256
to a PARI value.
|
|
Posted by Ilya Zakharevich on December 26, 2004, 11:47 am
Please log in for more thread options
People who had problem compiling Math::Pari on darwin:
Try removing -fno-common from CCFLAGS in libPARI/Makefile
If I knew what this means, I could try to do it automatically...
(When compiled with 'Configure' option to Makefile.PL, I see the
following failures:
Failed Test Status Wstat Total Fail Failed List of failed
-------------------------------------------------------------------------------
t/00_Pari.t 127 1 0.79% 109
t/nfields.t 0 11 161 141 87.58% 21-161
1 test and 25 subtests skipped.
Failed 2/15 test scripts, 86.67% okay. 142/826 subtests failed, 82.81% okay.
)
Yours,
Ilya
|
|
Posted by Ilya Zakharevich on December 26, 2004, 12:41 pm
Please log in for more thread options [A complimentary Cc of this posting was NOT [per weedlist] sent to
Ilya Zakharevich
> People who had problem compiling Math::Pari on darwin:
>
> Try removing -fno-common from CCFLAGS in libPARI/Makefile
>
> If I knew what this means, I could try to do it automatically...
> (When compiled with 'Configure' option to Makefile.PL, I see the
> following failures:
>
> Failed Test Status Wstat Total Fail Failed List of failed
> t/00_Pari.t 127 1 0.79% 109
> t/nfields.t 0 11 161 141 87.58% 21-161
I investigated more:
a) It works without Configure too;
b) test 109 failing is a known bug of RE match present in 5.6.0;
c) the segfault in nfields:21 is due to a short stack of Perl
process which is not enough to make a hairy RE match;
I replaced the expected output of this subtest in
src/tests/32/nfields by 0; this (obviously) made the subtest fail,
but the segfault disappears, and the other subtests succeed as
well.
Actually, running after (csh syntax)
limit stacksize 8192
(which is what most others Unix systems default to) makes the
test succeed.
This qualifies the build as succeeding. Now the only question is what
-no-common is supposed to mean, and why it is made the default for
perl...
Hope this helps,
Ilya
|
|
Posted by Jim Gibson on December 27, 2004, 2:02 pm
Please log in for more thread options >
> I investigated more:
>
> a) It works without Configure too;
>
> b) test 109 failing is a known bug of RE match present in 5.6.0;
>
> c) the segfault in nfields:21 is due to a short stack of Perl
> process which is not enough to make a hairy RE match;
>
> I replaced the expected output of this subtest in
> src/tests/32/nfields by 0; this (obviously) made the subtest fail,
> but the segfault disappears, and the other subtests succeed as
> well.
>
> Actually, running after (csh syntax)
>
> limit stacksize 8192
>
> (which is what most others Unix systems default to) makes the
> test succeed.
>
> This qualifies the build as succeeding. Now the only question is what
> -no-common is supposed to mean, and why it is made the default for
> perl...
From 'man gcc' on Mac OS 10.3.7:
-fno-common
In C, allocate even uninitialized global variables in the data sec-
tion of the object file, rather than generating them as common
blocks. This has the effect that if the same variable is declared
(without "extern") in two different compilations, you will get an
error when you link them. The only reason this might be useful is
if you wish to verify that the program will work on other systems
which always work this way.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000
Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
|
|
Posted by Ilya Zakharevich on December 28, 2004, 12:21 am
Please log in for more thread options [A complimentary Cc of this posting was sent to
Jim Gibson
> From 'man gcc' on Mac OS 10.3.7:
>
> -fno-common
> In C, allocate even uninitialized global variables in the data sec-
> tion of the object file, rather than generating them as common
> blocks. This has the effect that if the same variable is declared
> (without "extern") in two different compilations, you will get an
> error when you link them. The only reason this might be useful is
> if you wish to verify that the program will work on other systems
> which always work this way.
Thanks. Still, it is not clear why this is the default on Darwin.
Anyway, my latest variant's Changes (now on PAUSE):
2.010602:
A patch to fix a broken 64-bit ploth test of 2.1.6.
A patch to fix broken hiremainder overflow in port kernel (would not
work with -fno-common) of 2.1.6.
On 64-bit platforms wrong set of tests was chosen, what would
result in false positives during tests.
Now test errors on 64-bit systems should be considered as
indicators of real failures.
Skip 00_Pari.t:109 on 5.6.0 (bug in REx engine).
Reasons of most common test errors mentioned in INSTALL.
Move generation of the flag __HAS_NO_ASM__ to PariBuild.pm;
keep ASMINLINE in libPARI/Makefile.PL (since PariBuild.pm
knows little about $asmarch), but make it conditional on
$do_configure. (Avoids warnings with Configure.)
Yours,
Ilya
|
| Similar Threads | Posted | | Math::Pari headaches | August 15, 2006, 1:50 pm |
| Math::Pari 'factor' is wrong | March 17, 2006, 1:41 pm |
| Building Math::Pari using Sun Studio 11 | October 16, 2006, 11:46 am |
| math::pari on solaris 9 make failure | December 8, 2004, 6:36 am |
| Math::Pari doesn't compile with GCC 3.4.2 in Solaris 9 sparc | January 17, 2005, 5:24 pm |
| Newbie Desperate for Help Installing Math::Pari | August 9, 2006, 10:25 pm |
| Math-Pari-2.010501- make - cannot exec 'cc1' | September 26, 2004, 11:09 am |
| Failure to build Math::Pari Solaris 10 Studio 11 | November 7, 2006, 1:28 pm |
| Segmentation violation in Math:Pari when used in connection with Thread:Pool | February 2, 2006, 4:18 am |
| Out of Memory error | September 12, 2004, 11:51 pm |
|
XML Sitemap