From arthur@aiai.ed.ac.uk Thu Jun 1 12:39:10 1995 Received: from subnode.aiai.ed.ac.uk (burray) by aiai.ed.ac.uk; Thu, 1 Jun 95 12:39:06 BST Date: Thu, 1 Jun 95 12:39:04 BST Message-Id: <11776.9506011139@subnode.aiai.ed.ac.uk> From: Arthur Seaton Subject: Memory checking code To: jacs@aiai.ed.ac.uk Status: REO > BTW, here's a memory test. You know the debuggeration code > you wrote during Gryphon's heady months -- do you happen > to have it still, and maybe any notes...? Just dug it out for you. It's in /home/gryphon/arthur/src/memory. The Makefile should tell you the files that you require. Seems to be just mem.{h,cc} which provide the debugging and testmem.cc which is a test. First - I am _not_ a good C++ programmer so I expect that I've done a number of things badly! Personally I find C++ hard to use and worse to understand! It is commented and I usually keep comments up to date. Can't remember if I did in this case, but I don't see why I wouldn't have done. It was based on the ideas in that "No bugs" book of yours. That's all the "notes" that I have apart from the comments in the code itself. However porting to C++ adds problems of its own (see the vtbl problem below). Second - the dates indicate that I did this work just over a year ago. My God, I have done some programming in the past 2 years :-) On to the code itself... Looking at the comments it seems to work by adding a struct before the requested memory and placing 3 markers around the memory. 1 within the struct itself, one just after the struct and before the memory and 1 after the caller requested memory. Each of these is tested to check that they have not been overwritten. Checking can be done at various times controlled by the user of the package. >From memory (sorry!) there are a few problems: - underwrites are really difficult to test using this scheme. If the struct itself is overwritten you lose with no way of recovering. eg. member func within struct are overwritten and you try to call one of these funcs. I _think_ one way round this is to make everything non-virtual so there's no vtbl to get overwritten. Can't remember if I did this (it does have some disadvantages in loss of flexibility obviously) and I'm not entirely sure that it would have the desired effect. I'd need to check out the ARM and even then I suspect it's compiler specific. - Doesn't seem to compile under gcc-2.1. All seems to be ok using gcc-2.4.5. - There's a Makefile for the HP, but I can't remember what happened when I tried it out on the HP - sorry! - There's not been much testing done. Basically just testmem.cc which is obviously just a pre-alpha type testing! > I'd like to > throw it at wxwin-users to see if anyone wants to play with > it/finish it; it'd be a nice wxWin feature to have. Fine. I _may_ do some work on it myself in which case I'll copy it out of there and work on it elsewhere. If I do then I'll let you know and pass through anything that may be useful to you. Hope this is of some help, Arthur. Some further notes on debugging features - JACS May 1995 MFC has the CObject::Dump member for dumping info. It would be nice to be able to stick a 'probe' into an application whilst running, espec. the version actually distributed to a user. We could have a standard method for outputting debugging info *conditionally*; e.g. DEBUG_OUTPUT(2, "Shouldn't get here\n"); where 2 represents the level of detail. A global level of detail may still produce voluminous debugging info, so it would be nice to specify a module or 'context', e.g. DEBUG_OUTPUT("wxWindows:wx_win.cc:1", ...); where there's a hierarchical module system. If the current module is "wxWindows" then lots of stuff is output. If module is "wxWindows:wx_win.cc", then not so much. We could even use the regular expression code for the spec. up until the level number. May reduce speed substantially to use a regex evaluator though. We can have a standard way of communicating to a wxWin program, e.g. via DDE. A wxWindows debugger client allows querying of debugging info and display/file logging of the info remotely. Similarly we can reduce debugging info for memory checking, homing in on a particular module: perhaps using macros that give another argument to New. E.g. for a particular file, #define DEBUG_NEW2 new(__FILE__, __LINE__, "wxWindows:wx_win.cc") #define new DEBUG_NEW2 We'd have to try to keep the DDE flow small, so most of the time it's just used for issuing commands/getting status info. But it would be nice to be able to display debugging info as it came through... WIN32 + pipes may be the answer, or WinSock...