[Octave-bug-tracker] [bug #47372] Memory leaks and segmentation faults in Octave

[Rik]

Update of bug #47372 (project octave):

                  Status:                   Fixed => In Progress            
             Open/Closed:                  Closed => Open                   

    _______________________________________________________

Follow-up Comment #112:

I've been pressing on with the search for leaks.  Up until now I have disabled
opengl during configure.  I just enabled it, re-built, and tried "plot (1:10)"
which resulted in a use-after-free error from AddressSanitizer and the
immediate halt of Octave.  I guess there is more to be done...

In this case, it seems that octave_env::set_program_name is to blame because I
commented it out and provided a static string and now it works. 


diff -r e3888aa9a4d1 libinterp/octave.cc
--- a/libinterp/octave.cc       Thu Apr 07 15:55:10 2016 -0700
+++ b/libinterp/octave.cc       Fri Apr 08 14:19:14 2016 -0700
@@ -786,7 +786,8 @@ octave_initialize_interpreter (int argc,
 
   octave_embedded = embedded;
 
-  octave_env::set_program_name (argv[0]);
+  //octave_env::set_program_name (argv[0]);
+  octave_env::set_program_name ("foobar");
 
   octave_program_invocation_name = octave_env::get_program_invocation_name
();
   octave_program_name = octave_env::get_program_name ();


With that done, I can now find new, ugly memory violations.

For instance, 


demo ("colorbar", 5)


which always causes a heap-buffer-overflow error for me.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47372>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/