[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3.6.0 release
From: |
Ben Abbott |
Subject: |
Re: 3.6.0 release |
Date: |
Tue, 29 Nov 2011 20:39:43 -0500 |
On Nov 29, 2011, at 7:00 PM, John W. Eaton wrote:
> 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
I ran the legend demos on MacOS. All work correctly for me with the above
change.
Ben
- Re: 3.6.0 release, (continued)
- Re: 3.6.0 release, logari81, 2011/11/29
- Re: 3.6.0 release, Michael Goffioul, 2011/11/29
- Re: 3.6.0 release, John W. Eaton, 2011/11/29
- Re: 3.6.0 release, Michael D Godfrey, 2011/11/29
- Re: 3.6.0 release, Michael D Godfrey, 2011/11/29
- Re: 3.6.0 release, Michael Goffioul, 2011/11/29
- Re: 3.6.0 release, John W. Eaton, 2011/11/29
- Re: 3.6.0 release,
Ben Abbott <=
- Re: 3.6.0 release, Tatsuro MATSUOKA, 2011/11/29
Re: 3.6.0 release, PhilipNienhuis, 2011/11/28