Re: 3.6.0 release

[John W. Eaton]

On 29-Nov-2011, John W. Eaton wrote:

| Absolutely, this can't be the fix.  But when I run with valgrind with
| and without the above change, nothing obvious about uninitialized
| memory pops up.  However, there are some messages related to
| fontconfig (I think) in both cases.  I'll check again and try to send
| details later.

Great, now when I do "./run-octave -valgrind" and execute
"graphics_toolkit fltk; demo legend", the legend text appears.
Without valgrind, it does not.  So definitely some kind of memory
error.

OK, looking again at the valgrind output, the following seems to point
to the problem:

==30890== Invalid read of size 8
==30890==    at 0x53CBD20: Array<double>::xelem(int) const (Array.h:322)
==30890==    by 0x53BD035: Array<double>::elem(int) const (Array.h:377)
==30890==    by 0x53B4CE7: Array<double>::operator()(int) const (Array.h:392)
==30890==    by 0x540D7FA: opengl_renderer::draw_text(text::properties const&) 
(gl-render.cc:2471)
==30890==    by 0x53FF234: opengl_renderer::draw(graphics_object const&, bool) 
(gl-render.cc:567)
==30890==    by 0x5404169: opengl_renderer::draw_axes_children(axes::properties 
const&) (gl-render.cc:1362)
==30890==    by 0x54045EE: opengl_renderer::draw_axes(axes::properties const&) 
(gl-render.cc:1417)
==30890==    by 0x53FEE92: opengl_renderer::draw(graphics_object const&, bool) 
(gl-render.cc:557)
==30890==    by 0x5414B19: opengl_renderer::draw(Matrix const&, bool) 
(gl-render.h:73)
==30890==    by 0x53FFB42: opengl_renderer::draw_figure(figure::properties 
const&) (gl-render.cc:597)
==30890==    by 0x53FEDD8: opengl_renderer::draw(graphics_object const&, bool) 
(gl-render.cc:555)
==30890==    by 0x15389D25: OpenGL_fltk::draw() (__init_fltk__.cc:188)
==30890==  Address 0x16daa1d0 is 0 bytes after a block of size 16 alloc'd
==30890==    at 0x4C26CF7: operator new[](unsigned long) (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30890==    by 0x537EBEB: double* no_ctor_new<double>(unsigned long) 
(oct-mem.h:131)
==30890==    by 0x53BE061: Array<double>::ArrayRep::ArrayRep(int) (Array.h:80)
==30890==    by 0x662CACF: Array<double>::clear(dim_vector const&) 
(Array.cc:105)
==30890==    by 0x5827200: void single_type_concat<NDArray, 
double>(Array<double>&, dim_vector const&, tm_const&) (pt-mat.cc:786)
==30890==    by 0x5826013: octave_value 
do_single_type_concat<NDArray>(dim_vector const&, tm_const&) (pt-mat.cc:905)
==30890==    by 0x5824325: tree_matrix::rvalue1(int) (pt-mat.cc:1010)
==30890==    by 0x580D5FB: 
tree_argument_list::convert_to_const_vector(octave_value const*) 
(pt-arg-list.cc:201)
==30890==    by 0x581E1A4: tree_index_expression::rvalue(int, 
std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) (pt-idx.cc:308)
==30890==    by 0x581DF9E: tree_index_expression::rvalue(int) (pt-idx.cc:277)
==30890==    by 0x581EAA9: tree_index_expression::rvalue1(int) (pt-idx.cc:418)
==30890==    by 0x581944E: tree_evaluator::visit_statement(tree_statement&) 
(pt-eval.cc:739)
==30890== 

I checked in the following change, which seems to fix the problem for
me.

  http://hg.savannah.gnu.org/hgweb/octave/rev/0fea4cf22f88

jwe