|
»
»
Segmentation fault with dbstatus
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
Segmentation fault with dbstatus
by Kristjan Onu-3
::
Rate this Message:
Bug report for Octave 3.1.51+ configured for i686-pc-linux-gnu
Description: ----------- The sequence of commands given in the Repeat-By section below leads to a segmentation fault on my system. I have observed this problem with the version of Octave checked-out of the mercurial repository a few hours ago (ie. approx Mon Sep 15 12:00 CDT 2008) as well as the version of Octave currently provided packaged Debian Testing (octave3.0, version: 1:3.0.1-6lenny1.) A GDB backtrace after the segmentation fault shows: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb50339b0 (LWP 884)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0xb74fd054 in bp_table::do_get_breakpoint_list (this=0xa16f8e0, fname_list=@0xbfa235f4) at debug.cc:316 #2 0xb74fe9fe in Fdbstatus (args=@0xbfa23868, nargout=0) at debug.h:107 #3 0xb789fd24 in octave_builtin::do_multi_index_op (this=0x9ffa598, nargout=0, args=@0xbfa23868) at ov-builtin.cc:107 #4 0xb784b5b9 in octave_value::do_multi_index_op (this=0xbfa238d4, nargout=0, idx=@0xbfa23868) at ov.cc:1076 #5 0xb79b23d1 in tree_identifier::rvalue (this=0xa138360, nargout=0) at pt-id.cc:86 #6 0xb79da949 in tree_statement::eval (this=0xa13aa18, silent=false, nargout=0, in_function_or_script_body=<value optimized out>) at pt-stmt.cc:125 #7 0xb79daf7f in tree_statement_list::eval (this=0xa1460c0, silent=76, nargout=0) at pt-stmt.cc:186 #8 0xb779b2a9 in main_loop () at toplev.cc:557 #9 0xb7735085 in octave_main (argc=3, argv=0xbfa23cc4, embedded=0) at octave.cc:853 #10 0x0804879a in main (argc=-1254468991, argv=0x0) at main.c:35 Repeat-By: --------- $ octave --norc -q octave:1> dbstop("fcn",3) octave:2> fcn debug> dbcont octave:3> system("touch fcn.m") octave:4> fcn octave:5> dbstatus The file fcn.m is: function fcn disp("Point 1") disp("Point 2") endfunction Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux Ecliptic 2.6.26-1-686 #1 SMP Thu Aug 28 12:00:54 UTC 2008 i686 GNU/Linux configure opts: '--prefix=/home/k/local' Fortran compiler: gfortran FFLAGS: -O -mieee-fp F2C: @F2C@ F2CFLAGS: @F2CFLAGS@ FLIBS: -L/usr/lib/gcc/i486-linux-gnu/4.3.1 -L/usr/lib/gcc/i486-linux-gnu/4.3.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.1/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.1 (Debian 4.3.1-9) CFLAGS: -g -O2 CPICFLAG: -fPIC C++ compiler: g++, version 4.3.1 CXXFLAGS: -g -O2 CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/home/k/local/lib/octave-3.1.51+ BLAS_LIBS: -llapack -lblas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lblas -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMA=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_STRFTIME=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs -nw EXEC_PATH = /home/k/local/libexec/octave/3.1.51+/site/exec/i686-pc-linux-gnu:/home/k/local/libexec/octave/api-v33+/site/exec/i686-pc-linux-gnu:/home/k/local/libexec/octave/site/exec/i686-pc-linux-gnu:/home/k/local/libexec/octave/3.1.51+/exec/i686-pc-linux-gnu:/home/k/local/bin:/home/k/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games IMAGE_PATH = .:/home/k/local/share/octave/3.1.51+/imagelib PAGER = less PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = <no value or error in displaying it> # gnuplot_command_plot = <no value or error in displaying it> # gnuplot_command_replot = <no value or error in displaying it> # gnuplot_command_splot = <no value or error in displaying it> # gnuplot_command_title = <no value or error in displaying it> # gnuplot_command_using = <no value or error in displaying it> # gnuplot_command_with = <no value or error in displaying it> history_file = /home/k/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /home/k/local/share/info/octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 25 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = <no value or error in displaying it> print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 struct_levels_to_print = 2 suppress_verbose_help_message = 0 _______________________________________________ Bug-octave mailing list Bug-octave@... https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave |
|
|
Re: Segmentation fault with dbstatus
by dbateman
::
Rate this Message:
Ok it is pretty clear that this is a bug in that when fcn is reparsed as the timestamp was updated the breakpoints aren't updated. However, as I don't have access to matlab at the moment I have a question about how matlab handles this situation. There are basically three things it might do in the above case 1) Clear the breakpoints when fcn is reparsed. This is a simple solution, but make successive debugging of a function difficult, as the user would then have to reinstate the breakpoints 2) Reset the breakpoints to the next nearest line. The disadvantage with this is that the user might have added code to the function and so the line number might not correspond to the same locations in the code. Worse the original breakpoint might have been advanced to skip a comment and if the code is changed it might be better to move it back towards the originally requested location. This is probably the best thing to do as it is fairly easy to implement in this manner, while still being close to a user expected behavior 3) Try to regexp between the original and modified version of the code and place the breakpoint at the nearest match to the same line. This would be really difficult to implement as it means we need to keep two copies of the function for comparison. Also its not obvious how to do the regexp. If no one else looks at this I'll try to implement 2) above. D. |
|
|
Re: Segmentation fault with dbstatus
by Jaroslav Hajek-2
::
Rate this Message:
On Wed, Sep 17, 2008 at 11:44 AM, dbateman <dbateman@...> wrote:
> > > > Kristjan Onu-3 wrote: >> >> Bug report for Octave 3.1.51+ configured for i686-pc-linux-gnu >> >> Description: >> ----------- >> >> The sequence of commands given in the Repeat-By section below leads to >> a segmentation fault on my system. I have observed this problem with >> the version of Octave checked-out of the mercurial repository a few >> hours ago (ie. approx Mon Sep 15 12:00 CDT 2008) as well as the >> version of Octave currently provided packaged Debian Testing >> (octave3.0, version: 1:3.0.1-6lenny1.) >> >> A GDB backtrace after the segmentation fault shows: >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0xb50339b0 (LWP 884)] >> 0x00000000 in ?? () >> (gdb) bt >> #0 0x00000000 in ?? () >> #1 0xb74fd054 in bp_table::do_get_breakpoint_list (this=0xa16f8e0, >> fname_list=@0xbfa235f4) at debug.cc:316 >> #2 0xb74fe9fe in Fdbstatus (args=@0xbfa23868, nargout=0) at debug.h:107 >> #3 0xb789fd24 in octave_builtin::do_multi_index_op (this=0x9ffa598, >> nargout=0, args=@0xbfa23868) at ov-builtin.cc:107 >> #4 0xb784b5b9 in octave_value::do_multi_index_op (this=0xbfa238d4, >> nargout=0, idx=@0xbfa23868) at ov.cc:1076 >> #5 0xb79b23d1 in tree_identifier::rvalue (this=0xa138360, nargout=0) at >> pt-id.cc:86 >> #6 0xb79da949 in tree_statement::eval (this=0xa13aa18, silent=false, >> nargout=0, in_function_or_script_body=<value optimized out>) at >> pt-stmt.cc:125 >> #7 0xb79daf7f in tree_statement_list::eval (this=0xa1460c0, silent=76, >> nargout=0) at pt-stmt.cc:186 >> #8 0xb779b2a9 in main_loop () at toplev.cc:557 >> #9 0xb7735085 in octave_main (argc=3, argv=0xbfa23cc4, embedded=0) at >> octave.cc:853 >> #10 0x0804879a in main (argc=-1254468991, argv=0x0) at main.c:35 >> >> Repeat-By: >> --------- >> >> $ octave --norc -q >> octave:1> dbstop("fcn",3) >> octave:2> fcn >> debug> dbcont >> octave:3> system("touch fcn.m") >> octave:4> fcn >> octave:5> dbstatus >> >> The file fcn.m is: >> function fcn >> disp("Point 1") >> disp("Point 2") >> endfunction >> > > Ok it is pretty clear that this is a bug in that when fcn is reparsed as the > timestamp was updated the breakpoints aren't updated. However, as I don't > have access to matlab at the moment I have a question about how matlab > handles this situation. There are basically three things it might do in the > above case > > 1) Clear the breakpoints when fcn is reparsed. This is a simple solution, > but make successive debugging of a function difficult, as the user would > then have to reinstate the breakpoints > > 2) Reset the breakpoints to the next nearest line. The disadvantage with > this is that the user might have added code to the function and so the line > number might not correspond to the same locations in the code. Worse the > original breakpoint might have been advanced to skip a comment and if the > code is changed it might be better to move it back towards the originally > requested location. This is probably the best thing to do as it is fairly > easy to implement in this manner, while still being close to a user expected > behavior > > 3) Try to regexp between the original and modified version of the code and > place the breakpoint at the nearest match to the same line. This would be > really difficult to implement as it means we need to keep two copies of the > function for comparison. Also its not obvious how to do the regexp. > > If no one else looks at this I'll try to implement 2) above. > > D. David, Matlab2007a appears to simply clear the breakpoints. After running Kristjan's code, dbstatus outputs nothing. cheers > > -- > View this message in context: http://www.nabble.com/Segmentation-fault-with-dbstatus-tp19501121p19527800.html > Sent from the Octave - Bugs mailing list archive at Nabble.com. > > _______________________________________________ > Bug-octave mailing list > Bug-octave@... > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -- RNDr. Jaroslav Hajek computing expert Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz _______________________________________________ Bug-octave mailing list Bug-octave@... https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave |
|
|
Re: Segmentation fault with dbstatus
by John W. Eaton
::
Rate this Message:
On 17-Sep-2008, dbateman wrote:
| Ok it is pretty clear that this is a bug in that when fcn is reparsed as the | timestamp was updated the breakpoints aren't updated. However, as I don't | have access to matlab at the moment I have a question about how matlab | handles this situation. There are basically three things it might do in the | above case | | 1) Clear the breakpoints when fcn is reparsed. This is a simple solution, | but make successive debugging of a function difficult, as the user would | then have to reinstate the breakpoints | | 2) Reset the breakpoints to the next nearest line. The disadvantage with | this is that the user might have added code to the function and so the line | number might not correspond to the same locations in the code. Worse the | original breakpoint might have been advanced to skip a comment and if the | code is changed it might be better to move it back towards the originally | requested location. This is probably the best thing to do as it is fairly | easy to implement in this manner, while still being close to a user expected | behavior | | 3) Try to regexp between the original and modified version of the code and | place the breakpoint at the nearest match to the same line. This would be | really difficult to implement as it means we need to keep two copies of the | function for comparison. Also its not obvious how to do the regexp. | | If no one else looks at this I'll try to implement 2) above. I see no reason to assume that there have been only small changes to the file since the last time breakpoints were set. So I think it is probablye best to just clear them. jwe _______________________________________________ Bug-octave mailing list Bug-octave@... https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave |
|
|
[Changeset] Re: Segmentation fault with dbstatus
by David Bateman
::
Rate this Message:
John W. Eaton wrote:
> > I see no reason to assume that there have been only small changes to > the file since the last time breakpoints were set. So I think it is > probablye best to just clear them. > > Ok, then what about the attached changeset D. -- David Bateman David.Bateman@... Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob) 91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax) The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary # HG changeset patch # User David Bateman <dbateman@...> # Date 1221812162 -7200 # Node ID e6588b4755aae3981c6bc0cfcd3cd24af32de049 # Parent 2df996b3dfe243483d1e4d4657772a3724f06d88 clear breakpoints is function found to be out of date diff --git a/src/ChangeLog b/src/ChangeLog --- a/src/ChangeLog +++ b/src/ChangeLog @@ -1,3 +1,23 @@ 2008-09-18 David Bateman <dbateman@fre +2008-09-19 David Bateman <dbateman@...> + + * debug.cc (static octave_user_code * get_user_code + (const std::string&)): Only check user code as break points can't + be set in builtins or oct-files. + (bp_table::intmap bp_table::do_remove_all_breakpoints_in_file + (const std::string&, bool)): Add flag to silence the error message + from this function if a user code with breakpoints is not found. + (bp_table::fname_line_map bp_table::do_get_breakpoint_list (const + octave_value_list&)): Do an ourt of date check on the function + before checking the breakpoints. + * debug.h (do_remove_all_breakpoints_in_file, + remove_all_breakpoints_in_file): Add flag to silence error + message. + * symtab.cc (out_of_date_check_internal): Clear breakpoints in + function if out_of_date. split into two versions taking the + octave_function pointer seperately or not. + (bool out_of_date_check (octave_function*) + * symtab.h (bool out_of_date_check (octave_function*)): New function. + 2008-09-18 David Bateman <dbateman@...> * DLD-FUNCTIONS/fftw.cc (Ffftw): Clarify the documentation. diff --git a/src/debug.cc b/src/debug.cc --- a/src/debug.cc +++ b/src/debug.cc @@ -72,7 +72,7 @@ get_user_code (const std::string& fname { octave_value fcn = symbol_table::find_function (fname); - if (fcn.is_defined ()) + if (fcn.is_defined () && fcn.is_user_code ()) dbg_fcn = fcn.user_code_value (); } @@ -238,7 +238,8 @@ bp_table::do_remove_breakpoint (const st bp_table::intmap -bp_table::do_remove_all_breakpoints_in_file (const std::string& fname) +bp_table::do_remove_all_breakpoints_in_file (const std::string& fname, + bool silent) { intmap retval; @@ -265,7 +266,7 @@ bp_table::do_remove_all_breakpoints_in_f bp_map.erase (it); } } - else + else if (! silent) error ("remove_all_breakpoint_in_file: " "unable to find the function requested\n"); @@ -313,6 +314,9 @@ bp_table::do_get_breakpoint_list (const { octave_user_code *f = it->second; + // Clears the breakpoints if the function has been updated + out_of_date_check (f); + tree_statement_list *cmds = f->body (); if (cmds) @@ -321,12 +325,15 @@ bp_table::do_get_breakpoint_list (const octave_idx_type len = bkpts.length (); - bp_table::intmap bkpts_vec; - - for (int i = 0; i < len; i++) - bkpts_vec[i] = bkpts (i).double_value (); - - retval[it->first] = bkpts_vec; + if (len > 0) + { + bp_table::intmap bkpts_vec; + + for (int i = 0; i < len; i++) + bkpts_vec[i] = bkpts (i).double_value (); + + retval[it->first] = bkpts_vec; + } } } } diff --git a/src/debug.h b/src/debug.h --- a/src/debug.h +++ b/src/debug.h @@ -85,10 +85,11 @@ public: } // Remove all the breakpoints in a specified file. - static intmap remove_all_breakpoints_in_file (const std::string& fname) + static intmap remove_all_breakpoints_in_file (const std::string& fname, + bool silent = false) { return instance_ok () - ? instance->do_remove_all_breakpoints_in_file (fname) : intmap (); + ? instance->do_remove_all_breakpoints_in_file (fname, silent) : intmap (); } // Remove all the breakpoints registered with octave. @@ -124,7 +125,8 @@ private: int do_remove_breakpoint (const std::string&, const intmap& lines); - intmap do_remove_all_breakpoints_in_file (const std::string& fname); + intmap do_remove_all_breakpoints_in_file (const std::string& fname, + bool silent); void do_remove_all_breakpoints (void); diff --git a/src/symtab.cc b/src/symtab.cc --- a/src/symtab.cc +++ b/src/symtab.cc @@ -42,6 +42,7 @@ along with Octave; see the file COPYING. #include "toplev.h" #include "unwind-prot.h" #include "utils.h" +#include "debug.h" symbol_table *symbol_table::instance = 0; @@ -151,12 +152,10 @@ load_out_of_date_fcn (const std::string& } static inline bool -out_of_date_check_internal (octave_value& function, +out_of_date_check_internal (octave_function *fcn, octave_value& function, const std::string& dispatch_type = std::string ()) { bool retval = false; - - octave_function *fcn = function.function_value (true); if (fcn) { @@ -175,6 +174,7 @@ out_of_date_check_internal (octave_value if (tc < Vlast_prompt_time || (relative && tc < Vlast_chdir_time)) { + bool clear_breakpoints = false; std::string nm = fcn->name (); int nm_len = nm.length (); @@ -207,6 +207,8 @@ out_of_date_check_internal (octave_value // directory, so we should clear it. function = octave_value (); + + clear_breakpoints = true; } else if (same_file (file, ff)) { @@ -226,11 +228,19 @@ out_of_date_check_internal (octave_value if (fs) { if (fs.is_newer (tp)) - retval = load_out_of_date_fcn (ff, dir_name, - function); + { + retval = load_out_of_date_fcn (ff, dir_name, + function); + + clear_breakpoints = true; + } } else - function = octave_value (); + { + function = octave_value (); + + clear_breakpoints = true; + } } } else @@ -239,7 +249,14 @@ out_of_date_check_internal (octave_value // place of the old. retval = load_out_of_date_fcn (file, dir_name, function); + + clear_breakpoints = true; } + + // If the function has been replaced then clear any + // breakpoints associated with it + if (clear_breakpoints) + bp_table::remove_all_breakpoints_in_file (nm, true); } } } @@ -248,10 +265,25 @@ out_of_date_check_internal (octave_value return retval; } +static inline bool +out_of_date_check_internal (octave_value& function, + const std::string& dispatch_type = std::string ()) +{ + return out_of_date_check_internal (function.function_value (true), + function, dispatch_type); +} + bool out_of_date_check (octave_value& function) { return out_of_date_check_internal (function); +} + +bool +out_of_date_check (octave_function* fcn) +{ + octave_value function; + return out_of_date_check_internal (fcn, function); } octave_value diff --git a/src/symtab.h b/src/symtab.h --- a/src/symtab.h +++ b/src/symtab.h @@ -2292,6 +2292,8 @@ private: extern bool out_of_date_check (octave_value& function); +extern bool out_of_date_check (octave_function* fcn); + #endif /* _______________________________________________ Bug-octave mailing list Bug-octave@... https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave |
|
|
Re: [Changeset] Re: Segmentation fault with dbstatus
by Kristjan Onu-3
::
Rate this Message:
David Bateman wrote:
> Ok, then what about the attached changeset I applied this changeset and it fixes the segmentation fault problem I originally experienced. Thank you, Kristjan _______________________________________________ Bug-octave mailing list Bug-octave@... https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave |
|
|
[Changeset] Re: Segmentation fault with dbstatus
by John W. Eaton
::
Rate this Message:
On 19-Sep-2008, David Bateman wrote:
| John W. Eaton wrote: | > | > I see no reason to assume that there have been only small changes to | > the file since the last time breakpoints were set. So I think it is | > probablye best to just clear them. | > | > | | Ok, then what about the attached changeset I applied it. Thanks, jwe _______________________________________________ Bug-octave mailing list Bug-octave@... https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave |
| Free embeddable forum powered by Nabble | Forum Help |
