bugGNU Octave - Bugs: bug #49468, [octave forge] tsa package should...

 
 

bug #49468: [octave forge] tsa package should depend on Nan package

Submitter:  John Donoghue <lostbard>
Submitted:  Fri 28 Oct 2016 10:59:58 AM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  JohnD Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 18 Jan 2017 06:10:34 PM UTC, comment #9: 

Tested ok with tsa 4.4.5

John Donoghue <lostbard>
Group Member
Thu 03 Nov 2016 11:48:37 AM UTC, comment #8: 

Taking a look at it now - I see a warning during the install

warning: function C:\Octave\Octave-4.2.0-rc3\share\octave\packages\tsa-4.4.2\detrend.m shadows a core library function

It installs ok, and passes all tests (which also fixes bug #45977)



John Donoghue <lostbard>
Group Member
Thu 03 Nov 2016 12:23:50 AM UTC, comment #7: 

I've uploaded tsa 4.4.2, which does not depend on the NaN-toolbox anymore.

Alois

Alois Schlögl <schloegl>
Wed 02 Nov 2016 09:40:59 PM UTC, comment #6: 

Second issue documented in https://savannah.gnu.org/bugs/index.php?49516

For 1st issue, changing title of this one to reflect that it depends on Nan package

John Donoghue <lostbard>
Group Member
Wed 02 Nov 2016 11:53:56 AM UTC, comment #5: 

Partial issue appears to be that tsa should load the nan package - no crashes if that is loaded first.

Secondary, mexCallMatlab appears to return 0 (ok) even if it didn't find the requested function to run

John Donoghue <lostbard>
Group Member
Tue 01 Nov 2016 06:45:19 PM UTC, comment #4: 

Linux stack trace:


(gdb) where
#0  0x00007f9fdcc7e4d0 in mxGetScalar(mxArray const*) (ptr=0x0) at ../libinterp/corefcn/mex.cc:2856
#1  0x00007f9fa4050af7 in mexFunction(int, mxArray**, int, mxArray const**) (POutputCount=2, POutput=POutput@entry=0x7f9fc5602030, PInputCount=PInputCount@entry=4, PInputs=PInputs@entry=0x7f9fc5602010) at sumskipnan_mex.cpp:172
#2  0x00007f9fdcc83e47 in call_mex(bool, void*, octave_value_list const&, int, octave_mex_function*) (have_fmex=<optimized out>, f=0x7f9fa40505c0 <mexFunction(int, mxArray**, int, mxArray const**)>, args=..., nargout_arg=nargout_arg@entry=2, curr_mex_fcn=curr_mex_fcn@entry=0x7f9fa08f38b0) at ../libinterp/corefcn/mex.cc:3114
#3  0x00007f9fdc7df840 in octave_mex_function::do_multi_index_op(int, octave_value_list const&) (this=0x7f9fa08f38b0, nargout=2, args=...) at ../libinterp/octave-value/ov-mex-fcn.cc:147
#4  0x00007f9fdc7de679 in octave_mex_function::subsref(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (this=0x7f9fa08f38b0, type="(", idx=..., nargout=2) at ../libinterp/octave-value/ov-mex-fcn.cc:93
#5  0x00007f9fdc711cad in octave_base_value::subsref(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::__cxx11::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (this=<optimized out>, type=..., idx=..., nargout=<optimized out>) at ../libinterp/octave-value/ov-base.cc:248
#6  0x00007f9fdc82afd6 in octave_value::subsref(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::__cxx11::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (this=this@entry=0x7f9fb594c160, type="(", idx=..., nargout=nargout@entry=2, lvalue_list=lvalue_list@entry=0x7f9fb594c670) at ../libinterp/octave-value/ov.cc:1456
#7  0x00007f9fdc8e52f7 in tree_index_expression::rvalue(int, std::__cxx11::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (this=0x7f9fa08ad600, nargout=2, lvalue_list=0x7f9fb594c670) at ../libinterp/parse-tree/pt-idx.cc:428
#8  0x00007f9fdc8bb9e0 in tree_multi_assignment::rvalue(int) (this=0x7f9fa08a6ae0)
    at ../libinterp/parse-tree/pt-assign.cc:210


John Donoghue <lostbard>
Group Member
Tue 01 Nov 2016 06:42:32 PM UTC, comment #3: 

It also occurs in fedora 24 with rc3 compiled and installed, so marking OS as any.

John Donoghue <lostbard>
Group Member
Fri 28 Oct 2016 08:38:17 PM UTC, comment #2: 

From gdb:


#0  0x6c024494 in mxGetScalar () from C:\Octave\Octave-4.2.0-rc2\bin\liboctinterp-4.dll
#1  0x71142f6f in mexFunction (POutputCount=2, POutput=0x4c21030, PInputCount=4, PInputs=0x4c21020) at sumskipnan_mex.cpp:172
#2  0x6c029255 in liboctinterp-4!_Z8call_mexbPvRK17octave_value_listiP19octave_mex_function () from C:\Octave\Octave-4.2.0-rc2\bin\liboctinterp-4.dll
#3  0x6bc7d9cb in liboctinterp-4!_ZN19octave_mex_function17do_multi_index_opEiRK17octave_value_list () from C:\Octave\Octave-4.2.0-rc2\bin\liboctinterp-4.dll
#4  0x6bc7c928 in liboctinterp-4!_ZN19octave_mex_function7subsrefERKSsRKSt4listI17octave_value_listSaIS3_EEi () from C:\Octave\Octave-4.2.0-rc2\bin\liboctinterp-4.dll
#5  0x6bbf729c in liboctinterp-4!_ZN17octave_base_value7subsrefERKSsRKSt4listI17octave_value_listSaIS3_EEiPKS2_I13octave_lvalueSaIS8_EE () from C:\Octave\Octave-4.2.0-rc2\bin\liboctinterp-4.dll
#6  0x6bcb3f0a in liboctinterp-4!_ZN12octave_value7subsrefERKSsRKSt4listI17octave_value_listSaIS3_EEiPKS2_I13octave_lvalueSaIS8_EE () from C:\Octave\Octave-4.2.0-rc2\bin\liboctinterp-4.dll
#7  0x6bd1979a in liboctinterp-4!_ZN21tree_index_expression6rvalueEiPKSt4listI13octave_lvalueSaIS1_EE () from C:\Octave\Octave-4.2.0-rc2\bin\liboctinterp-4.dll
#8  0x6bcfc3b9 in liboctinterp-4!_ZN21tree_multi_assignment6rvalueEi () from C:\Octave\Octave-4.2.0-rc2\bin\liboctinterp-4.dll
#9  0x6bcfb4b3 in liboctinterp-4!_ZN21tree_multi_assignment7rvalue1Ei () from C:\Octave\Octave-4.2.0-rc2\bin\liboctinterp-4.dll


John Donoghue <lostbard>
Group Member
Fri 28 Oct 2016 05:49:56 PM UTC, comment #1: 

And where does histo_mex.cpp come from - trying to build from hg repo, its not there, without it, it no longer crashes.

John Donoghue <lostbard>
Group Member
Fri 28 Oct 2016 10:59:58 AM UTC, original submission:  

Not sure if windows only, but when running the tsa-4.4.1 built in tests octave 4.2.0rc2 crashes (win10, 32bit build).

It looks like at the time in is running the tests within covm.m.

Looking in gsb, but without debug symbols it looks like it crashes somewhere in the mxGetScalar call.

I'll try a debug build and see if I can get more info.



John Donoghue <lostbard>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by schloegl (Posted a comment)
  • -email is unavailable- added by lostbard (Adding package maintainer)
  • -email is unavailable- added by lostbard (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-01-18 lostbard Open/ClosedOpen Closed
    2017-01-18 lostbard StatusNone Fixed
    2016-11-02 lostbard Summary[octave forge] tsa package crashes in tests [octave forge] tsa package should depend on Nan package
    2016-11-01 lostbard Operating SystemMicrosoft Windows Any
    2016-10-28 lostbard Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code