Community
Participate
Working Groups
Build Identifier: I20100817-0800 when you use cdt for debug, it seems that console output doesn't immediately updated whenever it changes. and it is causing critical difficulties in the way that you can't be informed printf message on time( that is, there is no way to be informed about program output until the debug session exits) maybe cdt debug component is not consistently watching several console's changes... Reproducible: Always Steps to Reproduce: 1.try debugging a hello world program with cdt 2.after stepping printf("hello world");, hello world would have been appeared to console output. but doesn't come out. 3.and when program exits, hello world appears and it is unusable.
From the email thread: > -----Original Message----- > From: cdt-dev-bounces@xxxxxxxxxxx > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Jin > Sent: Wednesday, August 18, 2010 1:19 PM > To: cdt-dev@xxxxxxxxxxx > Subject: [cdt-dev] [DSF-GDB] Memory leak when running JUnit tests > > I am writing JUnit tests based on the current MI*test from > DSF-GDB. When > I run my JUnit tests (140+ tests) on multiple targets (total is 1000+ > tests) I always run out of heap memory. Some tracing reveals there is > memory leak in the range of 1M-2M per test. > > Further debugging led me to this: > > In my launch delegate I create the GDB CLI process before running my > finalLaunchSequence > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=223154), and > this creates > the GDB runtime process allocating around 2M buffer for input/output > (AbstractCLIProcess). When the launch is terminated this GDB runtime > process needs to be released and this is done at > GDBControl.terminate() > where it schedules a MIGDBExit(). > > However, most of the time (8 out of 10) this MIGDBExit() is not > completed, thus the future task above it will run after 2 second. This > task does not kill the GDB process because the state is never > "State.STARTED" in this case. Not sure if it's related but > running this > task results in a "rejected execution exception" which can be > seen from > the console view. > > I also tried running the DSF/GDB unit tests (e.g. > MIRegisterTest) I can > see the same behavior that the MIGDBExit() is not completed but the > future task is run.
(In reply to comment #1) > From the email thread: > > > -----Original Message----- > > From: cdt-dev-bounces@xxxxxxxxxxx > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Jin > > Sent: Wednesday, August 18, 2010 1:19 PM > > To: cdt-dev@xxxxxxxxxxx > > Subject: [cdt-dev] [DSF-GDB] Memory leak when running JUnit tests > > > > I am writing JUnit tests based on the current MI*test from > > DSF-GDB. When > > I run my JUnit tests (140+ tests) on multiple targets (total is 1000+ > > tests) I always run out of heap memory. Some tracing reveals there is > > memory leak in the range of 1M-2M per test. I've seen some out-of-memory errors when running a large number of JUnit tests also, so I believe we are leaking memory somehow. > > > > Further debugging led me to this: > > > > In my launch delegate I create the GDB CLI process before running my > > finalLaunchSequence > > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=223154), and > > this creates > > the GDB runtime process allocating around 2M buffer for input/output > > (AbstractCLIProcess). When the launch is terminated this GDB runtime > > process needs to be released Up to here I'm following. > > and this is done at GDBControl.terminate() > > where it schedules a MIGDBExit(). Here I'm confused. The two LargePipedInputStream of AbstractCLIProcess seem to be released in AbstractCLIProcess#closeIO() which is called by AbstractCLIProcess#dispose(), which is called by GDBControl.CommandProcessorsStep which is triggered by the ShutdownSequence, which I would like to believe is always being called. Did I mis-understand what you meant?
Please ignore comment #1 and comment #2 they were meant for bug 323071
About this bug: some info at http://sourceware.org/ml/gdb/2008-02/msg00131.html and in bug 184582 and I'm sure in other places as well. I've forgotten if this can be fixed or not...
(In reply to comment #4) > About this bug: > > some info at http://sourceware.org/ml/gdb/2008-02/msg00131.html > and in bug 184582 > and I'm sure in other places as well. > > I've forgotten if this can be fixed or not... oh... you can give workaround for this bug. cdt redirects debugee process stdout to console tab. but if cdt not redirects the stdout(that is, you disallow cdt to manage the debugee stdout), the stdout will be shown on time.(it is supposed to be) about three month ago,standard create proces launcher haven't redirected the debugee stdout, but recently it did redirects the stdout..
cdt-master-8.0.0-I201008270810 standard process launcher showing seperate console and works fine. but gdb dsf launcher hangs when triggered in breakpoint showing following message to console window. deg*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x00405465",func="fibheap<int, fibheapnode<int> >::mergelink",args=[{name="this",value="0x22fefc"},{name="nodein",value="0x515848"},{name="nodeout",value="0x52bc28"}],file="../fibheap.cpp",fullname="/tmp/fibheap/fibheap.cpp",line="343"},thread-id="1",stopped-threads="all"
okay.... i found working workaround.... if you want for eclipse not to redirect your debugee stdout, here is the step. 1. you must go to debugging configuration, 2. change launcher to standard create process launcher, NOT "gdb DSF" 3. and then, you can see combobox named "gdb command set". 4. select "Standard" not "Standard(windows)" 5. click debug, and console works! 6. on windows this was only working configuration i'd seen.
I now see that this bug is probably the same as bug 231883
