octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bus-error


From: Ben Abbott
Subject: Re: Bus-error
Date: Fri, 01 Oct 2010 11:43:17 -0400

On Oct 1, 2010, at 2:44 AM, Jaroslav Hajek wrote:

> 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.

I get the same result. I'll try to isolate the problem by bisecting as John 
suggested. If that doesn't indicate a specific changset, I'll back them out one 
at a time and make note of the backtrace in each instance. 

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=0xbfffacb8, 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=0x4136a90, address@hidden, 
at_end=true, warn=false) at file-stat.h:626
#6  0x002a666d in load_path::do_append (this=0x4136a90, address@hidden, 
warn=126) at load-path.cc:599
#7  0x002a6724 in load_path::do_set (this=0x4136a90, address@hidden, 
warn=false) at load-path.cc:578
#8  0x002a6ab5 in load_path::do_initialize (this=0x4136a90, 
set_initial_path=false) at load-path.cc:516
#9  0x003ac0e5 in octave_main (argc=6, argv=0xbfffafb8, embedded=0) at 
load-path.h:53
#10 0x00001f80 in main (argc=6, argv=0xbfffafb8) at main.c:35

Ben





reply via email to

[Prev in Thread] Current Thread [Next in Thread]