Re: Memory exhausted when using \

[Martin Helm]

Am 20.07.2012 23:44, schrieb Martin Helm:
> Am 20.07.2012 23:03, schrieb Martin Helm:
>> I see also a crash with the patch on openSUSE 12.1 64bit, gcc 4.6.2,
>> kernel 3.4.4, when doing "make check", it is test_sparse.m which
>> crashes. I have no proprietary drivers at all and no nvidia (Intel
>> graphics). Will also perform the debug and post back. 
> Backtrace from running test_sparse.m
>
> #0  0x00007ffff5083d95 in raise () from /lib64/libc.so.6
> #1  0x00007ffff50852ab in abort () from /lib64/libc.so.6
> #2  0x00007ffff50bf99e in __libc_message () from /lib64/libc.so.6
> #3  0x00007ffff50c56d6 in malloc_printerr () from /lib64/libc.so.6
> #4  0x00007ffff71044b7 in Sparse<double>::SparseRep::~SparseRep
> (this=0xe577c0,
>     __in_chrg=<optimized out>) at ../liboctave/Sparse.h:109
> #5  0x00007ffff6311273 in Sparse<double>::operator=
> (this=0x7fffffff8420, a=...)
>     at Sparse.cc:681
> #6  0x00007ffff70e8d9b in MSparse<double>::operator=
> (this=0x7fffffff8420, a=...)
>     at ../liboctave/MSparse.h:76
> #7  0x00007ffff70e413b in SparseMatrix::operator= (this=0x7fffffff8420,
> a=...)
>     at ../liboctave/dSparse.h:91
> #8  0x00007ffff64229cb in dmsolve<ComplexMatrix, SparseMatrix,
> ComplexMatrix> (
>     a=..., b=..., address@hidden) at sparse-dmsolve.cc:461
> #9  0x00007ffff640c237 in SparseMatrix::solve (this=0x7fffffff89f0,
> mattype=...,
>     b=..., address@hidden, address@hidden,
>     sing_handler=0x7ffff73c640c <solve_singularity_warning(double)>,
>     singular_fallback=true) at dSparse.cc:6980
> #10 0x00007ffff73c7cbc in xleftdiv (a=..., b=..., typ=...) at
> sparse-xdiv.cc:484
> #11 0x00007ffff7726e43 in oct_binop_ldiv (a1=..., a2=...)
>     at OPERATORS/op-sm-cm.cc:86
> #12 0x00007ffff74dbe2f in do_binary_op (op=octave_value::op_ldiv,
> v1=..., v2=...)
>     at ov.cc:1903
> #13 0x00007ffff754e530 in tree_binary_expression::rvalue1 (this=0xe71380)
>     at pt-binop.cc:132
> #14 0x00007ffff754cc71 in tree_simple_assignment::rvalue1 (this=0xe2c720)
>     at pt-assign.cc:210
> #15 0x00007ffff755747b in tree_evaluator::visit_statement
> (this=0x7ffff7ddb038,
>     stmt=...) at pt-eval.cc:736
> #16 0x00007ffff7572dd2 in tree_statement::accept (this=0xe7f1b0, tw=...)
>     at pt-stmt.cc:151
> #17 0x00007ffff755763f in tree_evaluator::visit_statement_list (
>     this=0x7ffff7ddb038, lst=...) at pt-eval.cc:772
> #18 0x00007ffff757313a in tree_statement_list::accept (this=0xe47540,
> tw=...)
>     at pt-stmt.cc:215
> #19 0x00007ffff74d0dd8 in octave_user_function::do_multi_index_op (
>     this=0xe9a970, nargout=0, args=..., lvalue_list=0x0) at
> ov-usr-fcn.cc:475
> #20 0x00007ffff74d0682 in octave_user_function::subsref (this=0xe9a970,
>     type=..., idx=..., nargout=0, lvalue_list=0x0) at ov-usr-fcn.cc:327
> #21 0x00007ffff74d0570 in octave_user_function::subsref (this=0xe9a970,
>     type=..., idx=..., nargout=0) at ov-usr-fcn.cc:310
> #22 0x00007ffff74d8bb0 in octave_value::subsref (this=0x7fffffff9570,
> type=...,
>     idx=..., nargout=0) at ov.cc:1203
> #23 0x00007ffff74d8c58 in octave_value::subsref (this=0x7fffffff9570,
> type=...,
>     idx=..., nargout=0, lvalue_list=0x0) at ov.cc:1214
> #24 0x00007ffff755c8c2 in tree_index_expression::rvalue (this=0xe338f0,
>     nargout=0, lvalue_list=0x0) at pt-idx.cc:414
> #25 0x00007ffff755c005 in tree_index_expression::rvalue (this=0xe338f0,
>     nargout=0) at pt-idx.cc:284
> #26 0x00007ffff755cb1c in tree_index_expression::rvalue1 (this=0xe338f0,
>     nargout=0) at pt-idx.cc:425
> #27 0x00007ffff755747b in tree_evaluator::visit_statement
> (this=0x7ffff7ddb038,
>     stmt=...) at pt-eval.cc:736
> #28 0x00007ffff7572dd2 in tree_statement::accept (this=0xe4b080, tw=...)
>     at pt-stmt.cc:151
> #29 0x00007ffff755763f in tree_evaluator::visit_statement_list (
>     this=0x7ffff7ddb038, lst=...) at pt-eval.cc:772
> #30 0x00007ffff757313a in tree_statement_list::accept (this=0xe274b0,
> tw=...)
>     at pt-stmt.cc:215
> #31 0x00007ffff74d0dd8 in octave_user_function::do_multi_index_op (
>     this=0xe3f010, nargout=26, args=..., lvalue_list=0x7fffffffa200)
>     at ov-usr-fcn.cc:475
> #32 0x00007ffff74d0682 in octave_user_function::subsref (this=0xe3f010,
>     type=..., idx=..., nargout=26, lvalue_list=0x7fffffffa200)
>     at ov-usr-fcn.cc:327
> #33 0x00007ffff74d8c38 in octave_value::subsref (this=0x7fffffff9e30,
> type=...,
>
The problem seems to be when the value of nz is zero in
MSparse<T> B (nr, nc, (nz < maxnz ? nz : maxnz));
Then it crashes later.