One test in data.cc crashes Octave 3.1.51

[John W. Eaton]

On 14-Aug-2008, Thomas Treichl wrote:

| Thomas Treichl schrieb:
| > John W. Eaton schrieb:
| >> On 12-Aug-2008, Jaroslav Hajek wrote:
| >>
| >> To start with, run Octave under gdb and find out where it crashes.
| > 
| > I have some problems here, it looks to me like gdb on my i386 cannot debug PPC 
| > code with the Rosetta backend (or at least I don't know how to do it). However, 
| > I can see the wrong result (without a crash of Octave) with the i386 binary too. 
| > If no other ideas then I'll have a look at that one and send my experiences as 
| > soon as possible...
| 
| I have had a look at several Mac developer pages but it seems that it won't be 
| possible to debug PPC on a 138 on 10.4. So I changed to the i386 binary and also 
| have had a look at the Octave sources and I tried to find out more about this 
| problem:
| 
| The strange thing is that none of the log2 and log10 results for complex numbers 
| is correct (but log results seem to e correct). I've found the following code in 
| ov-complex.cc which tells me (I hope that I read this correctly) that log and 
| log10 are taken from libc++ and log2 is taken from Octave internals?
| 
|    COMPLEX_MAPPER (log, std::log)
|    COMPLEX_MAPPER (log2, xlog2)
|    COMPLEX_MAPPER (log10, std::log10)
|    COMPLEX_MAPPER (log1p, ::log1p)

You can find the definitions of the xlog2 functions in
liboctave/lo-mappers.cc.  They are:

  double
  xlog2 (double x)
  {
  #if defined (HAVE_LOG2)
    return log2 (x);
  #else
  #if defined (M_LN2)
    static double ln2 = M_LN2;
  #else
    static double ln2 = log (2);
  #endif

    return log (x) / ln2;
  #endif
  }

  Complex
  xlog2 (const Complex& x)
  {
  #if defined (M_LN2)
    static double ln2 = M_LN2;
  #else
    static double ln2 = log (2);
  #endif

    return std::log (x) / ln2;
  }

| Here is an example output of my Octave session:
| 
|    octave-3.1.51+:1> A = complex (0, Inf)
|    A =    0 + Infi
|    octave-3.1.51+:2> log (A)    ## correct
|    ans = Inf + 1.571i
|    octave-3.1.51+:3> log1p (A)  ## correct
|    ans = Inf + 1.571i
|    octave-3.1.51+:4> log2 (A)   ## should be Inf+2.266*i
|    ans = Inf - NaNi
|    octave-3.1.51+:5> log10 (A)  ## should be Inf+0.682*i
|    ans = Inf - NaNi
| 
| Different number formats give me the same results:
| 
|    octave-3.1.51+:10> log10 (A) ## should be Inf+0.682*i
|    ans = Inf - NaNi
|    octave-3.1.51+:11> log10 (single (A))
|    ans = Inf - NaNi
| 
| Hhmmm... Do I have a problem with 'cmath' and its libraries of the gcc 4.0.1 suite?

What do you see for the following program?

  #include <cmath>
  #include <complex>
  #include <iostream>

  int
  main (void)
  {
    double inf = 1.0 / 0.0;

    double foo = std::log (std::complex<double> (0, inf)) / std::log (2);

    std::cout << foo << std::endl;

    return 0;
  }

Here are the results on my system (AMD 64, Debian) using GCC 4.3.1:

  segfault:57> g++ foo.cc
  segfault:58> ./a.out
  (inf,nan)
  segfault:59> g++ -O foo.cc
  segfault:60> ./a.out
  (inf,2.26618)

Note that the result depends on whether the program is compiled with
optimization enabled.  I think that points toward a bug in the
compiler or the library implementation.  Either way, I don't see how
this is a bug in Octave itself, but if it is a bug in Octave, then
someone will need to clue me in as to why that is so and how we should
go about fixing it.

jwe