|
From: Jeremy F. <je...@go...> - 2002-11-25 19:45:18
|
On Sun, 2002-11-24 at 22:05, James Maynard wrote: > I am having problems with your spam filtering so lets see if at least one of you gets this ;-) Hm, I got it, but I did find it in my spam folder. Oh, yeah, better tell my filter that js...@sf... is OK. A couple of comments: it would be nice if you could generate patches rather than send the whole source file. Also, it would be nice if you could say what version you started with, since that would avoid confusion. It would be particularly useful if you could grab the current CVS head version (http://sourceforge.net/cvs/?group_id=46268), and generate patches against that, since it is the current development version and is quite different from the 1.0 versions. Ah, OK, it's against 1.0.4. From having a look through the patch, a couple of things sprung to mind: 1. We definitely want the suppressions file to be in *mangled* form rather than demangled. The suppressions can have '*' as a wildcard match, and if the suppressions were demangled, every pointer would look like a wildcard. On the other hand, the mangled form is definitely painful to work with (Julian, Nick: what were the original motivations for using mangled names suppression matches?) 2. The code in vg_memory.c:suppressable() seems a bit clumsy. Can't you use a loop rather than assume there's only four levels in the suppression matching stack? And I'm pretty sure that functionality must already exist elsewhere (I guess; I still haven't really looked into the suppression machinery) - can you work out how to reuse that? Probably something to do with using VG_(maybe_record_error)() rather than VG_(message)() in VG_(detect_memory_leaks)(). J |
|
From: Jeremy F. <je...@go...> - 2002-11-26 01:19:40
|
[ You should "reply to all" to this; Julian is really the person you
need to convice about this stuff, and posting to the developers list is
the best way of making sure the right people see the conversation. ]
On Mon, 2002-11-25 at 16:35, James Maynard wrote:
> [James Maynard]
> I would supply a patch if I knew how how to put one together!
A patch is just the output of "diff -u oldfile newfile".
> [James Maynard]
> Writing the suppression file in mangled form is a pain
> in the but since the leak trace is in demangled form.
> We either dump the trace in mangled form and suppress
> in mangled form or dump in demangled form and suppress
> in demangled form. any other combination seems clumsy.
I tend to agree with you.
> [James Maynard]
> The suppression code is a replication of similar code
> in your code base.
Urk.
> I could have used dynamically allocated arrays and
> loops instead but I was not sure if this was a problem
> seing as we are checking memory allocation. Other
> places in the code do not use dynamic memory
> allocation so I was unsure about the efficacy of using
> it.
It works, but I think it can get a little inefficient. Still, loops
over static arrays are better than the opencoded version.
J
|
|
From: James M. <Jam...@na...> - 2002-11-26 01:34:24
|
OK I shall clean it up and supply a patch for you. Stay tuned -----Original Message----- From: Jeremy Fitzhardinge [mailto:je...@go...] Sent: Tuesday, 26 November 2002 9:19 AM To: James Maynard Cc: Valgrind Developers Subject: RE: FW: valgrinds suppression of leak errors [ You should "reply to all" to this; Julian is really the person you = need to convice about this stuff, and posting to the developers list is = the best way of making sure the right people see the conversation. ] On Mon, 2002-11-25 at 16:35, James Maynard wrote:=20 [James Maynard]=20 I would supply a patch if I knew how how to put one together!=20 A patch is just the output of "diff -u oldfile newfile".=20 [James Maynard] =20 Writing the suppression file in mangled form is a pain in the but since = the leak trace is in demangled form. We either dump the trace in mangled = form and suppress in mangled form or dump in demangled form and suppress = in demangled form. any other combination seems clumsy.=20 I tend to agree with you.=20 [James Maynard] =20 The suppression code is a replication of similar code in your code base. = Urk.=20 I could have used dynamically allocated arrays and loops instead but I = was not sure if this was a problem seing as we are checking memory = allocation. Other places in the code do not use dynamic memory = allocation so I was unsure about the efficacy of using it.=20 It works, but I think it can get a little inefficient. Still, loops = over static arrays are better than the opencoded version.=20 J=20 ____ This communication contains information which is confidential and the = copyright of Nautronix.=20 If you are not the intended recipient of this communication please = delete and destroy all copies and advise Nautronix immediately. If you = are the intended recipient of this communication you should not copy, = disclose or distribute this communication without the prior authority of = Nautronix. Any views expressed in this Communication are those of the = individual sender, except where the sender specifically states them to = be the views of Nautronix. Except as required at law, Nautronix does not represent, warrant and/or = guarantee that the integrity of this communication has been maintained = nor that the communication is free of errors, virus, interception or = interference. |