Discussion:
Console skip output lines when using gdb on windows/MinGW
fcx
2008-07-09 08:44:00 UTC
Permalink
Hi,
I am using CDT 5.0.0 on Eclipse 3.4.0 on Windows with MinGW 5.1.4.

In console, when i use gdb, I have only a subset of my traces.
Lost lines are: empty lines, lines which begin with '*', '=', ...

e.g. with the following code:

#include <stdio.h>
int main()
{
puts("one");
puts("");
puts("*two");
puts("==>tree");
puts("-->four");
puts("#five");
puts("done");
return 0;
}

on F11 (with gdb), my console shows:

one
-->four
#five
done

on Ctrl+F11 (without gdb), console contents is ok:

one

*two
==>tree
-->four
#five
done


Note 1: my project is a standard project (new>C++ project>Executable>Hello
world c++ project>...)

Note 2: when i activate "verbose console mode" in
"project>properties>run/debug setting>Edit launch configuration>Debugger", i
see all of my traces in gdb traces (see "HERE" tag below)

Any idea ?

Francois.

-----------------------------------------------------------------------------
gdb console:

189-gdb-set confirm off
189^done
(gdb)
190-gdb-set width 0
190^done
(gdb)
191-gdb-set height 0
191^done
(gdb)
192-interpreter-exec console echo
192^error,msg="Undefined MI command: interpreter-exec"
(gdb)
193-gdb-show prompt
193^done,value="(gdb) "
(gdb)
194
&"\n"

194^done
(gdb)
195-gdb-set stop-on-solib-events 0
195^done
(gdb)
196-gdb-set stop-on-solib-events 1
196^done
(gdb)
197-gdb-set new-console off
197^done
(gdb)
198-environment-cd C:\\Dev\\test2
198^done
(gdb)
199-environment-directory C:/Dev/test2 C:/Dev/test2/Debug
C:/Dev/test2/Debug/src C:/Dev/test2/src
199^done
(gdb)
200 info threads
&"info threads\n"
&"No stack.\n"
200^error,msg="No stack."
(gdb)
201-data-list-register-names
201^done,register-names=["eax","ecx","edx","ebx","esp","ebp","esi","edi","eip","eflags","cs","ss","ds","es","fs","gs","st0","st1","st2","st3","st4","st5","st6","st7","fctrl","fstat","ftag","fiseg","fioff","foseg","fooff","fop"]
(gdb)
202-exec-run
202^running <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< HERE
(gdb)
one

*two
==>tree
-->four
#five
done <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< HERE
202*stopped,reason="exited-normally"
(gdb)
203-data-evaluate-expression $_exitcode
203^done,value="0"
(gdb)
204-gdb-exit
204^exit


--
View this message in context: http://www.nabble.com/Console-skip-output-lines-when-using-gdb-on-windows-MinGW-tp18342983p18342983.html
Sent from the Eclipse CDT - debug mailing list archive at Nabble.com.
Elena Laskavaia
2008-07-09 13:42:18 UTC
Permalink
This is gbd console, if you interested in output of your application you
should switch to application console (select from menu in console view
that looks like monitor or click on binary your "process" in debug view)
Lines that start with * and = has special meaning in gdb protocol and
parsed out by protocol parser (and with verbose all echoed back so you
see it).

fcx wrote:
> Hi,
> I am using CDT 5.0.0 on Eclipse 3.4.0 on Windows with MinGW 5.1.4.
>
> In console, when i use gdb, I have only a subset of my traces.
> Lost lines are: empty lines, lines which begin with '*', '=', ...
>
> e.g. with the following code:
>
> #include <stdio.h>
> int main()
> {
> puts("one");
> puts("");
> puts("*two");
> puts("==>tree");
> puts("-->four");
> puts("#five");
> puts("done");
> return 0;
> }
>
> on F11 (with gdb), my console shows:
>
> one
> -->four
> #five
> done
>
> on Ctrl+F11 (without gdb), console contents is ok:
>
> one
>
> *two
> ==>tree
> -->four
> #five
> done
>
>
> Note 1: my project is a standard project (new>C++ project>Executable>Hello
> world c++ project>...)
>
> Note 2: when i activate "verbose console mode" in
> "project>properties>run/debug setting>Edit launch configuration>Debugger", i
> see all of my traces in gdb traces (see "HERE" tag below)
>
> Any idea ?
>
> Francois.
>
> -----------------------------------------------------------------------------
> gdb console:
>
> 189-gdb-set confirm off
> 189^done
> (gdb)
> 190-gdb-set width 0
> 190^done
> (gdb)
> 191-gdb-set height 0
> 191^done
> (gdb)
> 192-interpreter-exec console echo
> 192^error,msg="Undefined MI command: interpreter-exec"
> (gdb)
> 193-gdb-show prompt
> 193^done,value="(gdb) "
> (gdb)
> 194
> &"\n"
>
> 194^done
> (gdb)
> 195-gdb-set stop-on-solib-events 0
> 195^done
> (gdb)
> 196-gdb-set stop-on-solib-events 1
> 196^done
> (gdb)
> 197-gdb-set new-console off
> 197^done
> (gdb)
> 198-environment-cd C:\\Dev\\test2
> 198^done
> (gdb)
> 199-environment-directory C:/Dev/test2 C:/Dev/test2/Debug
> C:/Dev/test2/Debug/src C:/Dev/test2/src
> 199^done
> (gdb)
> 200 info threads
> &"info threads\n"
> &"No stack.\n"
> 200^error,msg="No stack."
> (gdb)
> 201-data-list-register-names
> 201^done,register-names=["eax","ecx","edx","ebx","esp","ebp","esi","edi","eip","eflags","cs","ss","ds","es","fs","gs","st0","st1","st2","st3","st4","st5","st6","st7","fctrl","fstat","ftag","fiseg","fioff","foseg","fooff","fop"]
> (gdb)
> 202-exec-run
> 202^running <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< HERE
> (gdb)
> one
>
> *two
> ==>tree
> -->four
> #five
> done <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< HERE
> 202*stopped,reason="exited-normally"
> (gdb)
> 203-data-evaluate-expression $_exitcode
> 203^done,value="0"
> (gdb)
> 204-gdb-exit
> 204^exit
>
>
>
fcx
2008-07-09 21:08:38 UTC
Permalink
Effectively, I have tree consoles:
- build console (gcc output)
- gdb.exe console : this console is empty if "verbose console mode" is not
checked. It contains my previous "gdb" traces is "verbose console mode is
checked"
- my_app.exe console : it contains my app output without "special lines"
(empty, *..., =...).

My problem is not to switch on "my_app.exe console" (in fact, it is the
default displayed).
My problem is that, "my_app.exe console" has not all traces.

Do you know why this parsing problem appears only with windows/mingw and not
with linux ? Is protocol parser different ? (I have tested with ubuntu Hardy
(same eclipse&cdt version): with linux, the "my_app output" console contains
all expected lines).

Note: I have notice a difference between windows and linux when I start gdb
manually (without eclipse):
- in windows: "gdb my_app.exe" execute my app in a new console (new window).
New console contains all expected lines !!!
- in linux: "gdb my_app" execute my app in current console




This is gbd console, if you interested in output of your application you
should switch to application console (select from menu in console view
that looks like monitor or click on binary your "process" in debug view)
Lines that start with * and = has special meaning in gdb protocol and
parsed out by protocol parser (and with verbose all echoed back so you
see it).

fcx wrote:
> Hi,
> I am using CDT 5.0.0 on Eclipse 3.4.0 on Windows with MinGW 5.1.4.
>
> In console, when i use gdb, I have only a subset of my traces.
> Lost lines are: empty lines, lines which begin with '*', '=', ...
>
> e.g. with the following code:
>
> #include <stdio.h>
> int main()
> {
> puts("one");
> puts("");
> puts("*two");
> puts("==>tree");
> puts("-->four");
> puts("#five");
> puts("done");
> return 0;
> }
>
> on F11 (with gdb), my console shows:
>
> one
> -->four
> #five
> done
>
> on Ctrl+F11 (without gdb), console contents is ok:
>
> one
>
> *two
> ==>tree
> -->four
> #five
> done
>
>
> Note 1: my project is a standard project (new>C++ project>Executable>Hello
> world c++ project>...)
>
> Note 2: when i activate "verbose console mode" in
> "project>properties>run/debug setting>Edit launch configuration>Debugger",
> i
> see all of my traces in gdb traces (see "HERE" tag below)
>
> Any idea ?
>
> Francois.

--
View this message in context: http://www.nabble.com/Console-skip-output-lines-when-using-gdb-on-windows-MinGW-tp18342983p18370859.html
Sent from the Eclipse CDT - debug mailing list archive at Nabble.com.
Daniel Jacobowitz
2008-07-09 21:17:25 UTC
Permalink
On Wed, Jul 09, 2008 at 02:08:38PM -0700, fcx wrote:
> Do you know why this parsing problem appears only with windows/mingw and not
> with linux ? Is protocol parser different ? (I have tested with ubuntu Hardy
> (same eclipse&cdt version): with linux, the "my_app output" console contains
> all expected lines).

On Linux, CDT redirects your application's output to a different
pseudo-terminal (TTY). That lets it unambiguously differentiate
between GDB output and program output. Windows doesn't have TTYs.

On Windows you could probably arrange to do this just with pipes... or
by using set new-console, but that pops up a window.

--
Daniel Jacobowitz
CodeSourcery
fcx
2008-07-10 13:36:21 UTC
Permalink
> On Linux, CDT redirects your application's output to a different
> pseudo-terminal (TTY). That lets it unambiguously differentiate
> between GDB output and program output. Windows doesn't have TTYs.
>
> On Windows you could probably arrange to do this just with pipes... or
> by using set new-console, but that pops up a window.
>
> --
> Daniel Jacobowitz
> CodeSourcery

Thanks,

Could you be more precise about your advices...

I have done some tests:

Solution 1 : "set new-console"
---------------------------
I suppose it is the "set new-console on" of gdb ("on" is the default mode in
mingw/gdb). I have tried to insert this line into a file "c:/gdbinit.txt"
and I set "c:/gdbinit.txt" in "gdb command set" in "launch
configuration>debugger". But "c:/gdbinit.txt" is not loaded by gdb under
eclipse (bug ?) (see traces #1)

Note : when I set "new-console" manually (outside eclipse), I have perfect
output (see trace #2)

Note : this solution is not as much pleasant than output in eclipse console
for simple test programs (especially, it requires "getchar()" function to
prevent automatic closing of the console window, ...)

Is there a methode to set "new-console to on" by an another way ?

Solution 2 : new console with an other method
---------------------------------------------
http://dev.eclipse.org/newslists/news.eclipse.tools.cdt/msg14587.html

In previous link, it is recommended to use "-Wl,-subsystem,console" option
in gcc.

It doesn't work in my environment... (it still use eclipse console)

My eclipse "build" console:

**** Rebuild of configuration Debug for project test ****
**** Internal Builder is used for build ****
g++ -O0 -g -c -osrc\test.o ..\src\test.cpp
g++ -Wl,-subsystem,console -otest.exe src\test.o
Build complete for project test
Time consumed: 422 ms.



Solution 3 : pipes
------------------

Do you mean to redirect output to a file and to watch file after execution ?

Do you mean to do something inside eclipse gui or outside eclipse ?


TRACES
======


trace #1 : gdb console, no call to c:/gdbinit.txt

327-gdb-set confirm off
327^done
(gdb)
328-gdb-set width 0
328^done
(gdb)
329-gdb-set height 0
329^done
(gdb)
330-interpreter-exec console echo
330^error,msg="Undefined MI command: interpreter-exec"
(gdb)
331-gdb-show prompt
331^done,value="(gdb) "
(gdb)
332
&"\n"
332^done
(gdb)

333-gdb-set stop-on-solib-events 0
333^done
334-gdb-set stop-on-solib-events 1
(gdb)
334^done
335-gdb-set new-console off
(gdb)
335^done
336-environment-cd C:\\Dev\\test
(gdb)
336^done
(gdb)
337-environment-directory C:/Dev/test C:/Dev/test/Debug
C:/Dev/test/Debug/src C:/Dev/test/src
337^done
(gdb)
338 info threads
&"info threads\n"
&"No stack.\n"
338^error,msg="No stack."
(gdb)
339-data-list-register-names

339^done,register-names=["eax","ecx","edx","ebx","esp","ebp","esi","edi","eip","eflags","cs","ss","ds","es","fs","gs","st0","st1","st2","st3","st4","st5","st6","st7","fctrl","fstat","ftag","fiseg","fioff","foseg","fooff","fop"]
(gdb)
340-exec-run
340^running
(gdb)
one

*two
==>tree
-->four
#five
done
340*stopped,reason="exited-normally"
(gdb)
341-data-evaluate-expression $_exitcode
341^done,value="0"
(gdb)
342-gdb-exit
342^exit


trace #2 : gdb console outside eclipse, test with "set-new-console"

C:\Dev\test\Debug>gdb test.exe
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) set new-console on
(gdb) r
Starting program: C:\Dev\test\Debug/test.exe

Program exited normally.
(gdb) set new-console off
(gdb) r
Starting program: C:\Dev\test\Debug/test.exe
one

*two
==>tree
-->four
#five
done

Program exited normally.
(gdb) quit



--
View this message in context: http://www.nabble.com/Console-skip-output-lines-when-using-gdb-on-windows-MinGW-tp18342983p18382939.html
Sent from the Eclipse CDT - debug mailing list archive at Nabble.com.
John Cortell
2008-07-15 16:31:08 UTC
Permalink
The CDI interfaces tied to the Debug View standard model hierarchy
lack a dispose method:

ICDITarget
ICDIThread
ICDIStackFrame

Their CDT counterparts (implementations) have a dispose method (e.g.,
CStackFrame.dispose) that could and should propagate the dispose to
their associated CDI object. This is needed for deterministic cleanup.

I was thinking of coming up with an ICDIDisposable. CDT would
instanceof for that interface and call it where available for
implementations of the above three interfaces and possibly more in
the future where we find a need. Any objections?

John
Elena Laskavaia
2008-07-15 18:13:03 UTC
Permalink
+1

John Cortell wrote:
> The CDI interfaces tied to the Debug View standard model hierarchy
> lack a dispose method:
>
> ICDITarget
> ICDIThread
> ICDIStackFrame
>
> Their CDT counterparts (implementations) have a dispose method (e.g.,
> CStackFrame.dispose) that could and should propagate the dispose to
> their associated CDI object. This is needed for deterministic cleanup.
>
> I was thinking of coming up with an ICDIDisposable. CDT would
> instanceof for that interface and call it where available for
> implementations of the above three interfaces and possibly more in the
> future where we find a need. Any objections?
>
> John
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev-j9T/***@public.gmane.org
> https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
Mikhail Khodjaiants
2008-07-16 09:13:18 UTC
Permalink
I don't mind adding ICDIDisposable if it is required. dispose() is added
to the CDT objects to prevent the "post-mortem" activity, for instance,
the event handling when a thread is terminated but the corresponding
CThread is still present in the GUI.
Why do you need to propagate this behaviour to the CDI layer?

Mikhail
-----Original Message-----
From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of John Cortell
Sent: Tuesday, July 15, 2008 5:31 PM
To: CDT Debug developers list
Subject: [cdt-debug-dev] dispose() for ICDI target,thread and stack
frame interfaces

The CDI interfaces tied to the Debug View standard model hierarchy lack
a dispose method:

ICDITarget
ICDIThread
ICDIStackFrame

Their CDT counterparts (implementations) have a dispose method (e.g.,
CStackFrame.dispose) that could and should propagate the dispose to
their associated CDI object. This is needed for deterministic cleanup.

I was thinking of coming up with an ICDIDisposable. CDT would instanceof
for that interface and call it where available for implementations of
the above three interfaces and possibly more in the future where we find
a need. Any objections?

John

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev-j9T/***@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

--
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
John Cortell
2008-07-16 12:17:00 UTC
Permalink
An interface/class whose implementation allocates and holds on to
external (non-Java) resources is a good candidate for a dispose
method. We see this pattern in GUI libraries and it applies equally
to CDI. A CDI implementation typically deals with some external
entity--a debugger engine (DE). Consequently, CDI objects allocate
and attach themselves to DE resources. It may not be ideal to subject
the external entity to the non-deterministic cleanup of the VM
garbage collector. The only way to avoid that is through explicit
dispose calls.

The user steps out of a function in a debug session. CDT has no
further use for the topmost ICDIStackFrame but the CDI client has no
way of being told that today. The client may have all sorts of DE
cleanup it may need to do when a stack frame is no longer needed.
Using the Java finalize method is not ideal. The solution is to have
CDT calls ICDIStackFrame.dispose() when CStackFrame.dispose() is called.

John


At 04:13 AM 7/16/2008, Mikhail Khodjaiants wrote:
>I don't mind adding ICDIDisposable if it is required. dispose() is added
>to the CDT objects to prevent the "post-mortem" activity, for instance,
>the event handling when a thread is terminated but the corresponding
>CThread is still present in the GUI.
>Why do you need to propagate this behaviour to the CDI layer?
>
>Mikhail
>-----Original Message-----
>From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
>[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of John Cortell
>Sent: Tuesday, July 15, 2008 5:31 PM
>To: CDT Debug developers list
>Subject: [cdt-debug-dev] dispose() for ICDI target,thread and stack
>frame interfaces
>
>The CDI interfaces tied to the Debug View standard model hierarchy lack
>a dispose method:
>
> ICDITarget
> ICDIThread
> ICDIStackFrame
>
>Their CDT counterparts (implementations) have a dispose method (e.g.,
>CStackFrame.dispose) that could and should propagate the dispose to
>their associated CDI object. This is needed for deterministic cleanup.
>
>I was thinking of coming up with an ICDIDisposable. CDT would instanceof
>for that interface and call it where available for implementations of
>the above three interfaces and possibly more in the future where we find
>a need. Any objections?
>
>John
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev-j9T/***@public.gmane.org
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
>--
>IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose
>the contents to any other person, use it for any purpose, or store
>or copy the information in any medium. Thank you.
>
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev-j9T/***@public.gmane.org
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
Mikhail Khodjaiants
2008-07-16 12:40:05 UTC
Permalink
I agree that a notification may be required for ICDIStackFrame. But if a
CDI target or thread is terminated doesn't it mean that you can do a
cleanup at that moment?

Mikhail
-----Original Message-----
From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of John Cortell
Sent: Wednesday, July 16, 2008 1:17 PM
To: CDT Debug developers list; CDT Debug developers list
Subject: RE: [cdt-debug-dev] dispose() for ICDI target, thread andstack
frame interfaces

An interface/class whose implementation allocates and holds on to
external (non-Java) resources is a good candidate for a dispose method.
We see this pattern in GUI libraries and it applies equally to CDI. A
CDI implementation typically deals with some external entity--a debugger
engine (DE). Consequently, CDI objects allocate and attach themselves to
DE resources. It may not be ideal to subject the external entity to the
non-deterministic cleanup of the VM garbage collector. The only way to
avoid that is through explicit dispose calls.

The user steps out of a function in a debug session. CDT has no further
use for the topmost ICDIStackFrame but the CDI client has no way of
being told that today. The client may have all sorts of DE cleanup it
may need to do when a stack frame is no longer needed.
Using the Java finalize method is not ideal. The solution is to have CDT
calls ICDIStackFrame.dispose() when CStackFrame.dispose() is called.

John


At 04:13 AM 7/16/2008, Mikhail Khodjaiants wrote:
>I don't mind adding ICDIDisposable if it is required. dispose() is
>added to the CDT objects to prevent the "post-mortem" activity, for
>instance, the event handling when a thread is terminated but the
>corresponding CThread is still present in the GUI.
>Why do you need to propagate this behaviour to the CDI layer?
>
>Mikhail
>-----Original Message-----
>From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
>[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of John Cortell
>Sent: Tuesday, July 15, 2008 5:31 PM
>To: CDT Debug developers list
>Subject: [cdt-debug-dev] dispose() for ICDI target,thread and stack
>frame interfaces
>
>The CDI interfaces tied to the Debug View standard model hierarchy lack

>a dispose method:
>
> ICDITarget
> ICDIThread
> ICDIStackFrame
>
>Their CDT counterparts (implementations) have a dispose method (e.g.,
>CStackFrame.dispose) that could and should propagate the dispose to
>their associated CDI object. This is needed for deterministic cleanup.
>
>I was thinking of coming up with an ICDIDisposable. CDT would
>instanceof for that interface and call it where available for
>implementations of the above three interfaces and possibly more in the
>future where we find a need. Any objections?
>
>John
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev-j9T/***@public.gmane.org
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
>--
>IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the

>contents to any other person, use it for any purpose, or store or copy
>the information in any medium. Thank you.
>
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev-j9T/***@public.gmane.org
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev-j9T/***@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

--
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
John Cortell
2008-07-16 13:21:04 UTC
Permalink
The idea was to provide consistency. Target, thread and frame are the
standard model objects in the Debug view. Their CDT classes
(CDebugTarget, CThread, and CStackFrame) all have a cleanup method.
It seems more natural to have all three have a dispose() capability
in their corresponding CDI interfaces, rather than just one out of three.

John

At 07:40 AM 7/16/2008, Mikhail Khodjaiants wrote:
>I agree that a notification may be required for ICDIStackFrame. But if a
>CDI target or thread is terminated doesn't it mean that you can do a
>cleanup at that moment?
>
>Mikhail
>-----Original Message-----
>From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
>[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of John Cortell
>Sent: Wednesday, July 16, 2008 1:17 PM
>To: CDT Debug developers list; CDT Debug developers list
>Subject: RE: [cdt-debug-dev] dispose() for ICDI target, thread andstack
>frame interfaces
>
>An interface/class whose implementation allocates and holds on to
>external (non-Java) resources is a good candidate for a dispose method.
>We see this pattern in GUI libraries and it applies equally to CDI. A
>CDI implementation typically deals with some external entity--a debugger
>engine (DE). Consequently, CDI objects allocate and attach themselves to
>DE resources. It may not be ideal to subject the external entity to the
>non-deterministic cleanup of the VM garbage collector. The only way to
>avoid that is through explicit dispose calls.
>
>The user steps out of a function in a debug session. CDT has no further
>use for the topmost ICDIStackFrame but the CDI client has no way of
>being told that today. The client may have all sorts of DE cleanup it
>may need to do when a stack frame is no longer needed.
>Using the Java finalize method is not ideal. The solution is to have CDT
>calls ICDIStackFrame.dispose() when CStackFrame.dispose() is called.
>
>John
>
>
>At 04:13 AM 7/16/2008, Mikhail Khodjaiants wrote:
> >I don't mind adding ICDIDisposable if it is required. dispose() is
> >added to the CDT objects to prevent the "post-mortem" activity, for
> >instance, the event handling when a thread is terminated but the
> >corresponding CThread is still present in the GUI.
> >Why do you need to propagate this behaviour to the CDI layer?
> >
> >Mikhail
> >-----Original Message-----
> >From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
> >[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of John Cortell
> >Sent: Tuesday, July 15, 2008 5:31 PM
> >To: CDT Debug developers list
> >Subject: [cdt-debug-dev] dispose() for ICDI target,thread and stack
> >frame interfaces
> >
> >The CDI interfaces tied to the Debug View standard model hierarchy lack
>
> >a dispose method:
> >
> > ICDITarget
> > ICDIThread
> > ICDIStackFrame
> >
> >Their CDT counterparts (implementations) have a dispose method (e.g.,
> >CStackFrame.dispose) that could and should propagate the dispose to
> >their associated CDI object. This is needed for deterministic cleanup.
> >
> >I was thinking of coming up with an ICDIDisposable. CDT would
> >instanceof for that interface and call it where available for
> >implementations of the above three interfaces and possibly more in the
> >future where we find a need. Any objections?
> >
> >John
> >
> >_______________________________________________
> >cdt-debug-dev mailing list
> >cdt-debug-dev-j9T/***@public.gmane.org
> >https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
> >
> >--
> >IMPORTANT NOTICE: The contents of this email and any attachments are
> >confidential and may also be privileged. If you are not the intended
> >recipient, please notify the sender immediately and do not disclose the
>
> >contents to any other person, use it for any purpose, or store or copy
> >the information in any medium. Thank you.
> >
> >
> >_______________________________________________
> >cdt-debug-dev mailing list
> >cdt-debug-dev-j9T/***@public.gmane.org
> >https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev-j9T/***@public.gmane.org
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
>--
>IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose
>the contents to any other person, use it for any purpose, or store
>or copy the information in any medium. Thank you.
>
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev-j9T/***@public.gmane.org
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
Mikhail Khodjaiants
2008-07-16 13:36:38 UTC
Permalink
Anyway, as I said I have no problem adding it. I was just trying to find
out if I was missing something.

Mikhail

-----Original Message-----
From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of John Cortell
Sent: Wednesday, July 16, 2008 2:21 PM
To: CDT Debug developers list; CDT Debug developers list
Subject: RE: [cdt-debug-dev] dispose() for ICDI target, thread
andstackframe interfaces

The idea was to provide consistency. Target, thread and frame are the
standard model objects in the Debug view. Their CDT classes
(CDebugTarget, CThread, and CStackFrame) all have a cleanup method.
It seems more natural to have all three have a dispose() capability in
their corresponding CDI interfaces, rather than just one out of three.

John

At 07:40 AM 7/16/2008, Mikhail Khodjaiants wrote:
>I agree that a notification may be required for ICDIStackFrame. But if
>a CDI target or thread is terminated doesn't it mean that you can do a
>cleanup at that moment?
>
>Mikhail
>-----Original Message-----
>From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
>[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of John Cortell
>Sent: Wednesday, July 16, 2008 1:17 PM
>To: CDT Debug developers list; CDT Debug developers list
>Subject: RE: [cdt-debug-dev] dispose() for ICDI target, thread andstack

>frame interfaces
>
>An interface/class whose implementation allocates and holds on to
>external (non-Java) resources is a good candidate for a dispose method.
>We see this pattern in GUI libraries and it applies equally to CDI. A
>CDI implementation typically deals with some external entity--a
>debugger engine (DE). Consequently, CDI objects allocate and attach
>themselves to DE resources. It may not be ideal to subject the external

>entity to the non-deterministic cleanup of the VM garbage collector.
>The only way to avoid that is through explicit dispose calls.
>
>The user steps out of a function in a debug session. CDT has no further

>use for the topmost ICDIStackFrame but the CDI client has no way of
>being told that today. The client may have all sorts of DE cleanup it
>may need to do when a stack frame is no longer needed.
>Using the Java finalize method is not ideal. The solution is to have
>CDT calls ICDIStackFrame.dispose() when CStackFrame.dispose() is
called.
>
>John
>
>
>At 04:13 AM 7/16/2008, Mikhail Khodjaiants wrote:
> >I don't mind adding ICDIDisposable if it is required. dispose() is
> >added to the CDT objects to prevent the "post-mortem" activity, for
> >instance, the event handling when a thread is terminated but the
> >corresponding CThread is still present in the GUI.
> >Why do you need to propagate this behaviour to the CDI layer?
> >
> >Mikhail
> >-----Original Message-----
> >From: cdt-debug-dev-bounces-j9T/***@public.gmane.org
> >[mailto:cdt-debug-dev-bounces-j9T/***@public.gmane.org] On Behalf Of John Cortell
> >Sent: Tuesday, July 15, 2008 5:31 PM
> >To: CDT Debug developers list
> >Subject: [cdt-debug-dev] dispose() for ICDI target,thread and stack
> >frame interfaces
> >
> >The CDI interfaces tied to the Debug View standard model hierarchy
> >lack
>
> >a dispose method:
> >
> > ICDITarget
> > ICDIThread
> > ICDIStackFrame
> >
> >Their CDT counterparts (implementations) have a dispose method (e.g.,
> >CStackFrame.dispose) that could and should propagate the dispose to
> >their associated CDI object. This is needed for deterministic
cleanup.
> >
> >I was thinking of coming up with an ICDIDisposable. CDT would
> >instanceof for that interface and call it where available for
> >implementations of the above three interfaces and possibly more in
> >the future where we find a need. Any objections?
> >
> >John
> >
> >_______________________________________________
> >cdt-debug-dev mailing list
> >cdt-debug-dev-j9T/***@public.gmane.org
> >https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
> >
> >--
> >IMPORTANT NOTICE: The contents of this email and any attachments are
> >confidential and may also be privileged. If you are not the intended
> >recipient, please notify the sender immediately and do not disclose
> >the
>
> >contents to any other person, use it for any purpose, or store or
> >copy the information in any medium. Thank you.
> >
> >
> >_______________________________________________
> >cdt-debug-dev mailing list
> >cdt-debug-dev-j9T/***@public.gmane.org
> >https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev-j9T/***@public.gmane.org
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
>--
>IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the

>contents to any other person, use it for any purpose, or store or copy
>the information in any medium. Thank you.
>
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev-j9T/***@public.gmane.org
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev-j9T/***@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

--
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
John Cortell
2009-01-14 22:15:29 UTC
Permalink
I've added the capability in our commercial product to quickly toggle
in and out of a mode that limits CDT/CDI stack crawls to one frame.
The limit is not simply an optimization at the GUI (Debug view)
level. The CDI backend is asked for only one frame, which (in theory)
means the debugger engine only needs to retrieve one frame from the
target. When debugging a slow target that is in deeply nested code,
this mode can be used to reduce the overhead of stepping (reduce the
amount of interaction with the target on every step.)

If there is any interest out there for this feature, I will
contribute it to CDT 6.0.

John
Loading...