help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: global variables and oct files


From: Xavier Delacour
Subject: Re: global variables and oct files
Date: Sun, 5 Jul 2009 15:34:14 -0700

On Sun, Jul 5, 2009 at 1:35 PM, Xavier
Delacour<address@hidden> 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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]