bugGNU Octave - Bugs: bug #53241, .gdbinit macros for Octave...

 
 

bug #53241: .gdbinit macros for Octave debugging no longer work

Submitter:  Rik <rik5>
Submitted:  Wed 28 Feb 2018 12:10:53 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 06 Mar 2018 09:55:19 PM UTC, comment #14: 

I meant, Why would gdb pick a syntax with such an easy source of confusion?  Accidentally leaving a space after what one thinks is a continuation character is the worse scenario.

Dan Sebald <sebald>
Tue 06 Mar 2018 09:27:54 PM UTC, comment #13: 

Dan,

The point of that backslash is not to be a continuation.  That's not needed.  It's to put a space after the '=' character.  I suppose printf could be used.

John W. Eaton <jwe>
Group administrator
Tue 06 Mar 2018 08:20:44 PM UTC, comment #12: 

Things seem to work now so I will close this bug report.

However, there are still little oddities.  When using show-octave-dbstack, the output appears not in the window running gdb, but back in the terminal window that is running the Octave process being debugged.  Also, the indicator that shows which function is active in the stack trace is off by one.  This could potentially lead to debugging errors.  For example, I used this test script blah.m


function blah ()
  subfunc1 ();
endfunction

function subfunc1 ()
  subfunc2 ();
endfunction

function subfunc2 ()
  x = magic (3);
  y = x ^ 2;
endfunction


I then set a breakpoint in gdb at xpow.cc:204.  When I execute blah() in Octave, and then show-octave-dbstack in gdb, I get


stopped in:

      blah>subfunc2 at line 11 [/home/rik/wip/Projects_Mine/octave-dbg/blah.m]
  --> blah>subfunc1 at line 6 [/home/rik/wip/Projects_Mine/octave-dbg/blah.m]
               blah at line 2 [/home/rik/wip/Projects_Mine/octave-dbg/blah.m]


This is another small niggle, but the reference count on an array object is shown twice.  Here is the array "magic (3)" displayed with the macro display-dense-array:


array object: (const Matrix &) @0x7ffeb39ebe90: {<NDArray> = {<MArray<double>> = {<Array<double>> = {_vptr.Array = 0x7f0fd1f639b0 <vtable for Matrix+16>, dimensions = {
          rep = 0x2197880}, rep = 0x1e689c0, slice_data = 0x2252c20,
        slice_len = 9}, <No data fields>}, <No data fields>}, <No data fields>}
dimensions:
ndims: 2
dims: {3, 3}

rep = {data = 0x2252c20, len = 9, count = {count = 2}}
rep.data = {8, 3, 4, 1, 5, 9, 6, 7, 2}


We could change the macro to actually print &rep.data, rep.len, and rep.count.count to avoid this rather than, the admittedly easy:


  output *$arg0.rep


The macro for display-sparse-array works, but seems awkward.  This is the display of "sparse (magic (3))"



sparse object: (const SparseMatrix &) @0x7ffeb39ebe90: {<MSparse<double>> = {<Sparse<double>> = {_vptr.Sparse = 0x7f0fd1f63890 <vtable for SparseMatrix+16>, rep = 0x20e92e0,
      dimensions = {rep = 0x2254780}}, <No data fields>}, <No data fields>}
dimensions.rep[0] = ndims: 2
dims: {3, 3}

dimensions.rep[1] = 3
rep = {d = 0x20796a0, r = 0x2101e60, c = 0x2279b00, nzmx = 9, nrows = 3, ncols = 3,
  count = {count = 2}}
rep.d = {8, 3, 4, 1, 5, 9, 6, 7, 2}
rep.r = {0, 1, 2, 0, 1, 2, 0, 1, 2}
rep.c = {0, 3, 6, 9}


It seems like the macro could just print "dimensions:\n" as the dense array macro does followed by display-dims.



Rik <rik5>
Group administrator
Tue 06 Mar 2018 07:46:20 PM UTC, comment #11: 

Oh, this 'echo':

https://sourceware.org/gdb/onlinedocs/gdb/Output.html#Output

That's kind of an odd choice for end of line: '\ ' means space while '\' means continuation.

There is also a more C-like 'printf' just after the 'echo' and 'output' commands in the documentation.  Could one simply use that without any arguments, rather than 'echo'?  E.g.,


  printf "\nrep =  "


Dan Sebald <sebald>
Tue 06 Mar 2018 07:22:43 PM UTC, comment #10: 

Dan, this is not a shell script.  It's interpreted by gdb, which has its own set of rules.

John W. Eaton <jwe>
Group administrator
Tue 06 Mar 2018 07:18:02 PM UTC, comment #9: 

Ah, the backslashes are meant to be escape codes.  Leave out the '\' then, I guess.  What does something like this do?

echo \n

The '\' is ignored by the echo command.  Or is that \n first interpreted as a newline by the script file before being passed to echo?  Confusing.

Dan Sebald <sebald>
Tue 06 Mar 2018 06:47:21 PM UTC, comment #8: 

echo accepts quotations on my system:


linux@ ~/octave/bug/53275 $ echo "ndims: \ "
ndims: \
linux@ ~/octave/bug/53275 $


In the verbatim above, note that the space after the reverse-slash is present.  That should get rid of the trailing whitespace.  (Not sure about MXE, etc.)

Dan Sebald <sebald>
Tue 06 Mar 2018 06:37:37 PM UTC, comment #7: 

For the original problem, I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/578ebece3dc7

Yes, the problem seems to have been caused by stripping the trailing spaces.  I added a note about that so maybe it won't happen again.

Rik, please close this report if this change fixes the problem for you.

John W. Eaton <jwe>
Group administrator
Tue 06 Mar 2018 06:18:47 PM UTC, comment #6: 

When I wrote the rule to avoid overwriting .gdbinit, I was trying to prevent wiping out local changes that had been made by hand.  That still seems to me like a friendly thing to do.

As far as I can tell, this rule should only be triggered if the file in the source tree is newer than the one in the build tree.  How does that happen?  Are you cloning a new source tree without also wiping out the build tree?  Or does it happen because of some other hg commands?

In any case, I suppose there is no need to complain about copying the file and updating the timestamp if the files are the same.

I don't remember why we copy the file to two different places.  Maybe because all the tests used to be in the test directory?  But that was long ago.  It's probably sufficient just to copy it to the same directory where run-octave is installed.

I pushed this changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/fc21ac9cd998

John W. Eaton <jwe>
Group administrator
Wed 28 Feb 2018 04:40:32 PM UTC, comment #5: 

I have customized my .gdbinit in the toplevel directory and it is never overwritten.  The only thing is that if I do 'make maintainer-clean' it gets blown away and then I have to modify it again after it is re-installed.

I don't think there is much, if anything, wrong with our installation procedures for gdbinit.  The pressing issue for me is that the macros themselves don't work.

Rik <rik5>
Group administrator
Wed 28 Feb 2018 04:31:27 AM UTC, comment #4: 

Are we concerned about overwriting an existing $(toplevel)/.gdbinit and $(toplevel)/test/.gdbinit then?  (Although, I'm not seeing a $(toplevel)/.gdbinit.)  A person's account gdbinit will be in ~/.gdbinit and the only way for that to be overwritten is if the build directory is ~.  Is that likely to happen?  Would someone start editing $(toplevel)/test/.gdbinit expecting it not to be overwritten even if an "hg pull" updates $(srcdir)/etc/gdbinit?

Dan Sebald <sebald>
Wed 28 Feb 2018 01:49:23 AM UTC, comment #3: 

Octave's make just copies $(srcdir)/etc/gdbinit into $(toplevel)/.gdbinit and into $(toplevel)/test/.gdbinit. It is only in the build tree for the purposes of debugging using the run-octave wrapper. It is not installed anywhere by 'make install'.

Mike Miller <mtmiller>
Group Member
Wed 28 Feb 2018 01:46:59 AM UTC, comment #2: 

Where are you placing the .gdbinit file?  I'm just curious because during repeated building there is always this message


refusing to overwrite test/.gdbinit with newer version from /home/usr3/octave/octave/octave/etc/gdbinit
libinterp/parse-tree/oct-parse.output is unchanged
refusing to overwrite .gdbinit with newer version from /home/usr3/octave/octave/octave/etc/gdbinit


which isn't an error or warning, it is simply a statement that the .gdbinit file isn't going to be written into the build directory because of a pre-existing .gdbinit file.  Is this a natural location for a .gdbinit file to be, i.e., the build directory test/.gdbinit?  Is there a test procedure that is performed during build that requires a .gdbinit file to be there?  During "make install" does that .gdbinit file get placed in some system-wide location?  Is there a consequence to always overwriting .gdbinit file if someone has such information typically stored elsewhere?

Links to common locations for .gdbinit files is given here:

https://savannah.gnu.org/bugs/?50285#comment4

Dan Sebald <sebald>
Wed 28 Feb 2018 12:18:18 AM UTC, comment #1: 

The recent Mercurial history for etc/gdbinit is


changeset:   24537:11729ca6eb81
user:        Rik <rik@octave.org>
date:        Sat Jan 06 13:48:58 2018 -0800
summary:     Add GPL license header to more Octave source files.

changeset:   23083:e9a0469dedd9
branch:      stable
user:        John W. Eaton <jwe@octave.org>
date:        Fri Jan 20 12:19:08 2017 -0500
summary:     maint: strip extra trailing newlines from files.

changeset:   18898:446c46af4b42
branch:      stable
parent:      18759:8dbd55742112
user:        John W. Eaton <jwe@octave.org>
date:        Tue Jan 20 08:26:57 2015 -0500
summary:     strip trailing whitespace from most source files

changeset:   15908:2c11d7c6cc21
user:        John W. Eaton <jwe@octave.org>
date:        Fri May 03 00:27:55 2013 -0400
summary:     turn off gdb thread messages by default


If I go back to cset 15908 then display-dense-array works.  display-dims is still a little off.  Perhaps the macros in gdb need certain amounts of trailing whitespace in order to function.

Rik <rik5>
Group administrator
Wed 28 Feb 2018 12:10:53 AM UTC, original submission:  

I just tried to use gdb to display an array when debugging Octave and I get strange results


display-dense-array (a)
array object:   output (a)
dimensions:
ndims:   output (a).dimensions.rep[-1]
dims:   output *(a).dimensions.rep@(a).dimensions.rep[-1]

rep =   output *(a).rep
rep.data =   output *(a).rep.data@(a).rep.len


This is with gdb 7.11.1 and a recent tip.

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-06 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-03-06 jwe StatusConfirmed Ready For Test
    2018-02-28 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code