A very good debugger

Hi,

I think it might interest many of you:
http://www.lambdacs.com/debugger/debugger.html
This is a debugger that records everything that occurs within a java
program and let's the user navigate in time to find where erroneous
behaviour started...
It is still a prototype... It would be really very nice to have IntelliJ
implement it in IDEA!

16 comments
Comment actions Permalink

Hi,

Can you imagine the number of info it has to store in the complex project?
If yes, than you can imagine how slow it should be.

BTW Have you tried it?

--
Best regards,
Mike Aizatsky.
-


JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


0
Comment actions Permalink


"Mike Aizatsky" <mike@intellij.com> wrote in message
news:atv9fs$b0b$1@is.intellij.net...

Hi,

>

Can you imagine the number of info it has to store in the complex project?
If yes, than you can imagine how slow it should be.

>

BTW Have you tried it?

>

I agree; I don't think you can really work with it.
Any practical experience would be interesting.

--
Best regards,
Mike Aizatsky.
------------------------------
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"

>
>


0
Comment actions Permalink

This isn't the only debugger that does this.

http://www.visicomp.com/

Sorry though, I don't have any experience with it. I too am a little mystified how they could make a debugger like this practical.

0
Comment actions Permalink

I was waiting for 30 minutes for RetroVue to finish patching IDEA classes &
then killed it.

--
Best regards,
Mike Aizatsky.
-


JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


0
Comment actions Permalink

I have tried it with the demo that comes with it. As it is a very simple
sorting program there is no noticeable slowdown in program execution. Of
course there actually is one, but as I have not been able yet to test it
for a real project, I don't know how slow it might get.
However, the idea is to instrument only the classes that are being
debugged (ie trusted classes do not need instrumentation).
I am ready to pay a slowdown of my application when I want to do this
kind of debugging, which is really much more adequate than traditional
debugging.

Mike Aizatsky wrote:

Hi,

Can you imagine the number of info it has to store in the complex project?
If yes, than you can imagine how slow it should be.

BTW Have you tried it?

--
Best regards,
Mike Aizatsky.
------------------------------
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


0
Comment actions Permalink

Guillaume wrote:

This is a debugger that records everything that occurs within a java
program and let's the user navigate in time to find where erroneous
behaviour started...


That is funny. We have just been discussing that on the German Java
newsgroup. Would it really be too bad, like, just storing a copy of all
watched variables for each step done? Like that you could avoid the "what
was that again" problem. Alternatively we were talking about a
"stop-debugging-restart-and-stop-at-last-xxxx" where xxx is breakpoint or
last step.

Best regrads,

Dirk Dittert
(who stopped developing with pleasure for the holiday break)

0
Comment actions Permalink

Dirk,

>>This is a debugger that records everything that occurs within a java
>>program and let's the user navigate in time to find where erroneous
>>behaviour started...


That is funny. We have just been discussing that on the German Java
newsgroup. Would it really be too bad, like, just storing a copy of all
watched variables for each step done? Like that you could avoid the "what
was that again" problem. Alternatively we were talking about a
"stop-debugging-restart-and-stop-at-last-xxxx" where xxx is breakpoint or
last step.


As far as I remember Borland C/C++ ide had this kind of feature like 8-10 years ago.
It did not keep all the info, but only from several last steps which is in fact
absolutely enough to support this "what was that?" :)

I don't know about these debuggers you are talking about but keeping all this info
during a program execution is not justified for the purpose, unless we have some
super-puper computer with terrabytes of RAM and terrahertz CPU.

--
Dmitry Skavish
-


Boston, MA, USA
tel. +1 781 370-6909
http://www.jzox.com
http://www.flashgap.com

0
Comment actions Permalink


"Guillaume" <gpothier@free.fr> wrote:

However, the idea is to instrument only the classes that are being
debugged (ie trusted classes do not need instrumentation).


I tend to agree. Filtering the classes you want to record the history for
should give you enough control over the amount of data you capture. An
option to "expire" older data once you reach a certain amount of info could
also help improving the memory usage.

I am ready to pay a slowdown of my application when I want to do this
kind of debugging, which is really much more adequate than traditional
debugging.


Same here.

Andrei

>

Mike Aizatsky wrote:

Hi,

>

Can you imagine the number of info it has to store in the complex

project?

If yes, than you can imagine how slow it should be.

>

BTW Have you tried it?

>

--
Best regards,
Mike Aizatsky.
------------------------------
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"

>
>

>


0
Comment actions Permalink

Dmitry Skavish wrote:

I don't know about these debuggers you are talking about but keeping all
this info during a program execution is not justified for the purpose,
unless we have some super-puper computer with terrabytes of RAM and
terrahertz CPU.


Why? It would be up to the user what should be traced. If you do not want
100eds of variables to be stored, why not just watch 3?

But you are right, there are several issues:
- do object then have to Serializable (as you want to store them for later
re-inspection or can this be done by reflection?
- how do you copy objects without loosing the link which object is which
(if it gets modified during several steps).

and by the way:

dittert@schlepptop:/privat/dittert> uname -a
Linux schlepptop 2.4.18-64GB #1 Wed Mar 27 13:57:05 UTC 2002 i986 unknown

dittert@schlepptop:/privat/dittert> cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 7
model : 14
model name : Pentium VI (Goldmine)
stepping : 6
cpu MHz : 69645554.986
cache size : 256 MB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips : 1389887.36

(I skipped the other 15 processors in my system)

Any questions ;))

Best regards,

Dirk Dittert

0
Comment actions Permalink

and by the way:

dittert@schlepptop:/privat/dittert> uname -a
Linux schlepptop 2.4.18-64GB #1 Wed Mar 27 13:57:05 UTC 2002 i986 unknown

dittert@schlepptop:/privat/dittert> cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 7
model : 14
model name : Pentium VI (Goldmine)
stepping : 6
cpu MHz : 69645554.986
cache size : 256 MB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips : 1389887.36

(I skipped the other 15 processors in my system)


"what was that?" :)

don't tell me that you are the only user on this monster, I won't sleep this night :)

--
Dmitry Skavish
-


Boston, MA, USA
tel. +1 781 910-3810
http://www.jzox.com
http://www.flashgap.com

0
Comment actions Permalink

Dmitry Skavish wrote:

"what was that?" :)

don't tell me that you are the only user on this monster, I won't sleep
this night :)


My personal machine. In a few years I will sell it to intel and they will
introduce it to the market as brand new ;)

I was just kidding ;)

Best regards,

Dirk Dittert
(that is the reason why you better keep students busy, otherwise they'll
just post nonsense to this newsgroup)

0
Comment actions Permalink

>>"what was that?" :)
>>don't tell me that you are the only user on this monster, I won't sleep
>>this night :)


My personal machine. In a few years I will sell it to intel and they will
introduce it to the market as brand new ;)

I was just kidding ;)


:) yeah, I figured it out. but you know, just in case I visited www.top500.org,
just to make sure and you know what, I found similar configurations there :)
check it out yourself!

(that is the reason why you better keep students busy, otherwise they'll
just post nonsense to this newsgroup)


posting nonsense is ok. makes life less serious ...

--
Dmitry Skavish
-


Boston, MA, USA
tel. +1 781 910-3810
http://www.jzox.com
http://www.flashgap.com

0
Comment actions Permalink

Linux schlepptop 2.4.18-64GB #1 Wed Mar 27 13:57:05 UTC 2002 i986 unknown


i986???

cpu MHz : 69645554.986


Dude! 69THz?

(I skipped the other 15 processors in my system)

Any questions ;))


Um. Yes. What? How? Where? ;)

Ciao,
Gordon

--
Gordon Tyler
Software Developer, R&D
Sitraka (now part of Quest Software)
"Performance is Mission Critical"

0
Comment actions Permalink

it would be nice to be able to start this and then stop it. Like start at this breakpoint and then stop at the next breakpoint.

0
Comment actions Permalink

I belive that Bill (the author) is well aware of this being a potentialy killer.
There's a number of ODB settins you can do to deal with this.
You can set the already mentioned "trusted" classes - in fact by default all the libraries are trusted.
You can tell the debugger when you want to start recording, and how much memory is it allowed to store recorded things in.
ODB also does some optimizations where the values can be always, provably deterministically computed, like in some loops (modifying local variables only, calling only deterministic methods - i.e. again local variables and params only).
Regards,
Vlad

0
Comment actions Permalink

I have used similar products in the Win/Intel C++ world. While slow and sometimes complex to configure they are often the best way to track down the most elusive bugs especially random ones.
You can think of it as the fancy way to do what C programmers call printf debugging. If you find that you are adding lots of log.Debug or system.println calls to find a bug then a tool like this will really come in handy.

0

Please sign in to leave a comment.