Krzysztof,
Regarding Poser, your article says:
Another way is to run your program using POSE, a PalmOS emulator and use a debug rom (which you can get if you participate in Palm's Solution Provider Program). If you have leaks in your program debug rom will tell you about this upon exiting. Unfortunately it only tells you the source file where the leak occured but doesn't tell you the exact line. You still have a lot of guessing to do.
I'd like to suggest three alterations to this paragraph.
First, finding memory leaks with Poser does not require a debug ROM. A release ROM downloaded from a device will work as well. What's mostly required from a ROM is that functions names are embedded in the ROM after the functions themselves (the so-called Macsbug symbols). Most ROMs have these -- even Release ROMs -- though some don't for space reasons. Without those names, all Poser can do is report memory addresses.
Second, Poser reports the function in which a leak occurs, not the source file. Poser has no way of finding the source file, since that information is not included in the ROM or .prc file, and Poser does not avail itself of any external symbolic debugger files.
Finally, when running under Poser, it's not the debug ROM that reports the leak, but Poser itself. There are some ROMs that are instrumented with routines to report memory leaks when an application exits, but Poser overrides this reporting and provides its own, which includes more specific information to help the developer.
By the way, the "My Way" section of your article pretty much describes the way Poser's memory leak algorithm works. From what I can see, the advantages of your approach are that it (a) records the line that performed the allocation, and (b) it can also work on PalmSim. On the other hand, I feel that Poser's approach (a) is less intrusive, (b) is faster, (c) works when the memory allocation is actually performed by the ROM, (d) is more helpful by showing a stack backtrace at the time the function was called and shows the contents of the leaked block for possible identification, and (e) is good enough (hopefully, merely identifying the leaking function is sufficient for determining the reason for the leak).
-- Keith Rollin -- Palm OS Emulator engineer
On Aug 13, 2004, at 7:17 PM, Krzysztof Kowalczyk wrote:
On Fri, 13 Aug 2004 21:31:28 -0000, Merav Rubinstein <[EMAIL PROTECTED]> wrote:I have a note that say that I can find the memory leaks in a log file, but I don't understand a thing from it...Can I know what's the problem from the log file?
I once wrote an article about a better way to detect memory leaks in Palm OS. You can read it here: http://www.fifthgate.org/articles/palm_mem_leaks.html
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
