[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some notes about mex support in Octave
From: |
David Bateman |
Subject: |
Re: some notes about mex support in Octave |
Date: |
Wed, 26 Jul 2006 10:13:19 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.6-7.6.20060mdk (X11/20050322) |
John W. Eaton wrote:
>On 26-Jul-2006, David Bateman wrote:
>
>| Ok, then what about the attached patch.
>
>Thanks, I checked it in.
>
>| The test code should probably be
>| cleaned up. Also I note that valgrind is not clean against the mex
>| types, though that is independent of the sparse type..
>
>Can you send an example of some code that shows the problem?
>
>
Well in fact I had problems with all of the mex example code in
valgrind. For example launching octave with "valgrind --tool-memcheck
octave" and then running the mystruct mex example gave me the errors
octave:1> a.b=1; a.c=2; mystruct(a)
==6528==
==6528== Invalid read of size 4
==6528== at 0x1DD2A506:
std::_Rb_tree_increment(std::_Rb_tree_node_base*) (in
/usr/lib/libstdc++.so.6.0.5)
==6528== by 0x1DD2A55C:
std::_Rb_tree_increment(std::_Rb_tree_node_base const*) (in
/usr/lib/libstdc++.so.6.0.5)
==6528== by 0x1BB094D9: mex::cleanup(void*) (stl_tree.h:263)
==6528== by 0x1BC038CF: unwind_protect::run() (unwind-prot.cc:205)
==6528== by 0x1BAFFD27: call_mex(callstyle, void*, octave_value_list
const&, int) (mex.cc:2837)
==6528== by 0x1BB0006A: C_mex(void*, octave_value_list const&, int)
(mex.cc:2851)
==6528== by 0x1BCE0F24: octave_mex_function::do_multi_index_op(int,
octave_value_list const&) (ov-mex-fcn.cc:147)
==6528== by 0x1BCE0790: octave_mex_function::subsref(std::string
const&, std::list<octave_value_list, std::allocator<octave_value_list> >
const&, int) (ov-mex-fcn.cc:88)
==6528== by 0x1BC9E357: octave_value::subsref(std::string const&,
std::list<octave_value_list, std::allocator<octave_value_list> > const&,
int) (ov.cc:734)
==6528== by 0x1BDD597D: tree_index_expression::rvalue(int)
(pt-idx.cc:352)
==6528== by 0x1BDF0DA4: tree_statement::eval(bool, int, bool)
(pt-stmt.cc:133)
==6528== by 0x1BDF11BD: tree_statement_list::eval(bool, int)
(pt-stmt.cc:190)
==6528== Address 0x1F32E4B4 is 12 bytes inside a block of size 20 free'd
==6528== at 0x1B900647: operator delete(void*) (vg_replace_malloc.c:246)
==6528== by 0x1BB09249: std::_Rb_tree<mxArray*, mxArray*,
std::_Identity<mxArray*>, std::less<mxArray*>, std::allocator<mxArray*>
>::_M_erase(std::_Rb_tree_node<mxArray*>*) (new_allocator.h:94)
==6528== by 0x1BB092E8: std::_Rb_tree<mxArray*, mxArray*,
std::_Identity<mxArray*>, std::less<mxArray*>, std::allocator<mxArray*>
>::erase(std::_Rb_tree_iterator<mxArray*>,
std::_Rb_tree_iterator<mxArray*>) (stl_tree.h:666)
==6528== by 0x1BB09377: std::_Rb_tree<mxArray*, mxArray*,
std::_Identity<mxArray*>, std::less<mxArray*>, std::allocator<mxArray*>
>::erase(mxArray* const&) (stl_tree.h:1045)
==6528== by 0x1BB094BA: mex::cleanup(void*) (stl_set.h:386)
==6528== by 0x1BC038CF: unwind_protect::run() (unwind-prot.cc:205)
==6528== by 0x1BAFFD27: call_mex(callstyle, void*, octave_value_list
const&, int) (mex.cc:2837)
==6528== by 0x1BB0006A: C_mex(void*, octave_value_list const&, int)
(mex.cc:2851)
==6528== by 0x1BCE0F24: octave_mex_function::do_multi_index_op(int,
octave_value_list const&) (ov-mex-fcn.cc:147)
==6528== by 0x1BCE0790: octave_mex_function::subsref(std::string
const&, std::list<octave_value_list, std::allocator<octave_value_list> >
const&, int) (ov-mex-fcn.cc:88)
==6528== by 0x1BC9E357: octave_value::subsref(std::string const&,
std::list<octave_value_list, std::allocator<octave_value_list> > const&,
int) (ov.cc:734)
==6528== by 0x1BDD597D: tree_index_expression::rvalue(int)
(pt-idx.cc:352)
==6528==
==6528== Invalid read of size 4
==6528== at 0x1DD2A51E:
std::_Rb_tree_increment(std::_Rb_tree_node_base*) (in
/usr/lib/libstdc++.so.6.0.5)
==6528== by 0x1DD2A55C:
std::_Rb_tree_increment(std::_Rb_tree_node_base const*) (in
/usr/lib/libstdc++.so.6.0.5)
==6528== by 0x1BB094D9: mex::cleanup(void*) (stl_tree.h:263)
==6528== by 0x1BC038CF: unwind_protect::run() (unwind-prot.cc:205)
==6528== by 0x1BAFFD27: call_mex(callstyle, void*, octave_value_list
const&, int) (mex.cc:2837)
==6528== by 0x1BB0006A: C_mex(void*, octave_value_list const&, int)
(mex.cc:2851)
==6528== by 0x1BCE0F24: octave_mex_function::do_multi_index_op(int,
octave_value_list const&) (ov-mex-fcn.cc:147)
==6528== by 0x1BCE0790: octave_mex_function::subsref(std::string
const&, std::list<octave_value_list, std::allocator<octave_value_list> >
const&, int) (ov-mex-fcn.cc:88)
==6528== by 0x1BC9E357: octave_value::subsref(std::string const&,
std::list<octave_value_list, std::allocator<octave_value_list> > const&,
int) (ov.cc:734)
==6528== by 0x1BDD597D: tree_index_expression::rvalue(int)
(pt-idx.cc:352)
==6528== by 0x1BDF0DA4: tree_statement::eval(bool, int, bool)
(pt-stmt.cc:133)
==6528== by 0x1BDF11BD: tree_statement_list::eval(bool, int)
(pt-stmt.cc:190)
==6528== Address 0x1F32E4AC is 4 bytes inside a block of size 20 free'd
==6528== at 0x1B900647: operator delete(void*) (vg_replace_malloc.c:246)
==6528== by 0x1BB09249: std::_Rb_tree<mxArray*, mxArray*,
std::_Identity<mxArray*>, std::less<mxArray*>, std::allocator<mxArray*>
>::_M_erase(std::_Rb_tree_node<mxArray*>*) (new_allocator.h:94)
==6528== by 0x1BB092E8: std::_Rb_tree<mxArray*, mxArray*,
std::_Identity<mxArray*>, std::less<mxArray*>, std::allocator<mxArray*>
>::erase(std::_Rb_tree_iterator<mxArray*>,
std::_Rb_tree_iterator<mxArray*>) (stl_tree.h:666)
==6528== by 0x1BB09377: std::_Rb_tree<mxArray*, mxArray*,
std::_Identity<mxArray*>, std::less<mxArray*>, std::allocator<mxArray*>
>::erase(mxArray* const&) (stl_tree.h:1045)
==6528== by 0x1BB094BA: mex::cleanup(void*) (stl_set.h:386)
==6528== by 0x1BC038CF: unwind_protect::run() (unwind-prot.cc:205)
==6528== by 0x1BAFFD27: call_mex(callstyle, void*, octave_value_list
const&, int) (mex.cc:2837)
==6528== by 0x1BB0006A: C_mex(void*, octave_value_list const&, int)
(mex.cc:2851)
==6528== by 0x1BCE0F24: octave_mex_function::do_multi_index_op(int,
octave_value_list const&) (ov-mex-fcn.cc:147)
==6528== by 0x1BCE0790: octave_mex_function::subsref(std::string
const&, std::list<octave_value_list, std::allocator<octave_value_list> >
const&, int) (ov-mex-fcn.cc:88)
==6528== by 0x1BC9E357: octave_value::subsref(std::string const&,
std::list<octave_value_list, std::allocator<octave_value_list> > const&,
int) (ov.cc:734)
==6528== by 0x1BDD597D: tree_index_expression::rvalue(int)
(pt-idx.cc:352)
field b(0) = 1
field c(0) = 2
I get similar errors in valgrind from all mex files.. BTW, maybe a patch
like the attached should also be applied..
D.
--
David Bateman address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
*** ./scripts/miscellaneous/mkoctfile.m.orig 2006-07-26 10:04:29.049172791
+0200
--- ./scripts/miscellaneous/mkoctfile.m 2006-07-26 10:02:04.050349335 +0200
***************
*** 50,57 ****
## @item -c
## Compile but do not link.
##
! ## @item -o FILE|--output FILE
! ## Output file name; by default extension is .oct.
##
## @item -p VAR|--print VAR
## Print the configuration variable VAR. Recognized variables are:
--- 50,59 ----
## @item -c
## Compile but do not link.
##
! ## @item -o FILE|--output FILE
! ## Output file name. Default extension is .oct
! ## (or .mex if --mex is specified) unless linking
! ## a stand-alone executable.
##
## @item -p VAR|--print VAR
## Print the configuration variable VAR. Recognized variables are:
***************
*** 82,87 ****
--- 84,93 ----
## @item --link-stand-alone
## Link a stand-alone executable file.
##
+ ## @item --mex
+ ## Assume we are creating a MEX file. Set the default output extension
+ ## to ".mex".
+ ##
## @item -s|--strip
## Strip the output file.
##
*** ./scripts/miscellaneous/mex.m.orig 2006-07-26 10:04:34.208844248 +0200
--- ./scripts/miscellaneous/mex.m 2006-07-26 10:03:59.435877048 +0200
***************
*** 0 ****
--- 1,34 ----
+ ## Copyright (C) 2006 David Bateman
+ ##
+ ## This file is part of Octave.
+ ##
+ ## Octave is free software; you can redistribute it and/or modify it
+ ## under the terms of the GNU General Public License as published by
+ ## the Free Software Foundation; either version 2, or (at your option)
+ ## any later version.
+ ##
+ ## Octave is distributed in the hope that it will be useful, but
+ ## WITHOUT ANY WARRANTY; without even the implied warranty of
+ ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ ## General Public License for more details.
+ ##
+ ## You should have received a copy of the GNU General Public License
+ ## along with Octave; see the file COPYING. If not, write to the Free
+ ## Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ ## 02110-1301, USA.
+
+ ## -*- texinfo -*-
+ ## @deftypefn {Function File} {} mex [-options] file ...
+ ##
+ ## The @code{mex} function compiles source code written in C,
+ ## C++, or Fortran, to a MEX file. This is equivalent to
+ ## @code {mkoctfile [-options] --mex file}
+ ## @seealse {mkoctfile}
+ ## @end deftypefn
+
+ ## PKG_ADD: mark_as_command mex
+
+ function mex (varargin)
+ varargin{nargin+1} = "--mex";
+ mkoctfile (varargin);
+ endfunction
- some notes about mex support in Octave, John W. Eaton, 2006/07/08
- Re: some notes about mex support in Octave, Paul Kienzle, 2006/07/08
- Re: some notes about mex support in Octave, John W. Eaton, 2006/07/08
- Re: some notes about mex support in Octave, Paul Kienzle, 2006/07/08
- Re: some notes about mex support in Octave, John W. Eaton, 2006/07/22
- Re: some notes about mex support in Octave, David Bateman, 2006/07/23
- Re: some notes about mex support in Octave, David Bateman, 2006/07/25
- Re: some notes about mex support in Octave, John W. Eaton, 2006/07/25
- Re: some notes about mex support in Octave,
David Bateman <=
- Re: some notes about mex support in Octave, John W. Eaton, 2006/07/26
- Re: some notes about mex support in Octave, John W. Eaton, 2006/07/26
- Re: some notes about mex support in Octave, David Bateman, 2006/07/27