发信人: kevins()
整理人: jkf(2001-07-15 20:38:07), 站内信件
|
There are a small set of common issues that many developers have experienced as they test their applications under Palm OS? software version 3.5, particularly when using debug-enabled ROMs. This is a list of the problem symptoms which have been experienced frequently, and their most common causes.
Note that some of these error messages only occur on debug-enabled ROMs, and not on the "release" (non-debug) ROM images that customers will use. This is to be expected: the debug ROMs will find bugs that might be very hard to reproduce on a normal device. You should heed all warnings and errors on debug-enabled ROMs so that your applications have the greatest stability on current and older devices, and best compatibility with future releases of the operating system and hardware devices.
For more information on these and similar issues, join discussions in the developer forums via email and newsgroups.
For more Palm OS? software version 3.5 documentation and a software overview, see the main Documentation page.
Problem Symptom:
Fatal alert "DataMgr.c, Records left locked in closed unprotected DB" as soon as you start a debugging session with CodeWarrior , before the application starts running
Problem Cause:
The debugger isn't setting its first breakpoint in a 100% reliable way. A newer debugger nub in the 3.5 SDK fixes this issue.
Solution:
Upgrade to the newer DebuggerNub included in the Palm OS 3.5 SDK, or simply press "Continue".
Additional Info:
The message only occurs on a debug rom. There are other situations in which the same error message is displayed that aren't caused by the debugger.
Problem Symptom:
Fatal alert "DataMgr.c, Records left locked in closed unprotected DB" when your application quits or closes one of its databases
Problem Cause:
As the message says, records or resources haven't been unlocked before their database has been closed. If an application continues to read or write the data in that record or resource, it is at risk because another application could delete the database which would make the pointer invalid, even though it was locked.
Furthermore, another application could open the database with write access and delete the record, which would again invalidate the pointer.
Solution:
If it is actually necessary to keep using a record or resource after closing the database that contains it, then use the DmDatabaseProtect() function to prevent the database from being deleted. In nearly all cases, however, the correct thing to do is to unlock a record immediately after using it. This also helps prevent memory fragmentation.
Additional Info:
The message only occurs on a debug rom, but the potential problem it warns of can happen on any rom.
Problem Symptom:
Fatal alert "DataMgr.c, Records left locked in closed unprotected DB" when developing a "hack" and enabling it with HackMaster version 0.9.x
Problem Cause:
HackMaster is keeping the code segments in a hack locked, but is not protecting the hack databases against being deleted. This means that if the user deletes the hack while it is active, or installs a newer version of the hack, the system will almost certainly crash.
Solution:
This is a bug in HackMaster, and needs to be corrected in a future release of HackMaster by having it call DmDatabaseProtect(). It may be possible for a "hack" to protect its own database and thus prevent this problem for itself.
Additional Info:
The message only occurs on a debug rom, but the potential problem it warns of can happen on any rom.
There are other situations in which the same error message is displayed that aren't caused by HackMaster.
HackMaster is not a product of Palm, Inc., but since it is widely used by the developer community we are informing developers of this potential crashing problem.
Problem Symptom:
Fatal alert "SystemMgr.c, Possible memory leak at 0x000xxxxx...Use the 'hd 0' command to find chunks owned by your app. These chunks have an ownerID of 2" when your application quits
Problem Cause:
Not all memory allocated by your application has been freed when it quits.
Solution:
Free all the memory that you allocated. One common item to miss is to call FrmCloseAllForms() when your application is quitting, usually in your AppStop function. (Even the Starter project in the pre-3.5 SDKs had this bug.)
Palm OS does automatically clean up all application-allocated memory in the dynamic heap after the application quits, but depending on what kind of memory is being leaked and its size and whether it is cumulative, your application might have a potentially serious bug that needs addressing.
Do use the 'hd 0' command in the debugging console window to examine the dynamic heap, and the contents of the memory chunk identified by this error message. Or use standard debugging techniques to identify the leak; memory leaks are common problems on every kind of application on every kind of computer.
Additional Info:
The message only occurs on a debug rom, but the memory leak could be occurring on any rom.
Problem Symptom:
Fatal alerts "Form.c, Form must be full width" or "Form.c, Form must be bottom justified"
Problem Cause:
Forms, other than the topmost form, must be the full width of the screen. The debug rom checks for this condition when removing a form from the screen (inside FrmEraseForm).
Solution:
Make the form the full width of the screen. Note that the left coordinate might need to be 1 or 2, and the width less than 160, if there is a border to the form.
Additional Info:
The message only appears on debug roms.
There may be an issue with popup lists and alarms which may trigger this message unavoidably.
Problem Symptom:
Fatal alert "Form.c, Windows cannot be under forms because they can't be redrawn"
Problem Cause:
If a window is underneath a form, the window manager has no way to redraw it when the form closes. If the other form hasn't saved the contents of the window, then it could result in a improperly blank area of the screen and user confusion.
Solution:
Change the code to use a form, so that a frmUpdateEvent may be sent to the form's event handler to get it to redraw as necessary. Or, close the window before another form appears above it.
Additional Info:
The message only appears on debug roms, but the non-redrawing problem could happen on release roms.
There may be an issue with popup lists and alarms which may trigger this message unavoidably.
Problem Symptom:
Application crashes while drawing, particularly either right on startup or when switching to a new form
Problem Cause:
If there isn't yet a valid window created or designated as active, drawing routines on a debug rom will generate a bus error. This is to help developers find situations in which they are drawing in the wrong context, or unnecessarily.
Solution:
Don't draw to a form until FrmDrawForm has been called to draw the form's background and establish it as the active form.
Additional Info:
On a release rom, if there is no active window, drawing will draw right on the main (root) window. This will often have the intended result, but not necessarily. Fixing the application to target the drawing properly is usually the right thing to do.
Problem Symptom:
After a dialog is dismissed, areas of the screen are blank or elements aren't drawn properly.
Problem Cause:
Most likely, the frmUpdateEvent isn't being handled correctly. When a form handler receives a frmUpdateEvent, the application must make sure to call FrmDrawForm and then draw anything on the display that isn't drawn by the standard form objects (e.g. gadget contents).
Solution:
Add a handler for frmUpdateEvent, which calls FrmDrawForm and does any other necessary drawing, and then returns True indicating that it has done all the necessary drawing.
Additional Info:
Many pop-up windows and forms have set the "saveBehind" bit, which tells the system to save the contents of the screen that they are going to obscure. However, if the system doesn't have enough free memory to save the screen bits, it will send a frmUpdateEvent to the forms when the obscuring one is closed. To help applications make sure they properly handle this update event, the debug rom mimics a low-memory situation by saving but never restoring the bits, and sending the frmUpdateEvent.
Problem Symptom:
Application does not run on a color device, crashes at startup.
Problem Cause:
If an application has made assumptions about the screen, and/or is directly addressing the Dragonball LCD controller or other pins on the chip, it has a very low chance of success on color or future devices.
Solution:
Use the supported APIs, and/or verify the characteristics of the hardware and display and OS before trying something unsupported and risky. There are features published in the Feature Manager which give information about the hardware and system software (see sysFtrNumProcessorID, sysFtrNumHwrMiscFlags, HwrMiscFlags.h...) and WinScreenMode and WinGetBitmap may also be extremely informative.
Not all devices will necessarily use the LCD controller on the Dragonball chip.
Problem Symptom:
The screen is cleared to black (or yellow on a color device) when applications start, and some might remain on the screen when the application is running
Problem Cause:
This is a debugging aid on debug roms. The system clears the screen to an unusual color so that if any remains on the screen, it indicates to the developer that the application hasn't completely drawn everything that it might need to.
Solution:
If none of the color remains on the screen, everything is working correctly. If any remains, then adjust your code to properly draw to that area of the screen.
Additional Info:
Only happens on debug roms.
Problem Symptom:
Some buttons in alerts are wider than they used to be in pre-3.5 versions of Palm OS software
Problem Cause:
When calling FrmAlert, FrmCustomAlert or FrmCustomResponseAlert, the system always would resize the alert's buttons to match the width of the text of the button, plus a small margin. In 3.5, the system also imposes a minimum width of 36 pixels to improve the appearance. (This expansion does not happen if there isn't room to expand the button width.)
Solution:
This is not a bug; it is working as intended so that the user has buttons of a more reasonable width to tap upon.
Problem Symptom:
The automatic cut/copy/paste/undo buttons on the 3.5 command bar appear correctly, but don't do anything when tapped.
Problem Cause:
The application is probably incorrectly saying that it handled the event sent by the command bar. If an application's event handling routine always returns TRUE for menu events, even those it doesn't actually handle, then the system doesn't get a chance to process those buttons. (These buttons send menu events with IDs >=10000, which are in the system reserved range.)
Solution:
Only return TRUE from your event handler if you've fully handled an event and don't want the system to take action on it.
Additional Info:
If your application needs to handle these events on its own, either add your own buttons to the command bar when you get a menuCmdBarOpenEvent, or else handle the menu command events with IDs 10000 to 10003 (sysEditMenuUndoCmd through sysEditMenuPasteCmd) yourself.
Problem Symptom:
Application runs out of memory when the screen is in 8-bit mode, or when using color bitmaps.
Problem Cause:
Color bitmaps take up eight times as much memory as black and white ones do, so memory requirements for color bitmaps are higher than applications may have had to deal with previously.
Solution:
Restructure your design to be more mindful of memory, and/or work on color bitmaps in segments if necessary.
Additional Info:
The largest amount of memory allocatable on the dynamic heap is still 64k, so allocating very large color bitmaps may not be possible.
Problem Symptom:
CodeWarrior Compilation Error: the file 'Us.Prefix.h' cannot be opened...
Problem Cause:
The project is referring to an old file which no longer exists in the SDK.
Solution:
Go to the "C/C++ Language" settings panel for your project. At the bottom you'll see an entry for "Prefix file". Remove the reference to Us.Prefix.h and all should be well.
Problem Symptom:
Application displays two squares in place of the Dollar ($) symbol.
Problem Cause:
The application is directly parsing the "cnty" resource, a private system resource whose format can change (and has).
Solution:
Don't do that. There is currently no API in the operating system to determine the currency symbol for a given country.
Additional Info:
The built-in Expense application does access this resource directly, but it isn't safe for third party applications to do so.
Problem Symptom:
Tapping on the title bar doesn't bring up the menu
Problem Cause:
Application is intercepting the pen taps, or is not letting the system handle the frmTitleSelectEvent.
Solution:
Let the pen tap or event be handled by the system, or change your code to enqueue a frmTitleSelectEvent, or enqueue a menuChr to display the menu in the appropriate circumstances.
Additional Info:
When the user taps on the screen, a penDown event is sent. The system's form event handler function will generate a frmTitleSelectEvent if the user pressed and released it on the title. When that frmTitleSelectEvent is handled by the system, it enqueues a menuChr, which when handled will display the menus.
Problem Symptom:
Euro symbols are displayed instead of blank space
Problem Cause:
Some applications used the "numeric space" character to lay out data in a table form. In Palm OS 3.3, the numeric space character was replaced by the Euro currency symbol.
Solution:
Do the spacing without using a numeric space, or use the ChrNumericSpace macro (new in 3.5) to determine the correct character to use for the device in use.
Problem Symptom:
Callbacks written in assembly, or by a version of gcc which relies upon register A4 being set automatically, now crash.
Problem Cause:
Some applications were written in such a way that they assumed that the A4 register, or some other register, was preserved or set to a particular value by the system when invoking a callback routine. In short, they were getting lucky since nothing was guaranteeing this behavior, and in newer versions of the OS the register may have been used for some other purpose by the routine calling the callback.
Solution:
A5 is the register reserved for global variable access. The other registers are not guaranteed to be preserved. Change the code to get the information via reliable methods. (Sometimes the Feature Manager may be appropriate.)
Problem Symptom:
SerSetSettings can now return a serErrNotOpen error code.
Problem Cause:
If called before the serial library has been opened, SerSetSettings will now properly return an error code. Previously, if called before the library was open, SerSetSettings wouldn't return an error but would write the setting to low memory.
Solution:
Open the library before calling SerSetSettings.
|
|