global variables and oct files

View: New views
2 Messages — Rating Filter:   Alert me  

global variables and oct files

by Xavier Delacour :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I am having some difficulty creating an oct-file that defines a custom
type (octave_base_value derivative) and installs an instance of it as
a global variable. Working with revision 9252:a1d20052517a
(release-3-2-0 tag), here is a small self-contained example:

------ BEGIN global_test.cc
// g++ -g -c -Wno-long-double global_test.cc && g++ -bundle -undefined
suppress -flat_namespace -g -Wno-long-double global_test.o -o
global_test.oct

#include <octave/oct.h>
#include <octave/parse.h>

class test_type:public octave_base_value {
public:
  test_type() {
  }
  octave_base_value *clone() const {
    return new test_type(*this);
  }
  octave_base_value *empty_clone() const {
    return new test_type();
  }
  bool is_defined() const {
    return true;
  }
  void print(std::ostream &os, bool pr_as_read_syntax = false) const {
  }
private:
  DECLARE_OCTAVE_ALLOCATOR;
  DECLARE_OV_TYPEID_FUNCTIONS_AND_DATA;
};
DEFINE_OCTAVE_ALLOCATOR(test_type);
DEFINE_OV_TYPEID_FUNCTIONS_AND_DATA(test_type, "test_type", "test_type");

DEFUN_DLD (global_test,args,nargout,"global_test") {
  test_type::register_type();
  set_global_value("test_global_var",new test_type);
  mlock();
  return octave_value_list();
}
------ END global_test.cc

------ BEGIN global_test_runme.m
global_test
who global
# who output contains test_global_var
clear -g
who global
# bug? who output still contains test_global_var
------ END global_test_runme.m

Running octave -q global_test_runme.m results in segfault at exit:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x008dc0ec
0x011cf705 in ~octave_value [inlined] () at ov.h:295
295      delete rep;
(gdb) bt
#0  0x011cf705 in ~octave_value [inlined] () at ov.h:295
#1  0x011cf705 in ~octave_value [inlined] () at ov.h:296
#2  0x011cf705 in ~pair [inlined] () at ov.h:69
#3  0x011cf705 in __gnu_cxx::new_allocator<std::pair<std::string
const, octave_value> >::destroy () at ov.h:107
#4  0x011cf705 in ~pair [inlined] () at ov.h:389
#5  0x011cf705 in ~pair [inlined] () at ov.h:389
#6  0x011cf705 in std::_Rb_tree<std::string, std::pair<std::string
const, octave_value>, std::_Select1st<std::pair<std::string const,
octave_value> >, std::less<std::string>,
std::allocator<std::pair<std::string const, octave_value> >
>::_M_erase (this=0x1e26958, __x=0x6029c70) at defun.cc:69
#7  0x01481055 in __tcf_7 () at defun.cc:69
#8  0x93d2bdbc in __cxa_finalize ()
#9  0x93d2bcb0 in exit ()
#10 0x01411a1b in octave_main (argc=3, argv=0xbffff3b8, embedded=0) at
defun.cc:69
#11 0x00001ffe in main ()
#12 0x00001fb2 in start ()

So in other words, octave has unloaded my .oct file before calling my
instance's destructor. Also as noted in global_test_runme.m comment,
clear -g does not actually remove my variable.

I'm not sure if this is a bug or incorrect usage of the API. Any
suggestions would be much appreciated.

For purposes of fixing swig-related crashes, it would be preferable to
make the above example work. However, removing all globals (and
returning octave_value pointing to created object) works fine and
produces no crashes (ie, assign global_test result to local variable;
apparently that gets cleared properly before unloading oct-files).
Unfortunately that would have the side effect of forcing all
swig-defined symbols to appear under a struct/namespace object (eg,
ns.ann_func() rather than just ann_func()).

Thanks,
Xavier
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: global variables and oct files

by Xavier Delacour :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sun, Jul 5, 2009 at 1:35 PM, Xavier
Delacour<xavier.delacour@...> wrote:
> I am having some difficulty creating an oct-file that defines a custom
> type (octave_base_value derivative) and installs an instance of it as
> a global variable. Working with revision 9252:a1d20052517a
> (release-3-2-0 tag), here is a small self-contained example:

The first issue, that clear -g doesn't remove the variable, appears to
be fixed on tip (9419:0dd3c7a2ba19). The crash on exit still exists
(same stacktrace). If I run clear -g before exiting, it doesn't crash.

Xavier

>
> ------ BEGIN global_test.cc
> // g++ -g -c -Wno-long-double global_test.cc && g++ -bundle -undefined
> suppress -flat_namespace -g -Wno-long-double global_test.o -o
> global_test.oct
>
> #include <octave/oct.h>
> #include <octave/parse.h>
>
> class test_type:public octave_base_value {
> public:
>  test_type() {
>  }
>  octave_base_value *clone() const {
>    return new test_type(*this);
>  }
>  octave_base_value *empty_clone() const {
>    return new test_type();
>  }
>  bool is_defined() const {
>    return true;
>  }
>  void print(std::ostream &os, bool pr_as_read_syntax = false) const {
>  }
> private:
>  DECLARE_OCTAVE_ALLOCATOR;
>  DECLARE_OV_TYPEID_FUNCTIONS_AND_DATA;
> };
> DEFINE_OCTAVE_ALLOCATOR(test_type);
> DEFINE_OV_TYPEID_FUNCTIONS_AND_DATA(test_type, "test_type", "test_type");
>
> DEFUN_DLD (global_test,args,nargout,"global_test") {
>  test_type::register_type();
>  set_global_value("test_global_var",new test_type);
>  mlock();
>  return octave_value_list();
> }
> ------ END global_test.cc
>
> ------ BEGIN global_test_runme.m
> global_test
> who global
> # who output contains test_global_var
> clear -g
> who global
> # bug? who output still contains test_global_var
> ------ END global_test_runme.m
>
> Running octave -q global_test_runme.m results in segfault at exit:
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x008dc0ec
> 0x011cf705 in ~octave_value [inlined] () at ov.h:295
> 295           delete rep;
> (gdb) bt
> #0  0x011cf705 in ~octave_value [inlined] () at ov.h:295
> #1  0x011cf705 in ~octave_value [inlined] () at ov.h:296
> #2  0x011cf705 in ~pair [inlined] () at ov.h:69
> #3  0x011cf705 in __gnu_cxx::new_allocator<std::pair<std::string
> const, octave_value> >::destroy () at ov.h:107
> #4  0x011cf705 in ~pair [inlined] () at ov.h:389
> #5  0x011cf705 in ~pair [inlined] () at ov.h:389
> #6  0x011cf705 in std::_Rb_tree<std::string, std::pair<std::string
> const, octave_value>, std::_Select1st<std::pair<std::string const,
> octave_value> >, std::less<std::string>,
> std::allocator<std::pair<std::string const, octave_value> >
>>::_M_erase (this=0x1e26958, __x=0x6029c70) at defun.cc:69
> #7  0x01481055 in __tcf_7 () at defun.cc:69
> #8  0x93d2bdbc in __cxa_finalize ()
> #9  0x93d2bcb0 in exit ()
> #10 0x01411a1b in octave_main (argc=3, argv=0xbffff3b8, embedded=0) at
> defun.cc:69
> #11 0x00001ffe in main ()
> #12 0x00001fb2 in start ()
>
> So in other words, octave has unloaded my .oct file before calling my
> instance's destructor. Also as noted in global_test_runme.m comment,
> clear -g does not actually remove my variable.
>
> I'm not sure if this is a bug or incorrect usage of the API. Any
> suggestions would be much appreciated.
>
> For purposes of fixing swig-related crashes, it would be preferable to
> make the above example work. However, removing all globals (and
> returning octave_value pointing to created object) works fine and
> produces no crashes (ie, assign global_test result to local variable;
> apparently that gets cleared properly before unloading oct-files).
> Unfortunately that would have the side effect of forcing all
> swig-defined symbols to appear under a struct/namespace object (eg,
> ns.ann_func() rather than just ann_func()).
>
> Thanks,
> Xavier
>

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave