Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Miles Bader Newsgroups: comp.lang.c++ Subject: Re: Debugger Recommendation Date: Thu, 15 Sep 2011 19:29:00 +0900 Organization: NEC Electronics Lines: 23 Message-ID: References: <4e71c098$0$24024$a729d347@news.telepac.pt> <9de0qpF2gmU7@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net djHkPLHCVYKwr/xa3+SCEwv47BJNZTaIY3t2DVuibhqfG7Sk4s Cancel-Lock: sha1:LnILDU4ReqBuO+5gINgtGQoXqOM= sha1:sydWhaRwrqIl6ugY7dttCjsgNwc= System-Type: x86_64-unknown-linux-gnu Blat: Foop Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:10158 Ian Collins writes: >> Having a debugger that integrated valgrind, and for instance, would >> let one examine the program state when a particular erroneous >> operation occured (e.g., reading uninitialized data) would be useful. > > That's how dbx works, access and leak checking are integrated in the > debugger and you can specify which classes of errors (read/write to/from > unallocated/uninitialised and so on) case a break. What does it do in the case of a leak (and similar "historical" analysis)? The point of the leak is not the point of detection, but it's the _former_ which is interesting. As recording the entire state of a program for every allocation is probably too expensive for any non-trivial program, it doesn't seem there's much the debugger can do other than act as a convenient "show me this source file location" tool.... -Miles -- Fast, small, soon; pick any 2.