[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
is_defined() again [Was: Follow up on profiler development]
From: |
John W. Eaton |
Subject: |
is_defined() again [Was: Follow up on profiler development] |
Date: |
Wed, 10 Aug 2011 11:18:23 -0400 |
On 10-Aug-2011, Daniel Kraft wrote:
| I just observed an "interesting" segfault while working on hierarchical
| profiling (but it happens as well with the version without my work in
| progress):
|
| Running "demo profshow" three times in a row makes Octave segfault --
| but GDB shows that the segfault happens not inside some profiler data
| collection routine (which I first thought, since I reworked them for
| hierarchical profiling) but rather with is_defined(). This routine
| becomes more and more mystical to me over time! :D
|
| Any ideas? But until the problem occurs in a more "direct" situation,
| I'll defer this to later. (Of course, maybe it is still a problem with
| my profiler code which corrupts some memory but leads only later to a
| segfault ... or something. Maybe I'll try to run Octave through
| valgrind to find that out -- any experience with that? Does it work?)
I can duplicate the problem.
You can run Octave with valgrind using
./run-octave -valgrind
When I do this and run "demo profshow" three times, I see the
following output the third time demo is evaluated:
octave:3> demo profshow
==13184== Use of uninitialised value of size 8
==13184== at 0x4F8DD31: octave_value::is_defined() const (ov.h:492)
==13184== by 0x5240F58:
symbol_table::fcn_info::fcn_info_rep::xfind(octave_value_list const&, bool)
(symtab.cc:758)
==13184== by 0x524063F:
symbol_table::fcn_info::fcn_info_rep::find(octave_value_list const&, bool)
(symtab.cc:590)
==13184== by 0x5244C0D: symbol_table::fcn_info::find(octave_value_list
const&, bool) (symtab.h:775)
==13184== by 0x523E90F:
symbol_table::symbol_record::find(octave_value_list const&) const
(symtab.cc:112)
==13184== by 0x53BDA43: tree_identifier::rvalue(int) (pt-id.cc:66)
==13184== by 0x53BDCD1: tree_identifier::rvalue1(int) (pt-id.cc:106)
==13184== by 0x53BAA96: tree_evaluator::visit_statement(tree_statement&)
(pt-eval.cc:737)
==13184== by 0x53D5D55: tree_statement::accept(tree_walker&)
(pt-stmt.cc:151)
==13184== by 0x53BAC5A:
tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:773)
==13184== by 0x53D60BD: tree_statement_list::accept(tree_walker&)
(pt-stmt.cc:215)
==13184== by 0x53BB07B:
tree_evaluator::visit_try_catch_command(tree_try_catch_command&)
(pt-eval.cc:889)
==13184==
==13184== Jump to the invalid address stated on the next line
==13184== at 0x1B990: ???
==13184== by 0x5240F58:
symbol_table::fcn_info::fcn_info_rep::xfind(octave_value_list const&, bool)
(symtab.cc:758)
==13184== by 0x524063F:
symbol_table::fcn_info::fcn_info_rep::find(octave_value_list const&, bool)
(symtab.cc:590)
==13184== by 0x5244C0D: symbol_table::fcn_info::find(octave_value_list
const&, bool) (symtab.h:775)
==13184== by 0x523E90F:
symbol_table::symbol_record::find(octave_value_list const&) const
(symtab.cc:112)
==13184== by 0x53BDA43: tree_identifier::rvalue(int) (pt-id.cc:66)
==13184== by 0x53BDCD1: tree_identifier::rvalue1(int) (pt-id.cc:106)
==13184== by 0x53BAA96: tree_evaluator::visit_statement(tree_statement&)
(pt-eval.cc:737)
==13184== by 0x53D5D55: tree_statement::accept(tree_walker&)
(pt-stmt.cc:151)
==13184== by 0x53BAC5A:
tree_evaluator::visit_statement_list(tree_statement_list&) (pt-eval.cc:773)
==13184== by 0x53D60BD: tree_statement_list::accept(tree_walker&)
(pt-stmt.cc:215)
==13184== by 0x53BB07B:
tree_evaluator::visit_try_catch_command(tree_try_catch_command&)
(pt-eval.cc:889)
==13184== Address 0x1b990 is not stack'd, malloc'd or (recently) free'd
==13184==
panic: Segmentation fault -- stopping myself...
==13184==
==13184== HEAP SUMMARY:
==13184== in use at exit: 41,948,257 bytes in 93,139 blocks
==13184== total heap usage: 2,286,504 allocs, 2,193,365 frees, 151,312,779
bytes allocated
==13184==
==13184== LEAK SUMMARY:
==13184== definitely lost: 612 bytes in 70 blocks
==13184== indirectly lost: 240 bytes in 10 blocks
==13184== possibly lost: 4,049,707 bytes in 71,218 blocks
==13184== still reachable: 37,897,698 bytes in 21,841 blocks
==13184== suppressed: 0 bytes in 0 blocks
==13184== Rerun with --leak-check=full to see details of leaked memory
==13184==
==13184== For counts of detected and suppressed errors, rerun with: -v
==13184== Use --track-origins=yes to see where uninitialised values come from
==13184== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 22 from 7)
Segmentation fault
jwe