where is ipvt (from base-lu) defined?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

where is ipvt (from base-lu) defined?

Clinton Chee
Hi Octave Maintainers,

I'm trying to track down a problem with initialization of ipvt in base-lu.cc

Version: Octave 2.1.64

Platform: Itanium2
Linux 2.4.21-sgi303r2 #1 SMP Mon Nov 29 15:29:38 PST 2004 ia64 ia64 ia64
GNU/Linux

Compiler:
Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=ia64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)

NOTE: The problem occurs on the above platform but DOES NOT occur on a
32bit Linux Cluster.

Description:
1. Start octave
2. type: a=([1,2;3,4])
3. type: lu(a)

The program segfaults, the  gdb backtrace is given below. I narrowed the
problem down to base-lu.cc in the "P" function. In the "P" function,
there is:

int k = ipvt.xelem(i)

.... within a for loop where i=0,1.

On the Itanium2 platform,
ipvt.xelem(0)=1
ipvt.xelem(1)=-1

On the 32 bit linux cluster
ipvt.xelem(0)=1
ipvt.xelem(1)=1

I understand why it Seg Faults (k given the value of -1, and then
pvt.xelem(k) fails)


Question: Where does ipvt become defined (in specific, when you do a
"lu(a)" operation)? I know it is declared in base-lu.h as an MArray<T>
type. But why on one platforms it has values of {1,1} and on another {1,-1}


PS Although I'm actually working on a 64bit modified Octave version, I
don't think that is the cause just yet. Just need to know where ipvt is
defined?

Thanks very much

Clinton

 ******** gdb session with backtrace *************


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2305843009213892784 (LWP 14738)]
base_lu<Matrix, double, Matrix, double>::P (this=0x60000fffffff8ab0)
    at Array.h:295
295       T& xelem (octave_idx_type n) {
Current language:  auto; currently c++
(gdb) bt


#0  base_lu<Matrix, double, Matrix, double>::P (this=0x60000fffffff8ab0)
    at Array.h:295
#1  0x40000000000f6970 in Flu (args=@0x0, nargout=0) at
DLD-FUNCTIONS/lu.cc:71
#2  0x40000000004ff1a0 in octave_builtin::do_multi_index_op (
    this=0x6000000000e578f0, nargout=0, args=@0x600000000007acb0)
    at oct-obj.h:78
#3  0x40000000004fe160 in octave_builtin::subsref (this=0x60000fffffff8c80,
    type=@0x6000000000e8fa20, idx=@0x60000fffffff8d60, nargout=0)
    at stl_list.h:413
#4  0x40000000004b0e00 in octave_value::subsref (this=0x60000fffffff8d40,
    type=@0x6000000000e8fa20, idx=@0x60000fffffff8d60, nargout=0) at
ov.cc:832
#5  0x40000000006f0b30 in tree_index_expression::rvalue (
    this=0x6000000000e8f9f0, nargout=0) at pt-idx.cc:256
#6  0x4000000000740e50 in tree_statement::eval (this=0x6000000000eb3088,
    silent=true, nargout=0, in_function_body=false) at pt-stmt.cc:92
#7  0x4000000000741a40 in tree_statement_list::eval
(this=0x6000000000eb2ea0,
    silent=false, nargout=0) at oct-obj.h:78
#8  0x40000000003e8750 in main_loop (fun_to_call=@0x6000000000064eb0)
    at toplev.cc:121
#9  0x0000000000000000 in ?? ()

***********************************************************
--


----------------------------------------------------------------------------
Clinton Chee
Computational Scientist
High Performance Computing Unit
Room 2075, Red Centre
University of New South Wales
Australia 2035
chee at parallel stop hpc stop unsw stop edu stop au
Tel: 61 2 9385 6915
----------------------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

where is ipvt (from base-lu) defined?

John W. Eaton-6
On 29-Mar-2005, Clinton Chee <[hidden email]> wrote:

| Hi Octave Maintainers,
|
| I'm trying to track down a problem with initialization of ipvt in base-lu.cc
|
| Version: Octave 2.1.64
|
| Platform: Itanium2
| Linux 2.4.21-sgi303r2 #1 SMP Mon Nov 29 15:29:38 PST 2004 ia64 ia64 ia64
| GNU/Linux
|
| Compiler:
| Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs
| Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
| --infodir=/usr/share/info --enable-shared --enable-threads=posix
| --disable-checking --with-system-zlib --enable-__cxa_atexit
| --host=ia64-redhat-linux
| Thread model: posix
| gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)
|
| NOTE: The problem occurs on the above platform but DOES NOT occur on a
| 32bit Linux Cluster.
|
| Description:
| 1. Start octave
| 2. type: a=([1,2;3,4])
| 3. type: lu(a)
|
| The program segfaults, the  gdb backtrace is given below. I narrowed the
| problem down to base-lu.cc in the "P" function. In the "P" function,
| there is:
|
| int k = ipvt.xelem(i)
|
| .... within a for loop where i=0,1.
|
| On the Itanium2 platform,
| ipvt.xelem(0)=1
| ipvt.xelem(1)=-1
|
| On the 32 bit linux cluster
| ipvt.xelem(0)=1
| ipvt.xelem(1)=1
|
| I understand why it Seg Faults (k given the value of -1, and then
| pvt.xelem(k) fails)
|
|
| Question: Where does ipvt become defined (in specific, when you do a
| "lu(a)" operation)? I know it is declared in base-lu.h as an MArray<T>
| type. But why on one platforms it has values of {1,1} and on another {1,-1}

It's defined in the LU constructor.  For example, in dbleLU.cc:

LU::LU (const Matrix& a)
{
  int a_nr = a.rows ();
  int a_nc = a.cols ();
  int mn = (a_nr < a_nc ? a_nr : a_nc);

  ipvt.resize (mn);
  int *pipvt = ipvt.fortran_vec ();

  a_fact = a;
  double *tmp_data = a_fact.fortran_vec ();

  int info = 0;

  F77_XFCN (dgetrf, DGETRF, (a_nr, a_nc, tmp_data, a_nr, pipvt, info));

  if (f77_exception_encountered)
    (*current_liboctave_error_handler) ("unrecoverable error in dgetrf");
  else
    ipvt -= 1;
}

First it's resized, then values are set for it in the call to DGETRF.
If the calculation succeeds, the values in ipvt are decremented so
that they match the zero-based indexing used for arrays in Octave.

jwe