Bugzilla – Full Text Bug Listing
| Summary: | [pretty printers] children of pointer to class with multiple inheritance are corrupted | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Jens Elmenthaler <jens.elmenthaler> | ||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Marc Khouzam <marc.khouzam> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | cdtdoug, pawel.1.piech, timblaktu | ||||
| Version: | 8.0 | ||||||
| Target Milestone: | 8.0 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 183480 [details]
Fix
Hey Jens, any idea if your fix has gotten into the latest CDT nightly builds? (In reply to comment #2) > Hey Jens, any idea if your fix has gotten into the latest CDT nightly builds? Just tried cdt-master-8.0.0-I201101140804 and reproduced the same behavior. This renders eclipse useless anytime you enter a scope that contains a stack variable that is a class with multiple parents. (In reply to comment #2) > Hey Jens, any idea if your fix has gotten into the latest CDT nightly builds? Sorry about the delay. I'll try to get this in tomorrow. Seems ok. Committed to HEAD. Thanks Jens. *** cdt cvs genie on behalf of mkhouzam *** Bug 330669: [pretty printers] children of pointer to class with multiple inheritance are corrupted [*] MIVariableManager.java 1.18 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIVariableManager.java?root=Tools_Project&r1=1.17&r2=1.18 Thanks Marc. I have tested the simple case from the top post of this thread using today's CDT 8.0 build and 3.7M4 eclipse. No hang up. But then again, I just noticed that this simple case seems to work fine, on my old eclipse install using 3.6 and a CDT 8.0 nightly from November. The main() in my primary application still hangs gdb mi in the same manner as described here. I'm not sure if it's bc of multiple inheritance or not, but the gdb traces output is the same as before. The last thing printed is : 516,889 (gdb) 517,197 20-stack-list-locals --thread 1 --frame 0 1 and via top on linux, I can see that a "gdb --interpreter mi2 --nx" thread has run off with one of my cores pegged at 100%. I will continue the process of narrowing down what local variable is causing the problem. I had assumed it was the multiple inheritance problem, bc we use that all over the place. Do let me know if there is some other piece of info that would be of help. (In reply to comment #7) > and via top on linux, I can see that a "gdb --interpreter mi2 --nx" thread has > run off with one of my cores pegged at 100%. That sounds like a gdb bug. You could try it with gdb HEAD if you have time to build it yourself, to see if it has been fixed. Or, if you can give us a way to reproduce the problem, I can try with gdb HEAD. You can also look at the bugzillas for gdb to see if the problem is known: http://www.gnu.org/software/gdb/bugs/ > I will continue the process of narrowing down what local variable is causing > the problem. I had assumed it was the multiple inheritance problem, bc we use > that all over the place. Do let me know if there is some other piece of info > that would be of help. The last few MI commands sent may help us see what could be the area to focus on. I #ifdef stubbed out the code until I have a simple case that hangs and a simple case that doesn't hang. The only difference is the inclusion of one more source line that declares/initializes a struct local variable. I looked at the gdb traces for the 2 cases, and the only difference is that in the good case, the stack-list-locals command immediately returns with the result, but in the problem case, the line: 543,915 20-stack-list-locals --thread 1 --frame 0 1 is the last mi command sent to gdb. once the "gdb --interpreter mi2 --nx" process stops hogging a core (after about a minute), it appears that a correct response is printed in the gdb traces. Then I can single step again, but when I do, the same process repeats.. This behavior does not happen when debugging the same thing via gdb command line. It seems MI-specific. I haven't been able to find any relevant gdb bugs yet. I thought this one might be related: http://sourceware.org/bugzilla/show_bug.cgi?id=9831 But then I found another eclipse user that had the exact same problem I'm having: https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&id=324522 He claims that this has been fixed, so next I guess I'll take all your suggestions and try to get bleeding edge gdb and see if the problem goes away... Thanks. I just upgraded gdb to 7.2-debian (debian unstable package) and am gettting the same behavior. (In reply to comment #10) > I just upgraded gdb to 7.2-debian (debian unstable package) and am gettting the > same behavior. I think I know what's going on, it's again the evil uninitialized local variable problem, i.e. calculating the child count or children can be very lengthy or run forever. While -var-list-children and -var-update have the children range to take control of this, -stack-list-locals only has the means to not fetch the values. The gdb command line takes care internally, that's why it doesn't hang. I will prepare a patch for MIStack to not fetch the values if MI pretty printing is enabled. Marc, would that be fine with you? (In reply to comment #11) > (In reply to comment #10) > I will prepare a patch for MIStack to not fetch the values if MI pretty > printing is enabled. Marc, would that be fine with you? Done, see bug307614, which originally tried to fix that problem, but didn't go far enough. (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > I will prepare a patch for MIStack to not fetch the values if MI pretty > > printing is enabled. Marc, would that be fine with you? > Done, see bug307614, which originally tried to fix that problem, but didn't go > far enough. Tim, are you able to test the fix that Jens posted in bug 307614 before I commit it? Let's make sure it fixes your problem. (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > I will prepare a patch for MIStack to not fetch the values if MI pretty > > > printing is enabled. Marc, would that be fine with you? > > Done, see bug307614, which originally tried to fix that problem, but didn't go > > far enough. > > Tim, are you able to test the fix that Jens posted in bug 307614 before I > commit it? Let's make sure it fixes your problem. I may not get it tested for a few days, as I am busy and novice at modifying eclipse. I will certainly let you know when I get to it. Hopefully it can get into Friday's build. OK. I'm trying to get back into CDT-development mode and following our isntructions at http://wiki.eclipse.org/Getting_started_with_CDT_development. After getting the latest project set file, replacing "extssh" with "pserver" and importing it, I get this dialog: Specify Repository Information The project set only contains partial repository information. You may use the table below to specify the complete repository information for each repository in the project set or click OK to use the default repository location. This dialog shows mapping from :pserver:dev.eclipse.org:/cvsroot/tools to :extssh:dev.eclipse.org:/cvsroot/tools. When I click OK, I am prompted to login, and I can see that it is trying to login to :extssh:dev.eclipse.org:/cvsroot/tools. So my anonymous login fails. The anonymous login used to work. Any idea how I can get around this? (In reply to comment #15) > OK. I'm trying to get back into CDT-development mode and following our > isntructions at http://wiki.eclipse.org/Getting_started_with_CDT_development. > After getting the latest project set file, replacing "extssh" with "pserver" > and importing it, I get this dialog: > > Specify Repository Information > > The project set only contains partial repository information. You may use the > table below to specify the complete repository information for each repository > in the project set or click OK to use the default repository location. > > This dialog shows mapping from :pserver:dev.eclipse.org:/cvsroot/tools to > :extssh:dev.eclipse.org:/cvsroot/tools. When I click OK, I am prompted to > login, and I can see that it is trying to login to > :extssh:dev.eclipse.org:/cvsroot/tools. So my anonymous login fails. The > anonymous login used to work. Any idea how I can get around this? The anonymous login only works with pserver. Right. The problem was that editing the project set is not sufficient. Your first time connecting to pserver, Eclipse requires you to "add the location"... So, I build CDT HEAD, applied the patch, and ran org.eclipse.cdt.ui as "Eclipse Application". When I debug my app using the new eclipse instance, eclipse hung indefinitely. For a sanity check, I reverted my patch change by replacing org.eclipse.cdt.dsf.gdb with HEAD, built and reran org.eclipse.cdt.ui as "Eclipse Application". I am able to debug my application as long as I don't have the variables tab open of course. So, so far I cannot verify this change fixes my problem. One thing of note is that when I run org.eclipse.cdt.ui as "Eclipse Application", and it hangs for whatever reason, when I force quit, I can see several java-6-sun threads sticking around in top... Next I will try using a launcher instead of doing "Run as.." "Eclipse Application" and see if the behavior improves. I have tested the latest patch against Eclipse 3.7M4 and CDT 8.0.0 Build I201101210805, and my project does not hang anymore when I enter the same scopes that were problems before. I have a few questions about my experience: (a) I had about 5000+ warnings when building CDT 8.0 HEAD. Is this expected? (b) When running org.eclipse.cdt.ui as an Eclipse Application, after running a C++ app debug session and terminating the app, the launched eclipse becomes unresponsive and I have to ungracefully terminate it. Is this expected? Do you have a preferred/better way of launching eclipse when you're testing patches? re: (b), I found that if I was patient enough after attempting to close the eclipse window, it eventually does close, and the console in my PDE environment has this: !ENTRY org.eclipse.osgi 2 1 2011-01-31 09:52:17.993 !MESSAGE NLS missing message: TaskJobFactory_Refreshing_repository_configuration in: org.eclipse.mylyn.internal.tasks.ui.messages Exception in thread "Worker-6" java.lang.OutOfMemoryError: PermGen space !ENTRY org.eclipse.osgi 4 0 2011-01-31 09:59:25.417 !MESSAGE !STACK 0 java.lang.OutOfMemoryError: PermGen space java.lang.OutOfMemoryError: PermGen space (In reply to comment #18) > I have tested the latest patch against Eclipse 3.7M4 and CDT 8.0.0 Build > I201101210805, and my project does not hang anymore when I enter the same > scopes that were problems before. I have a few questions about my experience: > (a) I had about 5000+ warnings when building CDT 8.0 HEAD. Is this expected? I also see that, but there used to be around 9000 a couple of months ago. So there certainly is progress. > (b) When running org.eclipse.cdt.ui as an Eclipse Application, after running a > C++ app debug session and terminating the app, the launched eclipse becomes > unresponsive and I have to ungracefully terminate it. Is this expected? Do you > have a preferred/better way of launching eclipse when you're testing patches? > re: (b), I found that if I was patient enough after attempting to close the > eclipse window, it eventually does close, and the console in my PDE environment > has this: > !ENTRY org.eclipse.osgi 2 1 2011-01-31 09:52:17.993 > !MESSAGE NLS missing message: > TaskJobFactory_Refreshing_repository_configuration in: > org.eclipse.mylyn.internal.tasks.ui.messages > Exception in thread "Worker-6" java.lang.OutOfMemoryError: PermGen space > !ENTRY org.eclipse.osgi 4 0 2011-01-31 09:59:25.417 > !MESSAGE > !STACK 0 > java.lang.OutOfMemoryError: PermGen space > java.lang.OutOfMemoryError: PermGen space Configure your jvm for for memory. You can do that in the eclipse.ini. I, for instance have the following entries there: -vmargs -Xms64m -Xmx3072m -XX:MaxPermSize=256m -XX:PermSize=64m -XX:+HeapDumpOnOutOfMemoryError -Xss1m |
Build Identifier: HEAD Create a source file with the following content: class BaseA { int a(); }; class BaseB { int b(); }; class Derived : public BaseA, public BaseB { public: Derived(const char * c) : s(c) { } ; private: std::string s; }; int main() { vector<Derived*> v; Derived * a = new Derived("33"); v.push_back(a); return 0; } Set a breakpoint the return-statement in main and run in debugger. When halted, expand v in variables view, the expand [0]. The children of [0] remain blank. I'm now starting to look at it. Reproducible: Always