i686-specific install failure in java-1.2.6

[Alex Lancaster]

I have narrowed down and can reproduce at least one of the build
failures that is preventing a full rebuild of the Fedora octave-forge
package.

These failures all occur during the final install phase, not during
the build.  The reproducible failure occurs during the install of the
java-1.2.6 package but when compiling for i686, not when compiling for
x86_64 (even on the same machine):

# make install TMPDIR=/var/tmp
DESTDIR=/builddir/build/BUILDROOT/octave-forge-20090607-8.fc12.i386
DISTPKG=redhat
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
mkdir (/var/tmp/oct-A1qbfn)
untar (/var/tmp/java-1.2.6.tar.gz, /var/tmp/oct-A1qbfn)
error: memory exhausted or requested size too large for range of
Octave's index
type -- eval failed
structure has no member `local_packages'
error: called from `pkg>installed_packages' in file
/usr/share/octave/3.2.2/m/pkg/pkg.m near line 1847, column 20

warning: lo_ieee_init: unrecognized floating point format!
error: can't perform indexing operations for cs-list type
error: evaluating argument list element number 1
error: evaluating argument list element number 1
/bin/sh: line 25: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 26: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 27: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 28: /packinfo/dist_admin: No such file or directory
/bin/sh: line 29: /packinfo/dist_admin: No such file or directory
/bin/sh: line 30: /packinfo/dist_admin: No such file or directory
/bin/sh: line 31: /packinfo/dist_admin: No such file or directory
/bin/sh: line 32: /packinfo/dist_admin: No such file or directory
/bin/sh: line 33: /packinfo/dist_admin: No such file or directory
/bin/sh: line 34: /packinfo/dist_admin: No such file or directory
/bin/sh: line 35: /packinfo/dist_admin: No such file or directory
/bin/sh: line 36: /packinfo/dist_admin: No such file or directory
/bin/sh: line 37: /packinfo/dist_admin: No such file or directory
/bin/sh: line 38: /packinfo/dist_admin: No such file or directory
/bin/sh: line 39: /packinfo/dist_admin: No such file or directory
chmod: cannot access `/packinfo/dist_admin': No such file or directory
make: *** [install] Error 1


(Note that on the very same machine the x86_64 build works fine.)

I then isolated this to the section of the Makefile that runs:

pkg('install','-nodeps','-nodeps','-verbose','/var/tmp/java-1.2.6.tar.gz');

which produces the error:

warning: lo_ieee_init: unrecognized floating point format!
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
mkdir (/tmp/oct-Me8WmG)
untar (/var/tmp/java-1.2.6.tar.gz, /tmp/oct-Me8WmG)
error: memory exhausted or requested size too large for range of Octave's index type -- eval failed  

I'm not sure how to debug much further than this.

More details available on the Fedora downstream bug:

https://bugzilla.redhat.com/show_bug.cgi?id=510841

Note that ppc, ppc64 and x86_64 builds all seem to complete correctly.

Alex






------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Dmitri A. Sergatskov]

On Sat, Aug 29, 2009 at 12:23 AM, Alex
Lancaster<alexl@...> wrote:

> which produces the error:
>
> warning: lo_ieee_init: unrecognized floating point format!
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> warning: autoload: `./__java__.oct' is not an absolute file name
> mkdir (/tmp/oct-Me8WmG)
> untar (/var/tmp/java-1.2.6.tar.gz, /tmp/oct-Me8WmG)
> error: memory exhausted or requested size too large for range of Octave's index type -- eval failed
>
> I'm not sure how to debug much further than this.
>

I can reproduce this error on FC11 (i386) with octave 3.2.2 as well. I
did few steps futher:

try to install java package from the octave prompt:

octave:1> pkg install java-1.2.6.tar.gz
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
__java__.cc: In function ‘void initialize_jvm()’:
__java__.cc:385: warning: deprecated conversion from string constant to ‘char*’
... < few warnings deleted > ...

2 problems (2 warnings)error: memory exhausted or requested size too
large for range of Octave's index type -- trying to return to prompt
octave:1>

Then I tried to build the package in bash shell with ./configure and
make, then it succeeds:

2 problems (2 warnings)rm -f octave.jar
jar cf octave.jar  org/octave/ClassHelper.class
org/octave/OctClassLoader.class  org/octave/Octave.class
org/octave/OctaveReference.class  org/octave/Matrix.class

It appears to me that it is this "jar cf ... " command that crashes
octave's pkg.
So may be it is an octave bug. Crossposting to the octave mailing list...


> More details available on the Fedora downstream bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=510841
>
> Note that ppc, ppc64 and x86_64 builds all seem to complete correctly.
>
> Alex
>
>

Dmitri.
--

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[John W. Eaton-3]

On 29-Aug-2009, Dmitri A. Sergatskov wrote:

| On Sat, Aug 29, 2009 at 12:23 AM, Alex
| Lancaster<alexl@...> wrote:
|
| > which produces the error:
| >
| > warning: lo_ieee_init: unrecognized floating point format!

I think the first thing to do is find why this is happening.  It may
not solve your other problems, but this is a serious error for Octave,
so you should find out why it is happening and fix it.  Maybe we
should make it fatal instead of just a warning.

jwe

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Dmitri A. Sergatskov]

On Sat, Aug 29, 2009 at 11:07 AM, John W. Eaton<jwe@...> wrote:

> On 29-Aug-2009, Dmitri A. Sergatskov wrote:
>
> | On Sat, Aug 29, 2009 at 12:23 AM, Alex
> | Lancaster<alexl@...> wrote:
> |
> | > which produces the error:
> | >
> | > warning: lo_ieee_init: unrecognized floating point format!
>
> I think the first thing to do is find why this is happening.  It may
> not solve your other problems, but this is a serious error for Octave,
> so you should find out why it is happening and fix it.  Maybe we
> should make it fatal instead of just a warning.
>
> jwe
>

OK. I compiled octave 3.2.3_rc1 against self-compiled combined
lapack-3.2.1 + ATLAS-3.9.14 and the ieee warning gone and java package
compiles and installs fine. (I had tried 3.2.3_rc1 against Fedora's
lapack/blas or
ATLAS and it was failing the same way as 3.2.2).

Dmitri.
--

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Dmitri A. Sergatskov]

BTW, while looking into this, I checked netlib's paranoia
(against  gcc version 4.4.1 20090725 (Red Hat 4.4.1-2))

While on x86_64 it passed all tests with flying colors even with highest level
of optimization, on i386 it failed quite miserably:

===============================
gcc -O0 -o paranoia paranoia.c -lm

<skipping some passed tests>

Running test of square root(x).
Testing if sqrt(X * X) == X for 20 Integers X.
Test for sqrt monotonicity.
sqrt has passed a test for Monotonicity.
Testing whether sqrt is rounded or chopped.
Square root is neither chopped nor correctly rounded.
Observed errors run from -5.0000000e-01 to 5.0000000e-01 ulps.

Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065218e+00 as X -> 1.
DEFECT:  Calculated 7.38905609548934539e+00 for
        (1 + (-1.11022302462515654e-16) ^ (-1.80143985094819840e+16);
        differs from correct value by -3.44130679508225512e-09 .
        This much error may spoil financial
        calculations involving tiny interest rates.

<deletia>
====================

Now trying with -O2

<deletia>

Checking for guard digit in *, /, and -.
SERIOUS DEFECT:  - lacks Guard Digit, so cancellation is obscured.

Checking rounding on multiply, divide and add/subtract.
* is neither chopped nor correctly rounded.
/ is neither chopped nor correctly rounded.
Addition/Subtraction neither rounds nor chops.
Sticky bit used incorrectly or not at all.
FLAW:  lack(s) of guard digits or failure(s) to correctly round or chop
(noted above) count as one flaw in the final tally below.

Running test of square root(x).
Testing if sqrt(X * X) == X for 20 Integers X.
Test for sqrt monotonicity.
DEFECT:  sqrt(X) is non-monotonic for X near 2.0000000e+00 .
Testing whether sqrt is rounded or chopped.
Square root is neither chopped nor correctly rounded.
Observed errors run from -5.5000000e+00 to 5.0000000e-01 ulps.
SERIOUS DEFECT:  sqrt gets too many last digits wrong.

Testing powers Z^i for small Integers Z and i.
DEFECT:  computing
        (1.30000000000000000e+01) ^ (1.70000000000000000e+01)
        yielded 8.65041591938133811e+18;
        which compared unequal to correct 8.65041591938133914e+18 ;
                they differ by -1.02400000000000000e+03 .
Errors like this may invalidate financial calculations
        involving interest rates.
Similar discrepancies have occurred 4 times.

Seeking Underflow thresholds UfThold and E0.
FAILURE:  multiplication gets too many last digits wrong.

Smallest strictly positive number found is E0 = 0 .
FAILURE:  Either accuracy deteriorates as numbers
approach a threshold = 0.00000000000000000e+00
 coming down from 0.00000000000000000e+00
 or else multiplication gets too many last digits wrong.
Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065041e+00 as X -> 1.
DEFECT:  Calculated 1.00000000000000000e+00 for
        (1 + (0.00000000000000000e+00) ^ (inf);
        differs from correct value by -6.38905609893065041e+00 .
        This much error may spoil financial
        calculations involving tiny interest rates.

Searching for Overflow threshold:
This may generate an error.
Can `Z = -Y' overflow?
Trying it on Y = -inf .
finds a FLAW:  -(-Y) differs from Y.
Overflow threshold is V  = -inf .
Overflow saturates at V0 = inf .
No Overflow should be signaled for V * 1 = -inf
                           nor for V / 1 = -inf .
Any overflow signal separating this * from the one
above is a DEFECT.
FAILURE:  Comparisons involving +--inf, +-inf
and +-0 are confused by Overflow.

SERIOUS DEFECT:    X / X differs from 1 when X = -inf
  instead, X / X - 1/2 - 1/2 = nan .
SERIOUS DEFECT:    X / X differs from 1 when X = 0.00000000000000000e+00
  instead, X / X - 1/2 - 1/2 = nan .

The number of  FAILUREs  encountered =       4.
The number of  SERIOUS DEFECTs  discovered = 4.
The number of  DEFECTs  discovered =         3.
The number of  FLAWs  discovered =           2.

The arithmetic diagnosed has unacceptable Serious Defects.
Potentially fatal FAILURE may have spoiled this program's subsequent diagnoses.
END OF TEST.
===========================================

 -mieee-fp does not seem to change anything....

FWIW.

Dmitri.
--

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[John W. Eaton-3]

On 29-Aug-2009, Dmitri A. Sergatskov wrote:

| On Sat, Aug 29, 2009 at 11:07 AM, John W. Eaton<jwe@...> wrote:
| > On 29-Aug-2009, Dmitri A. Sergatskov wrote:
| >
| > | On Sat, Aug 29, 2009 at 12:23 AM, Alex
| > | Lancaster<alexl@...> wrote:
| > |
| > | > which produces the error:
| > | >
| > | > warning: lo_ieee_init: unrecognized floating point format!
| >
| > I think the first thing to do is find why this is happening.  It may
| > not solve your other problems, but this is a serious error for Octave,
| > so you should find out why it is happening and fix it.  Maybe we
| > should make it fatal instead of just a warning.
| >
| > jwe
| >
|
| OK. I compiled octave 3.2.3_rc1 against self-compiled combined
| lapack-3.2.1 + ATLAS-3.9.14 and the ieee warning gone and java package
| compiles and installs fine. (I had tried 3.2.3_rc1 against Fedora's
| lapack/blas or
| ATLAS and it was failing the same way as 3.2.2).

I was thinking that the version of ATLAS or BLAS shouldn't have
anything to do with this warning, but then I realized that we now use
D1MACH to compute some machine constants and then compare them against
some known values to determine the floating point format (see
liboctave/mach-info.cc).  The D1MACH function in Octave used to be
implemented using some old code from netlib (machar.c) but now uses
the DLAMCH function from LAPACK.  So I suppose the warning about
unrecognized floating point format could happen if the DLAMCH function
is miscompiled.

jwe

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Michael Goffioul-2]

On Sun, Aug 30, 2009 at 4:21 AM, John W. Eaton<jwe@...> wrote:
> I was thinking that the version of ATLAS or BLAS shouldn't have
> anything to do with this warning, but then I realized that we now use
> D1MACH to compute some machine constants and then compare them against
> some known values to determine the floating point format (see
> liboctave/mach-info.cc).  The D1MACH function in Octave used to be
> implemented using some old code from netlib (machar.c) but now uses
> the DLAMCH function from LAPACK.  So I suppose the warning about
> unrecognized floating point format could happen if the DLAMCH function
> is miscompiled.

I remember that I had a similar problem when using MSVC/f2c. I don't
remember exactly all bits and pieces (as I don't have my laptop under
the hand), but I had to disable optimization when compiling the related
files in LAPACK.

Michael.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Alex Lancaster]

> On 29-Aug-2009, Dmitri A. Sergatskov wrote:

>> On Sat, Aug 29, 2009 at 11:07 AM, John W. Eaton<jwe@...> wrote:
>>> On 29-Aug-2009, Dmitri A. Sergatskov wrote:
>>
>> | On Sat, Aug 29, 2009 at 12:23 AM, Alex
>> | Lancaster<alexl@...> wrote:
>> |
>> | > which produces the error:
>> | >
>> | > warning: lo_ieee_init: unrecognized floating point format!
>>
>> I think the first thing to do is find why this is happening.  It may
>> not solve your other problems, but this is a serious error for Octave,
>> so you should find out why it is happening and fix it.  Maybe we
>> should make it fatal instead of just a warning.
>>
>> jwe

> OK. I compiled octave 3.2.3_rc1 against self-compiled combined
> lapack-3.2.1 + ATLAS-3.9.14 and the ieee warning gone and java
> package compiles and installs fine. (I had tried 3.2.3_rc1 against
> Fedora's lapack/blas or ATLAS and it was failing the same way as
> 3.2.2).

Hi Dmitri,

That's good news.  So what do we need to do to fix this in Fedora
rawhide?  Update to octave 3.2.3_rc1 for one, obviously, and then do
we need to upgrade Fedora's lapack and Atlas packages, or are there
additional configuration changes in their (or octave/octave-forge)
spec files?

Alex

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Dmitri A. Sergatskov]

On Mon, Aug 31, 2009 at 1:28 AM, Alex
Lancaster<alexl@...> wrote:

> Hi Dmitri,
>
> That's good news.  So what do we need to do to fix this in Fedora
> rawhide?  Update to octave 3.2.3_rc1 for one, obviously, and then do
> we need to upgrade Fedora's lapack and Atlas packages, or are there
> additional configuration changes in their (or octave/octave-forge)
> spec files?
>

The main issue is that gcc 4.4.1 appears to have problems on i386.
That leads to mis-compiled DLAMCH routine from lapack 3.1.1.
I do not know why the problem goes avay with lapack 3.2.1,
perhaps it is re-written and more robust now, or it gets compiled
with different optimization flags.
As things stands now, the octave 3.2.2 (from RPM package) on i386
will not pass "make check" test.

> Alex
>

Dmitri.
--

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Dmitri A. Sergatskov]

Apparently dlamch used to be compiled on Fedora with -Os
optimization. May be it was OK before, but now it is definitely too
much. When i recompiled dlamch with  "-ffloat-store -O0"
(as well as slamch and few others,
actually I just replaced -Os flag in the Makefile with "-ffloat-store -O0)
lapack works fine.
I am not sure if -ffloat-store is redundant in this context, but I
decided it would not hurt.

I filled a bug report against lapack on Fedora's bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=520518

FYI.

Dmitri.
--

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev