|
From: Scot M. <sco...@or...> - 2005-11-08 01:38:22
|
Hi, sorry upfront if this has already been covered. I noticed the proposal about desupporting addrcheck. I would like to put out that addrcheck is still useful, and ask if there has been any work to get it supported in 3.0.1? Specifically, Oracle has a case where memcheck is unusable, whereas addrcheck is, due to its performance benefits (both cpu consumption and memory usage). Or, are there options we can give to memcheck to reduce it's memory/cpu consumption to be comparable to addrcheck. Thanks in advance. Regards, -sm |
|
From: Julian S. <js...@ac...> - 2005-11-08 02:37:11
|
On Tuesday 08 November 2005 01:38, Scot McKinley wrote: > Hi, sorry upfront if this has already been covered. > > I noticed the proposal about desupporting addrcheck. I would like to put > out that addrcheck is still useful, and ask if there has been any work > to get it supported in 3.0.1? > > > Specifically, Oracle has a case where memcheck is unusable, whereas > addrcheck is, due to its performance benefits (both cpu consumption and > memory usage). Can you give some details of the problem: the platform you're running on, what V says when it fails, and roughly what memory demands the program has. Memory management, especially for large programs, has improved since 3.0.1, and you might have more luck trying the latest svn sources, especially on a 64-bit machine, where we now support memchecking programs which take up to about 14G natively. Try this: svn co svn://svn.valgrind.org/valgrind/trunk cd trunk ./autogen.sh configure and build as usual I'd really like to get rid of addrcheck as I don't believe its hassle-to- usefulness ratio justifies its continued existence, given that memcheck provides a superset of the functionality. J |
|
From: Scot M. <sco...@or...> - 2005-11-08 02:58:17
|
It is not that easy. ie, valgrind didn't fail. Instead, Oracle failed, because valgrind was too d*mn slow!!! ;-) I actually dont care whether you call it addrcheck, or "memcheck w/ an option to make it less heavy weight". They are obviously equivalent. Specifically, can memcheck be utilized in manner that gives us the more fatal errors (MLK/ABR/ABW/SBR/SBW/IPR/ZPR/NPR/COR/...), but doesn't check for the more mundane errors (mainly UMR and PLK). Definitions: ABR: Array bounds read: COR: Fatal core dump: IPR: Invalid pointer read: MSE: Memory segment error: NPR: Null pointer read: SBR: Stack array bounds read: SIG: Signal handled: UMR: Uninitialized memory read: ZPR: Zero page read: UMR: Uninitialized Memory Read PLK: Potential LeaK I will also try out the post 3.0.1 stuff you mentioned. Thanks, -sm Julian Seward wrote: >On Tuesday 08 November 2005 01:38, Scot McKinley wrote: > > >>Hi, sorry upfront if this has already been covered. >> >>I noticed the proposal about desupporting addrcheck. I would like to put >>out that addrcheck is still useful, and ask if there has been any work >>to get it supported in 3.0.1? >> >> >>Specifically, Oracle has a case where memcheck is unusable, whereas >>addrcheck is, due to its performance benefits (both cpu consumption and >>memory usage). >> >> > >Can you give some details of the problem: the platform you're running >on, what V says when it fails, and roughly what memory demands the >program has. > >Memory management, especially for large programs, has improved since >3.0.1, and you might have more luck trying the latest svn sources, >especially on a 64-bit machine, where we now support memchecking >programs which take up to about 14G natively. Try this: > > svn co svn://svn.valgrind.org/valgrind/trunk > cd trunk > ./autogen.sh > configure and build as usual > >I'd really like to get rid of addrcheck as I don't believe its hassle-to- >usefulness ratio justifies its continued existence, given that memcheck >provides a superset of the functionality. > >J > > |
|
From: Dirk M. <dm...@gm...> - 2005-11-08 10:20:36
|
On Tuesday 08 November 2005 03:41, Julian Seward wrote: > I'd really like to get rid of addrcheck as I don't believe its hassle-to- > usefulness ratio justifies its continued existence, given that memcheck > provides a superset of the functionality. The superset is exactly the problem - it makes valgrinded apps so slow that you don't want to run it longer than anyhow necessary :( addrcheck did provide a small speedup. |