bugDDD - Bugs: bug #25109, All-registers display doesn't work


bug #25109: All-registers display doesn't work

Submitted by:  None
Submitted on:  Wed 17 Dec 2008 07:47:38 AM UTC  
Category:  Data display Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  3.3.11

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sat 02 May 2009 10:45:39 AM UTC, comment #2:

I did a little bit of debugging.

The problem is in parsing the result of info all registers.
The result of info all registers is something like

eax 0x1 1
fop 0x0 0
xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000}
[...(further xmm's very similar to xmm0)...]

This is parsed by DispValues init-method which (I think correctly) tries to put it into a List because `info all-registers` is identified as a user command.

After a little bit of other code we arrive at the while(more_values) loop in DispValue.C:573ff where things get out of control.

The first gdb-output lines (eax to fop) are processed smothly and added as text, because read_member_name can not find a valid member separator and so decides there is no member name (this is ok, I guess).

Then the line with xmm0 is processed.
It contains a member separator (' = ', actually the separator for contained struct member v4_float). So code for adding ordinary members is invoked, adding (incorrectly) members with names {v4_float to uint128 and leaving the final closing bracket '}' as last character in the line. This closing bracket causes read_next_struct to decide the input for the List / Struct (both handled in the same block) is processed completely.

Unfortunately there is still lots of unprocessed stuff in the input. This is detected later on (DispValue.C:786ff) and the type is switched from List to Sequence which causes the result to be displayed as single line instead of a list.

A possible fix would not to call read_member_name for Lists, but instead to take each line as Text in any case. Or to use a different separator (e.g. some spaces) for Lists.
I don't really know the ddd-code so I don't know the dependencies. It might well be that Lists are used in other positions where Lists of `key = value` pairs are displayed. In that case, the fix could be more complicated and might need extending the parsing algorithm for Lists.

Ansgar Lampe <zaldron>
Fri 01 May 2009 11:20:03 PM UTC, comment #1:

I have tested this with KUbuntu 8.04 version of ddd (which is as you describe version 3.3.11) as well as with source compiles of ddd versions 3.3.11 and 3.3.12 and current svn (revision 7209).

All tested versions show the same behaviour:

  • I can NOT confirm strange behaviour at end of grid. In my case the grid is longer than the displayed text.


  • I can confirm there are no linebreaks.
  • I can confirm the text looks more or less exactly as on the screenshot.
Ansgar Lampe <zaldron>
Wed 17 Dec 2008 07:47:38 AM UTC, original submission:

I previously reported this issue in the ubuntu bugtracker ( https://bugs.launchpad.net/ubuntu/+source/ddd/+bug/111723 ) hoping they would've been able to contact the upstream development, but apparently this isn't the case and after a year and a half basicly nothing happened.

But, when a small hello world application is written, a breakpoint is set and i enter "graph display `info all-registers`" then the display gets screwed up.

In attach you can find:

  • gdb.png : The default view, which shows the linebreaks get screwed
  • gdb1.png : When scrolling towards the end of the string, where the grid stops things get really messy
  • gdb2.png : And if you scroll even further the text turns into gibberish
  • log : the .ddd/log

The package is the same package which should be available in standard debian and ubuntu distributions.



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

Attach Files:

Attached Files
file #17080:  gdb.png added by None (25KiB - image/png - 3 screenshots and ddd.log )
file #17081:  gdb2.png added by None (24KiB - image/png - 3 screenshots and ddd.log )
file #17082:  gdb1.png added by None (24KiB - image/png - 3 screenshots and ddd.log )
file #17083:  log added by None (19KiB - application/octet-stream - 3 screenshots and ddd.log )


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by zaldron (Posted a comment)
  • -email is unavailable- added by eliedebrauwer (Adding myself to notification list)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-12-17 eliedebrauwer Carbon-Copy- => Added -email is unavailable-
    2008-12-17 None Attached File- => Added gdb.png, #17080
        Attached File- => Added gdb2.png, #17081
        Attached File- => Added gdb1.png, #17082
        Attached File- => Added log, #17083

    Back to the top

    Powered by Savane 3.3