Re: Bus-error

[Jaroslav Hajek]

On Thu, Sep 30, 2010 at 10:51 PM, bpabbott <address@hidden> wrote:
> On Sep 30, 2010, at 04:05 PM, Jaroslav Hajek <address@hidden> wrote:
>
> On Thu, Sep 30, 2010 at 9:44 PM, John W. Eaton <address@hidden> wrote:
>> On 30-Sep-2010, bpabbott wrote:
>>
>> | With that change I still have a problem.
>> |
>> | ../../run-octave -f -q -H ./mk_doc_cache.m doc-cache
>> ../../scripts/DOCSTRINGS
>> | ../../src/DOCSTRINGS || { rm -f doc-cache; exit 1; }
>> | octave(54771,0xa07db500) malloc: *** error for object 0xe48fb8: pointer
>> being
>> | freed was not allocated
>> | *** set a breakpoint in malloc_error_break to debug
>> | error: octave_map::setfield: internal error
>> | error: octave_map::setfield: internal error
>> | octave(54771,0xa07db500) malloc: *** error for object 0xe48fb8: pointer
>> being
>> | freed was not allocated
>> | *** set a breakpoint in malloc_error_break to debug
>> |
>> | panic: Segmentation fault -- stopping myself...
>> | attempting to save variables to `octave-core'...
>> | panic: attempted clean up apparently failed -- aborting...
>> | /bin/sh: line 1: 54771 Abort trap              ../../run-octave -f -q -H
>> ./
>> | mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS
>> | make[3]: *** [doc-cache] Error 1
>> | make[2]: *** [all-recursive] Error 1
>> | make[1]: *** [all-recursive] Error 1
>> | make: *** [all] Error 2
>>
>> This does not fail for me, and running the mk_doc_cache script with
>> Octave under valgrind doesn't show anything unusual, so I have no
>> clue where to look.  Unless Jaroslav sees what the problem is, I guess
>> the next step would be to bisect and find which of the recent changes
>> related to Octave_map -> octave_(scalar_|)map caused the problem to
>> appear for you.  That might point us in the right direction.
>>
>> jwe
>>
>
> I suspect this is another SID. Ben's Mac OS is apparently good at
> catching those :)
> Ben, please pull this patch and try again:
> http://hg.savannah.gnu.org/hgweb/octave/rev/b0eec300d3fc
>
> This is with you change and "octave_map" in octave.cc
> touch .DOCSTRINGS
> Making all in scripts
> making plot/gnuplot_binary.m from plot/gnuplot_binary.in
> plot/gnuplot_binary.m is unchanged
> Making all in doc
> Making all in faq
> make[3]: Nothing to be done for `all'.
> Making all in interpreter
> ../../run-octave -f -q -H ./mk_doc_cache.m doc-cache
> ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS || { rm -f doc-cache; exit 1;
> }
> panic: Segmentation fault -- stopping myself...
> attempting to save variables to `octave-core'...
> save to `octave-core' complete
> /bin/sh: line 1: 89239 Segmentation fault      ../../run-octave -f -q -H
> ./mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS
> make[3]: *** [doc-cache] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> From the debugger ....
> bens-macbook:interpreter bpabbott$ ../../run-octave -g -f -q -H
> ./mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS ||
> { rm -f doc-cache; exit 1; }
> GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May  5 04:36:56 UTC
> 2010)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
> shared libraries .............
> warning: Could not find object file
> "/sw/src/fink.build/freetype219-2.3.12-1/freetype-2.3.12/objs/.libs/ftsystem.o"
> - no debug information available for "builds/unix/ftsystem.c"
> SNIP
> ........ done
> (gdb) run
> Starting program:
> /Users/bpabbott/Development/mercurial/local_clone/src/.libs/octave
> --no-init-path --path=...
> Reading symbols for shared libraries
> .++++++++++++++++++++..............................................................................................
> done
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0xfffffff4
> 0x903a40c1 in std::string::find ()
> (gdb) bt
> #0  0x903a40c1 in std::string::find ()
> #1  0x0131a7e1 in file_ops::tilde_expand (address@hidden) at
> file-ops.cc:280
> #2  0x0131bc48 in file_stat::update_internal (this=0xbfffabe8, force=false)
> at file-stat.cc:189
> #3  0x002a5d24 in file_stat [inlined] () at file-stat.h:209
> #4  0x002a5d24 in file_stat [inlined] () at
> /Users/bpabbott/Development/mercurial/local_clone/liboctave/file-stat.h:210
> #5  0x002a5d24 in load_path::do_add (this=0x4036a50, address@hidden,
> at_end=true, warn=false) at file-stat.h:626
> #6  0x002a666d in load_path::do_append (this=0x4036a50, address@hidden,
> warn=126) at load-path.cc:599
> #7  0x002a6724 in load_path::do_set (this=0x4036a50, address@hidden,
> warn=false) at load-path.cc:578
> #8  0x002a6ab5 in load_path::do_initialize (this=0x4036a50,
> set_initial_path=false) at load-path.cc:516
> #9  0x003ac0e5 in octave_main (argc=13, argv=0xbfffaef4, embedded=0) at
> load-path.h:53
> #10 0x00001f80 in main (argc=13, argv=0xbfffaef4) at main.c:35
> (gdb)
> Ben
>

OK, this isn't getting us anywhere. octave_map and octave_scalar_map
are not even used in load-path.cc, so this now appears to have nothing
to do with the map changes. What happens if you just start
./run-octave -g and exit? Does it work normally? If so, then please
try to isolate the part of mk_doc_cache that causes the problem.


-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz