![]() |
Leakhunt
Updated 08 Jun 2002
|
Upper levels: - QuArK Information Base - 4. The Source Code |
4.8. Leakhunt |
[ | - - ]
User reports and the use of Atanas Stoyanov's Memproof reveals a substantial assortment of resource and memory leaks. Unfortunately it's not entirely clear which ones are genuine and which ones are Memproof misreports or Delphi bugs, but it is possible that most of the really important ones have been dealt with. So here are listed various things that still appear, organized by when they show up, followed by some other items. These leaks only include those reported when the `specifics sharing' scheme is disabled, by compiling with the flag `Noshare'. Sorting the apparent specifics-sharing scheme leaks out is a challenge we have not yet risen to (since specifics sharing is arcane, involves assembler code, etc., the reports may well be spurious). Developer Mode in QuArK also enables a command to track memory usage, and compare current used message to that from the last call to it. This can be used to tell if inordinate amounts of memory are being consumed by map editing operations (of course the undo stack will get bigger as editing procedes, etc.) |
Index |
Opening and Closing QuArK |
tiglari - 08 Jun 2002 | [ Top ] |
|
Open/Close Map Editor |
tiglari - 08 Jun 2002 | [ Top ] |
|
Unfreed Event (don't mess with) |
Decker (mostly) & tiglari - 08 Jun 2002 | [ Top ] |
The kernel error CreatEvent generated at QkFileObjects.pas:RestoreAutoSaved line 2061 should not be fixed by deleting the event; here's what Decker had to say about my attempt to do that: Oops I believe you just introduced "an unintended bug". I've looked at that particular piece of code before (less than a month ago I think), and made up my mind of what it does. Unfortunatly I never got around to document it. Armin should have done that, when he coded it. It has something to do, when running two or more instances of QuArK on the same machine at the same time, and the crashes of QuArK. Here's my thoughts of it: - The procedure is called "RestoreAutoSaved", so it might have something
to do with when QuArK crashes and is started again.
- There is a call to "GetCurrentProcessId" at the bottom of the
procedure. So some kind of 'uniqueness' is apparently needed.
- The call to "WaitForSingleObject" has a timeout-value of 0, e.g. don't
wait (quite strange!?).
- The file named "auto-save- - Note also, that any events owned by a process, the one who called CreateEvent(), gets automatically released/closed by the operation-system when that process stops/crashes. Thats why Armin never did nor should do a CloseHandle() on the last CreateEvent(), as it will destroy the purpose of the WaitForSingleObject() check. Phew... that was a bit much, for such a little thing ;-) I know a bit about event/mutex-semaphores, as I use them at work these days, porting an OS/2-application to Windows 2000 Advanced Server. |
Popup Menus (resolved) |
tiglari - 08 Jun 2002 | [ Top ] |
Well this one seems to be cleared by destroying the menubarhandle in the TPyForm.FormDestroy method in PyFroms.pas ... Easy money! ******* The User|Menu|CreatePopup Menu error appears to be noncrititical. 11 popup menus are created when the map editor is started, and not properly deleted on closure but operation of the map editor does not seem to create more of these errors. The menu creation code is run when the buttons in the button panel are pressed, but the resulting menus are propely deleted. However, it would probably be good to attend to this someday, since these popups, and one ordinary menu, are created and not deleted every time the map editor is started, so if it's started once in a session you get 12 menu errors; twice, 24. |
GNU General Public License by The QuArK (Quake Army Knife) Community - http://www.planetquake.com/quark |
[ Top - ] | -