Bug 136627 - broken static fields dispay
Summary: broken static fields dispay
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug (show other bugs)
Version: 3.1   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: cdt-debug-inbox@eclipse.org CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-13 09:48 EDT by Vladimir Prus CLA
Modified: 2020-09-04 15:17 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Prus CLA 2006-04-13 09:48:12 EDT
I'm debugging a Qt (version 3.3) application, and tried to view a QString variable. The QString class has a static field 'null', that also has type 'QString'. This makes Eclipse think there's infinite object tree, I see this tree:
- 'xs' (my varible),
- 'public'
- 'null'
- 'public'
- 'null'
- 'public'
- 'null'

and so on, infinitely.

Having static members of the same type as the class there are in is not so rare practice, so maybe Eclipse can more reasonable handle this case?
Comment 1 Nobody - feel free to take it CLA 2006-05-31 17:18:28 EDT
So what's the problem? This presentation is based on the backend debugger, in this case it is gdb. That's the way gdb presents the instances of your class.
Comment 2 Vladimir Prus CLA 2007-09-02 14:22:21 EDT
This is correct, technically speaking. However, for end user this behaviour is strange, and end user might not care about 'gdb' thing. Presumably, I can make changes on gdb side, but I'm not quite sure what changes will be most helpfull -- should gdb somehow indicate 'this is static field that is already' shown, or what?
Comment 3 Nobody - feel free to take it CLA 2007-09-04 06:56:47 EDT
(In reply to comment #2)
> This is correct, technically speaking. However, for end user this behaviour is
> strange, and end user might not care about 'gdb' thing. Presumably, I can make
> changes on gdb side, but I'm not quite sure what changes will be most helpfull
> -- should gdb somehow indicate 'this is static field that is already' shown, or
> what?

Do you know how it works with other mi based clients? 
Comment 4 Vladimir Prus CLA 2007-09-04 08:18:22 EDT
No. The only other MI client I know is KDevelop, and it has the same problem. I'd hope XCore to be better, but don't have access to it and it uses customized gdb anyway.
Comment 5 Nobody - feel free to take it CLA 2007-09-04 09:44:44 EDT
(In reply to comment #4)
> No. The only other MI client I know is KDevelop, and it has the same problem.
> I'd hope XCore to be better, but don't have access to it and it uses customized
> gdb anyway.

I don't know why gdb can't handle this situation internally. mi is not intended to be used by end users, so why list the static fields for each child. 
If there is a reason to do it I would rather prefer to have an option for var-list-children to turn on/off the static field display. 
Comment 6 Vladimir Prus CLA 2007-09-04 09:48:50 EDT
In fact, -var-list-children always shows static fields; that's something KDevelop users complained about too.

Do you think you'd prefer "display static fields" to be specified for every -var-list-children command, or be a global MI setting?
Comment 7 Nobody - feel free to take it CLA 2007-09-04 10:21:44 EDT
(In reply to comment #6)
> In fact, -var-list-children always shows static fields; that's something
> KDevelop users complained about too.
> Do you think you'd prefer "display static fields" to be specified for every
> -var-list-children command, or be a global MI setting?

I think we need both. We can turn the command option on for the top level variable and turn it off for its children. A global setting can be used as a default value for this option so it will not affect the existing mi based clients.