Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 16-Jun-2009, Rafael Laboissiere wrote: | * Rafael Laboissiere raf...@debian.org [2009-06-15 21:55]: | | * John W. Eaton j...@jweaton.org [2009-06-15 13:25]: | | On 15-Jun-2009, Rafael Laboissiere wrote: | | | Anyway, it is funny to see how long this bug lived in the code and was | | just awakened by the crappy mips/mipsel architecture... | | Also strange that it didn't show up until now, even on mips. Maybe a | compiler change? | | Probably. | | Anyway, these differences on floating point representation/manipulation | among the architectures make me kinda nervous. | | I am wondering whether we could add a regression test like the following | to data.cc (or wherever): | | /* | %!test | %! format short | %! for r = [0, Inf -Inf, NaN] | %! for i = [0, Inf -Inf, NaN] | %! complex (r, i) | %! endfor | %! endfor | */ | | Yes, the 'complex (r, i)' would lack the semicolon, just to exercise the | code in pr-output.cc. Are you sure you would want this? It won't tell you if the printing is correct without manual inspection, and will clutter the output from running make check with src/pr-output.cc ...ans = 0 + 0i ans =0 + Infi ans =0 - Infi ans =0 + NaNi ans = Inf + 0i ans = Inf + Infi ans = Inf - Infi ans = Inf + NaNi ans = -Inf + 0i ans = -Inf + Infi ans = -Inf - Infi ans = -Inf + NaNi ans = NaN + 0i ans = NaN + Infi ans = NaN - Infi ans = NaN + NaNi PASS1/1 Is there another way to test this without printing the output to the sreen? Maybe use fdisp to put the output in a file and then compare the contents of the file to some expected value? jwe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* John W. Eaton j...@jweaton.org [2009-06-17 14:24]: Are you sure you would want this? It won't tell you if the printing is correct without manual inspection, and will clutter the output from running make check with src/pr-output.cc ...ans = 0 + 0i ans =0 + Infi ans =0 - Infi ans =0 + NaNi ans = Inf + 0i ans = Inf + Infi ans = Inf - Infi ans = Inf + NaNi ans = -Inf + 0i ans = -Inf + Infi ans = -Inf - Infi ans = -Inf + NaNi ans = NaN + 0i ans = NaN + Infi ans = NaN - Infi ans = NaN + NaNi PASS1/1 Is there another way to test this without printing the output to the sreen? Maybe use fdisp to put the output in a file and then compare the contents of the file to some expected value? That would be surely better. Actually, in the specific case I had in mind (NaN problem on mips/mipsel) there would be no need to compare the output, just to exercise the code in pr-output.cc. So, the test could be, for now: /* %!test %! format short %! file = tempname () %! fd = fopen (file) %! for r = [0, Inf -Inf, NaN] %! for i = [0, Inf -Inf, NaN] %! fdisp (fd, complex (r, i)) %! endfor %! endfor %! fclose (fd) %! unlink (file) */ -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* Rafael Laboissiere raf...@debian.org [2009-06-14 22:45]:
Now, I am wondering whether the code in set_format() makes sense. The
function reads:
///
static void
set_format (const Complex c, int r_fw, int i_fw)
{
// [snip]
double rp = c.real ();
double ip = c.imag ();
bool inf_or_nan = (xisinf (c) || xisnan (c));
bool int_only = (D_NINT (rp) == rp D_NINT (ip) == ip);
double r_abs = rp 0.0 ? -rp : rp;
double i_abs = ip 0.0 ? -ip : ip;
int r_x = r_abs == 0.0
? 0 : static_castint (floor (log10 (r_abs) + 1.0));
// [snip]
///
When r_abs is NaN (as in the bug-triggering case) what is the sense of
computing log10 (r_abs) and propagating the result? I am probably
missing something but it seems just pure chance that r_x ends up being
negative on amd64 and i386, what does not trigger the bug.
Attached below is a patch for pr-output.cc that makes Octave work as
expected for 'complex(NaN,0)' on mips (and amd64 as well, FWIW). The
package is being built right now on mips and on amd64 and, if everything
goes well on both arches, I will upload to unstable a new version of the
package, octave3.2_3.2.0-2, containing the patch.
I am rushing with this because everything else is being held by this bug,
like the upload of the new octave-forge packages.
--
Rafael
--- a/pr-output.cc 2009-06-15 08:48:48.0 +0200
+++ b/pr-output.cc 2009-06-15 11:28:58.0 +0200
@@ -852,10 +852,12 @@
double i_abs = ip 0.0 ? -ip : ip;
int r_x = r_abs == 0.0
-? 0 : static_castint (floor (log10 (r_abs) + 1.0));
+? 0 : ((xisinf (rp) || xisnan (rp))
+ ? INT_MIN : static_castint (floor (log10 (r_abs) + 1.0)));
int i_x = i_abs == 0.0
-? 0 : static_castint (floor (log10 (i_abs) + 1.0));
+? 0 : ((xisinf (ip) || xisnan (ip))
+ ? INT_MIN : static_castint (floor (log10 (i_abs) + 1.0)));
int x_max, x_min;
Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 15-Jun-2009, Rafael Laboissiere wrote: | Attached below is a patch for pr-output.cc that makes Octave work as | expected for 'complex(NaN,0)' on mips (and amd64 as well, FWIW). The | package is being built right now on mips and on amd64 and, if everything | goes well on both arches, I will upload to unstable a new version of the | package, octave3.2_3.2.0-2, containing the patch. | | I am rushing with this because everything else is being held by this bug, | like the upload of the new octave-forge packages. | | -- | Rafael | | -- | --- a/pr-output.cc2009-06-15 08:48:48.0 +0200 | +++ b/pr-output.cc2009-06-15 11:28:58.0 +0200 | @@ -852,10 +852,12 @@ |double i_abs = ip 0.0 ? -ip : ip; | |int r_x = r_abs == 0.0 | -? 0 : static_castint (floor (log10 (r_abs) + 1.0)); | +? 0 : ((xisinf (rp) || xisnan (rp)) | +? INT_MIN : static_castint (floor (log10 (r_abs) + 1.0))); | |int i_x = i_abs == 0.0 | -? 0 : static_castint (floor (log10 (i_abs) + 1.0)); | +? 0 : ((xisinf (ip) || xisnan (ip)) | +? INT_MIN : static_castint (floor (log10 (i_abs) + 1.0))); | |int x_max, x_min; To be consistent with what is done int set_format (double, ...), I think this should be diff --git a/src/pr-output.cc b/src/pr-output.cc --- a/src/pr-output.cc +++ b/src/pr-output.cc @@ -851,10 +851,10 @@ double r_abs = rp 0.0 ? -rp : rp; double i_abs = ip 0.0 ? -ip : ip; - int r_x = r_abs == 0.0 + int r_x = (xisinf (rp) || xisnan (rp) || xr_abs == 0.0) ? 0 : static_castint (floor (log10 (r_abs) + 1.0)); - int i_x = i_abs == 0.0 + int i_x = (xisinf (ip) || xisnan (ip) || i_abs == 0.0) ? 0 : static_castint (floor (log10 (i_abs) + 1.0)); int x_max, x_min; Does that work for you? Similar changes may be needed in other functions in case all the elements of a matrix are NaN, for example. jwe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* John W. Eaton j...@jweaton.org [2009-06-15 09:31]: To be consistent with what is done int set_format (double, ...), I think this should be diff --git a/src/pr-output.cc b/src/pr-output.cc --- a/src/pr-output.cc +++ b/src/pr-output.cc @@ -851,10 +851,10 @@ double r_abs = rp 0.0 ? -rp : rp; double i_abs = ip 0.0 ? -ip : ip; - int r_x = r_abs == 0.0 + int r_x = (xisinf (rp) || xisnan (rp) || xr_abs == 0.0) ? 0 : static_castint (floor (log10 (r_abs) + 1.0)); - int i_x = i_abs == 0.0 + int i_x = (xisinf (ip) || xisnan (ip) || i_abs == 0.0) ? 0 : static_castint (floor (log10 (i_abs) + 1.0)); int x_max, x_min; Does that work for you? Thanks for the patch. I will try it on mips as soon as the current build will finish (it takes forever on this kind of hardware...). Your solution is probably better. In my patch, the use of INT_MIN was intended to mimic the result of floor (log10 (NaN) + 1.0) on i386 and amd64. But a value of 0 as you suggest will probably work fine. Anyway, it is funny to see how long this bug lived in the code and was just awakened by the crappy mips/mipsel architecture... Similar changes may be needed in other functions in case all the elements of a matrix are NaN, for example. As I wrote before, if my patch makes the package build and check correctly on mips, I think I will do the upload with it, without waiting for a full solution to the problem. This bug is blocking the progress on the octave-forge packages. Cheers, -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 15-Jun-2009, Rafael Laboissiere wrote: | Anyway, it is funny to see how long this bug lived in the code and was | just awakened by the crappy mips/mipsel architecture... Also strange that it didn't show up until now, even on mips. Maybe a compiler change? jwe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* John W. Eaton j...@jweaton.org [2009-06-15 13:25]: On 15-Jun-2009, Rafael Laboissiere wrote: | Anyway, it is funny to see how long this bug lived in the code and was | just awakened by the crappy mips/mipsel architecture... Also strange that it didn't show up until now, even on mips. Maybe a compiler change? Probably. Anyway, these differences on floating point representation/manipulation among the architectures make me kinda nervous. -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* Rafael Laboissiere raf...@debian.org [2009-06-15 21:55]: * John W. Eaton j...@jweaton.org [2009-06-15 13:25]: On 15-Jun-2009, Rafael Laboissiere wrote: | Anyway, it is funny to see how long this bug lived in the code and was | just awakened by the crappy mips/mipsel architecture... Also strange that it didn't show up until now, even on mips. Maybe a compiler change? Probably. Anyway, these differences on floating point representation/manipulation among the architectures make me kinda nervous. I am wondering whether we could add a regression test like the following to data.cc (or wherever): /* %!test %! format short %! for r = [0, Inf -Inf, NaN] %! for i = [0, Inf -Inf, NaN] %! complex (r, i) %! endfor %! endfor */ Yes, the 'complex (r, i)' would lack the semicolon, just to exercise the code in pr-output.cc. -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* Rafael Laboissiere raf...@debian.org [2009-06-13 09:15]: So, even if log2 returns a wrong value, the bug happens elsewhere. At any rate, the following works as expected: complex (NaN, NaN) complex (0, NaN) complex (NaN, Inf) I am puzzled with this problem and I cannot really debug it, since I am not versed in GDB. The bug arises at line 1442 of pr-output.cc, in function pr_complex(): pr_imag_float (os, i, i_fw); I think I found the culprit but I am stuck with the debugging (see below). If I set a breakpoint at line 703 of pr-output.cc, I see the following when I launch complex(NaN,0) at the octave prompt under gdb: Breakpoint 4, set_complex_format (x_max=2147483647, x_min=0, r_x=2147483647, inf_or_nan=true, int_only=0, r_...@0x7facdd70, i_...@0x7facdd74) at pr-output.cc:703 703 int prec = Voutput_precision; On my amd64 system I see the following, instead: Breakpoint 6, set_complex_format (x_max=0, x_min=-2147483648, r_x=-2147483648, inf_or_nan=true, int_only=0, r_...@0x7fffd1dd6afc, i_...@0x7fffd1dd6af8) at pr-output.cc:703 703 int prec = Voutput_precision; I think that the different values of x_max and x_min explain the bug on the mips system. I guess that this is caused by the following lines in pr-output.cc (function set_format): int x_max = max_abs == 0.0 ? 0 : static_castint (floor (log10 (max_abs) + 1.0)); int x_min = min_abs == 0.0 ? 0 : static_castint (floor (log10 (min_abs) + 1.0)); However, I cannot debug the problem because the variables are not visible from gdb and many things seem to be inlined. Would it be possible to write a simple C++ test program that would expose the problem on mips? -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* Rafael Laboissiere raf...@debian.org [2009-06-14 12:25]: I think that the different values of x_max and x_min explain the bug on the mips system. I guess that this is caused by the following lines in pr-output.cc (function set_format): int x_max = max_abs == 0.0 ? 0 : static_castint (floor (log10 (max_abs) + 1.0)); int x_min = min_abs == 0.0 ? 0 : static_castint (floor (log10 (min_abs) + 1.0)); I meant lines 854 to 858 in pr-output.cc, in function set_format (const Complex c, int r_fw, int i_fw) -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* Rafael Laboissiere raf...@debian.org [2009-06-14 15:39]:
* Rafael Laboissiere raf...@debian.org [2009-06-14 12:25]:
I think that the different values of x_max and x_min explain the bug on
the mips system. I guess that this is caused by the following lines in
pr-output.cc (function set_format):
int x_max = max_abs == 0.0
? 0 : static_castint (floor (log10 (max_abs) + 1.0));
int x_min = min_abs == 0.0
? 0 : static_castint (floor (log10 (min_abs) + 1.0));
I meant lines 854 to 858 in pr-output.cc, in function
set_format (const Complex c, int r_fw, int i_fw)
I think I found the cause of the bug. The simple program:
///
#include cmath
#include iostream
int
main (void)
{
std::cerr static_castint (floor (log10 (0.0/0.0))) std::endl;
return 0;
}
///
when compiled on mips yields 2147483647, while on amd64 and i386 it
yields -2147483648. This explains the different behavior on both
architectures.
Now, I am wondering whether the code in set_format() makes sense. The
function reads:
///
static void
set_format (const Complex c, int r_fw, int i_fw)
{
// [snip]
double rp = c.real ();
double ip = c.imag ();
bool inf_or_nan = (xisinf (c) || xisnan (c));
bool int_only = (D_NINT (rp) == rp D_NINT (ip) == ip);
double r_abs = rp 0.0 ? -rp : rp;
double i_abs = ip 0.0 ? -ip : ip;
int r_x = r_abs == 0.0
? 0 : static_castint (floor (log10 (r_abs) + 1.0));
// [snip]
///
When r_abs is NaN (as in the bug-triggering case) what is the sense of
computing log10 (r_abs) and propagating the result? I am probably
missing something but it seems just pure chance that r_x ends up being
negative on amd64 and i386, what does not trigger the bug.
--
Rafael
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* Rafael Laboissiere raf...@debian.org [2009-06-12 23:09]:
* John W. Eaton j...@jweaton.org [2009-06-12 13:20]:
On 11-Jun-2009, Rafael Laboissiere wrote:
| (gdb) bt
| #0 0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar,
std::char_traitschar ::_M_insert_floatdouble () from
/usr/lib/libstdc++.so.6
| #1 0x2e17b048 in std::num_putchar, std::ostreambuf_iteratorchar,
std::char_traitschar ::do_put () from /usr/lib/libstdc++.so.6
| #2 0x2e18fd44 in std::ostream::_M_insertdouble () from
/usr/lib/libstdc++.so.6
| #3 0x2b04e65c in operator (o...@0x4328b0, pff=value optimized out)
| at /usr/include/c++/4.3/ostream:214
| #4 0x2b054160 in pr_any_float (fmt=0x2bac0d40, o...@0x4328b0,
d=2.2661800709135971, fw=0)
| at pr-output.cc:1394
| #5 0x2b055ca4 in pr_complex (o...@0x4328b0, c=value optimized out,
| r_fw=value optimized out, i_fw=0, scale=value optimized out) at
pr-output.cc:1412
| #6 0x2b057a98 in octave_print_internal (o...@0x4328b0, c...@0x455cc8) at
pr-output.cc:1958
Can you move to this frame and examine the value of C?
Breakpoint 2, octave_print_internal (o...@0x4328b0, c...@0x455cc8) at
pr-output.cc:1958
1958 pr_complex (os, c);
Current language: auto; currently c++
(gdb) print c
$1 = (const Complex ) @0x455cc8: {_M_value = nan(0x7) +
2.2661800709135971 * I}
The real part should be Inf, not NaN, right? I discovered that the octave
on mips also hungs for this :
complex (NaN, 0)
So, even if log2 returns a wrong value, the bug happens elsewhere. At any
rate, the following works as expected:
complex (NaN, NaN)
complex (0, NaN)
complex (NaN, Inf)
I am puzzled with this problem and I cannot really debug it, since I am
not versed in GDB. The bug arises at line 1442 of pr-output.cc, in
function pr_complex():
pr_imag_float (os, i, i_fw);
--
Rafael
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 11-Jun-2009, Rafael Laboissiere wrote: | * John W. Eaton j...@octave.org [2009-06-11 15:42]: | | Did you compile the simpler program with the same options used to | build Octave? | | Probably not. | | Can you run Octave under gdb and find where it hangs, either by | running | |log2 (complex (0, inf)) | | and interrupting it when the hang happens and getting a stack trace, | or by stepping through the log2 function (and the functions it calls) | to find where it hangs? | | When I run it through ./run-octave -g, the command above does not hang, | but gives immediately this, even when I set a breakpoint at log2: How did you set the breakpoint? You'll need to set it in Flog2 to stop in Octave's log2 function (the one that is callable from Octave scripts). | octave:1 log2 (complex (0, inf)) | | Program received signal SIGBUS, Bus error. | [Switching to Thread 0x2aad4d80 (LWP 11231)] | 0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_floatdouble () from /usr/lib/libstdc++.so.6 | | Here is the stack: | | (gdb) bt | #0 0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_floatdouble () from /usr/lib/libstdc++.so.6 | #1 0x2e17b048 in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::do_put () from /usr/lib/libstdc++.so.6 | #2 0x2e18fd44 in std::ostream::_M_insertdouble () from /usr/lib/libstdc++.so.6 | #3 0x2b04e65c in operator (o...@0x4328b0, pff=value optimized out) | at /usr/include/c++/4.3/ostream:214 | #4 0x2b054160 in pr_any_float (fmt=0x2bac0d40, o...@0x4328b0, d=2.2661800709135971, fw=0) | at pr-output.cc:1394 | #5 0x2b055ca4 in pr_complex (o...@0x4328b0, c=value optimized out, | r_fw=value optimized out, i_fw=0, scale=value optimized out) at pr-output.cc:1412 | #6 0x2b057a98 in octave_print_internal (o...@0x4328b0, c...@0x455cc8) at pr-output.cc:1958 Can you move to this frame and examine the value of C? So there is some problem printing the value? Maybe log2 is returning some invalid value. jwe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* Rafael Laboissiere raf...@debian.org [2009-06-11 01:08]: * Peter De Schrijver p...@debian.org [2009-06-10 19:40]: Package: octave3.2 Version: 3.2.0-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999 Build started at 20090607-1015 Thanks, we are already aware of it. It also heppens on mipsel. I am currently investigating the problem using mahler.debian.org. I got the culprit. The test of data.cc never returns because the code below makes Octave 3.2.0 on mips (at least on mahler.debian.org) hangs forever: log2(complex(0,Inf)) Any idea on how to debug this? -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* Rafael Laboissiere raf...@debian.org [2009-06-11 16:07]: * Rafael Laboissiere raf...@debian.org [2009-06-11 01:08]: * Peter De Schrijver p...@debian.org [2009-06-10 19:40]: Package: octave3.2 Version: 3.2.0-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999 Build started at 20090607-1015 Thanks, we are already aware of it. It also heppens on mipsel. I am currently investigating the problem using mahler.debian.org. I got the culprit. The test of data.cc never returns because the code below makes Octave 3.2.0 on mips (at least on mahler.debian.org) hangs forever: log2(complex(0,Inf)) FWIW, the following works: octave:1 complex(0,Inf) ans = 0 + Infi -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 11-Jun-2009, Rafael Laboissiere wrote:
| * Rafael Laboissiere raf...@debian.org [2009-06-11 16:07]:
|
| * Rafael Laboissiere raf...@debian.org [2009-06-11 01:08]:
|
| * Peter De Schrijver p...@debian.org [2009-06-10 19:40]:
|
|Package: octave3.2
|Version: 3.2.0-1
|Severity: serious
|
|There was an error while trying to autobuild your package:
|
| Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999
| Build started at 20090607-1015
|
| Thanks, we are already aware of it. It also heppens on mipsel.
|
| I am currently investigating the problem using mahler.debian.org.
|
| I got the culprit. The test of data.cc never returns because the code below
| makes Octave 3.2.0 on mips (at least on mahler.debian.org) hangs forever:
|
| log2(complex(0,Inf))
|
| FWIW, the following works:
|
| octave:1 complex(0,Inf)
| ans = 0 + Infi
The log2 function is defined in src/data.cc. The relevant part is
if (args.length () == 1)
{
if (nargout 2)
retval(0) = args(0).log2 ();
which ultimately dispatches to
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;
}
So first, can you determine precisely where Octave is actually
hannging? Does the following program work, or does it also hang in
the same way?
#include cmath
#include complex
#include iostream
typedef std::complexdouble Complex;
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;
}
int
main (void)
{
std::complexdouble inf_i (0.0, 1.0/0.0);
std::cerr inf_i std::endl;
std::complexdouble result = xlog2 (inf_i);
std::cerr result std::endl;
return 0;
}
I expect this program to print:
(0,inf)
(inf,2.26618)
but if it hangs, then I think the problem is in the C++ or C library
functions, not Octave.
jwe
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* John W. Eaton j...@bevo.che.wisc.edu [2009-06-11 11:27]:
So first, can you determine precisely where Octave is actually
hannging? Does the following program work, or does it also hang in
the same way?
#include cmath
#include complex
#include iostream
typedef std::complexdouble Complex;
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;
}
int
main (void)
{
std::complexdouble inf_i (0.0, 1.0/0.0);
std::cerr inf_i std::endl;
std::complexdouble result = xlog2 (inf_i);
std::cerr result std::endl;
return 0;
}
I expect this program to print:
(0,inf)
(inf,2.26618)
but if it hangs, then I think the problem is in the C++ or C library
functions, not Octave.
No, it does not hang, but produces the following:
(0,inf)
(nan,nan)
On my Debian sid chroot on amd64, it produces:
(0,inf)
(inf,nan)
--
Rafael
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 11-Jun-2009, Rafael Laboissiere wrote:
| * John W. Eaton j...@bevo.che.wisc.edu [2009-06-11 11:27]:
|
| So first, can you determine precisely where Octave is actually
| hannging? Does the following program work, or does it also hang in
| the same way?
|
|#include cmath
|#include complex
|#include iostream
|
|typedef std::complexdouble Complex;
|
|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;
|}
|
|int
|main (void)
|{
| std::complexdouble inf_i (0.0, 1.0/0.0);
| std::cerr inf_i std::endl;
| std::complexdouble result = xlog2 (inf_i);
| std::cerr result std::endl;
| return 0;
|}
|
| I expect this program to print:
|
|(0,inf)
|(inf,2.26618)
|
| but if it hangs, then I think the problem is in the C++ or C library
| functions, not Octave.
|
| No, it does not hang, but produces the following:
|
| (0,inf)
| (nan,nan)
|
| On my Debian sid chroot on amd64, it produces:
|
| (0,inf)
| (inf,nan)
Did you compile the simpler program with the same options used to
build Octave?
Can you run Octave under gdb and find where it hangs, either by
running
log2 (complex (0, inf))
and interrupting it when the hang happens and getting a stack trace,
or by stepping through the log2 function (and the functions it calls)
to find where it hangs?
jwe
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* John W. Eaton j...@octave.org [2009-06-11 15:42]: Did you compile the simpler program with the same options used to build Octave? Probably not. Can you run Octave under gdb and find where it hangs, either by running log2 (complex (0, inf)) and interrupting it when the hang happens and getting a stack trace, or by stepping through the log2 function (and the functions it calls) to find where it hangs? When I run it through ./run-octave -g, the command above does not hang, but gives immediately this, even when I set a breakpoint at log2: octave:1 log2 (complex (0, inf)) Program received signal SIGBUS, Bus error. [Switching to Thread 0x2aad4d80 (LWP 11231)] 0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_floatdouble () from /usr/lib/libstdc++.so.6 Here is the stack: (gdb) bt #0 0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_floatdouble () from /usr/lib/libstdc++.so.6 #1 0x2e17b048 in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::do_put () from /usr/lib/libstdc++.so.6 #2 0x2e18fd44 in std::ostream::_M_insertdouble () from /usr/lib/libstdc++.so.6 #3 0x2b04e65c in operator (o...@0x4328b0, pff=value optimized out) at /usr/include/c++/4.3/ostream:214 #4 0x2b054160 in pr_any_float (fmt=0x2bac0d40, o...@0x4328b0, d=2.2661800709135971, fw=0) at pr-output.cc:1394 #5 0x2b055ca4 in pr_complex (o...@0x4328b0, c=value optimized out, r_fw=value optimized out, i_fw=0, scale=value optimized out) at pr-output.cc:1412 #6 0x2b057a98 in octave_print_internal (o...@0x4328b0, c...@0x455cc8) at pr-output.cc:1958 #7 0x2b17d504 in octave_base_scalarstd::complexdouble ::print (this=0x2e1fcd60, o...@0x20, pr_as_read_syntax=value optimized out) at ov-base-scalar.cc:121 #8 0x2b114d14 in octave_base_value::print_with_name (this=0x455cc0, output_b...@0x4328b0, name=value optimized out, print_padding=true) at ov-base.cc:358 #9 0x2b0d1450 in bind_ans (v...@0x7faa61a8, print=true) at ov.h:961 #10 0x2b36a1a0 in tree_evaluator::visit_statement (this=0x2bac17dc, stmt=value optimized out) at pt-eval.cc:698 #11 0x2b366174 in tree_evaluator::visit_statement_list (this=0x2bac17dc, l...@0x595ca0) at pt-eval.cc:731 #12 0x2b0bba84 in main_loop () at toplev.cc:570 #13 0x2b02bd1c in octave_main (argc=6, argv=0x7faa6544, embedded=0) at octave.cc:878 #14 0x2e266bac in __libc_start_main () from /lib/libc.so.6 #15 0x004009e8 in _ftext () -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
Package: octave3.2 Version: 3.2.0-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999 Build started at 20090607-1015 [...] ** Using build dependencies supplied by package: Build-Depends: g++-4.1 [arm], gcc-4.1 [arm], gfortran, debhelper (= 6.0.7), autoconf, texinfo, texlive-latex-base, texlive-generic-recommended, libreadline5-dev, libncurses5-dev, gperf, libhdf5-serial-dev (= 1.6.6) | libhdf5-lam-dev (= 1.6.6) | libhdf5-mpich-dev (= 1.6.6) | libhdf5-openmpi-dev (= 1.6.6), libblas-dev, liblapack-dev, gnuplot-nox, libfftw3-dev, texi2html, less, quilt, slice, libpcre3-dev, flex, libglpk-dev (= 4.15), libsuitesparse-dev (= 1:3.2.0), gawk, ghostscript, libcurl4-dev, libqhull-dev, desktop-file-utils, libfltk1.1-dev, libgl1-mesa-swx11-dev, libglu1-mesa-dev, libgraphicsmagick++1-dev, libftgl-dev, libqrupdate-dev, libarpack2-dev (= 2.1+parpack96.dfsg-2) [...] src/DLD-FUNCTIONS/max.cc ... PASS 12/12 src/DLD-FUNCTIONS/qr.cc PASS 46/47 FAIL 1 src/DLD-FUNCTIONS/quad.cc .. PASS8/8 src/DLD-FUNCTIONS/rand.cc .. PASS 57/57 src/DLD-FUNCTIONS/regexp.cc PASS 90/90 src/DLD-FUNCTIONS/schur.cc . PASS5/5 src/DLD-FUNCTIONS/svd.cc ... PASS 15/15 src/DLD-FUNCTIONS/syl.cc ... PASS5/5 src/DLD-FUNCTIONS/time.cc .. PASS 13/13 src/DLD-FUNCTIONS/tsearch.cc ... PASS6/6 src/data.cc make[3]: *** [check] Segmentation fault make[2]: *** [check] Terminated make[1]: *** [check] Terminated make: *** [check-stamp] Terminated Build killed with signal 15 after 150 minutes of inactivity A full build log can be found at: http://buildd.debian.org/build.php?arch=mipspkg=octave3.2ver=3.2.0-1 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
* Peter De Schrijver p...@debian.org [2009-06-10 19:40]: Package: octave3.2 Version: 3.2.0-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999 Build started at 20090607-1015 Thanks, we are already aware of it. It also heppens on mipsel. I am currently investigating the problem using mahler.debian.org. Cheers, -- Rafael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
