|
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 > > |