This chapter discusses various problems people have encountered while writing and debugging their code. There are suggested solutions for each problem. If your problem is not in this chapter, please contact Metrowerks Technical Support for assistance using the contact information at the front of this manual. To contact Desktop Technical Support use:
http://www.metrowerks.com/support/desktop/
mailto:cw_support@metrowerks.com
For quick answers to commn questions, visit the Technical Support FAQ site at:
http://www.metrowerks.com/support/faq/
This chapter will expand to include more problems with each release of CodeWarrior.
The topic areas covered include:
This section discusses some problems that are commonly encountered when writing code for the Mac OS. This section continues to expand as more problems are encountered.
This section has one primary topic:
This problem and answer, by Apple Developer Support, appeared in the "Q &A" section of the August 1997 issue of MacTech magazine (Vol. 13. No. 8). It is reprinted here with permission. Metrowerks thanks the staff at MacTech for use of this question.
Sometimes, MacsBug generates a PowerPC unmapped memory exception
with an address that starts with the symbol BowelsOfTheMemoryMgr. What does this mean?
When you are displaying addresses in MacsBug, MacsBug shows offsets
from the last symbol it can find. In the Modern Memory Manager
on Power Macintosh computers up to Mac OS version 7.6, the last
symbol was __HSetStateQ. The code after __HSetStateQ consists of various internal Memory Manager subroutines. So,
if there's a hang or crash in an internal Memory Manager subroutine,
it shows up in MacsBug as __HSetStateQ+xxxxxxxx.
Various system software engineers were tired of seeing bug reports
that said __HSetStateQ was crashing, so beginning with Mac OS
7.6, we decided to add a new last symbol to the Memory Manager.
As a consequence, bug reports would be somewhat more informative.
We thought of naming the new symbol YourHeapIsCorrupt (since that's usually the case when a program crashes the Memory
Manager) but decided on BowelsOfTheMemoryMgr instead because that's where you are.
So if you're crashing or hanging at BowelsOfTheMemoryMgr+xxxxxxx, type HC to see if your heap is corrupted (it probably will be) and then
start debugging your code to find out how it got corrupted.
This section discusses problems encountered while using the CodeWarrior IDE on Mac OS computers.
This section discusses the following problem topics:
How do I run a Mac OS Application created on the Windows-hosted version of the IDE?
To solve this problem, you'll need Aladdin Systems' Stuffit Expander and DropStuff.
Follow these steps to solve the problem:
1. Ensure that the IDE post-links the application using the "MacBinarize Post Linker" option.
You use the Target Settings panel to select this post-linker.
2. Use the Make menu command to build your project.
Suppose you build a target named PPC Std C Console for a project named test.mcp, which you created from the Standard Console stationery. The
following files appear in the project's folder after the build
completes:
You must transfer only one of the following files from your project:
MacOS ToolBox Debug PPC.bin the file that duplicate's your file's name and adds a .bin extension.
In the example from the previous step, you would transfer the
file named test.bin. The transferred file appears on the Mac OS computer with an
icon that includes the letters "PC."
4. Drag and drop the .bin file onto DropStuff.
DropStuff converts the .bin file into a Stuffit archive (.sit file).
5. Drag and drop the .sit file onto Stuffit Expander.
Stuffit Expander converts the .sit file into a Mac OS executable file.
6. Double-click the Mac OS executable file.
The Mac OS application now runs on your computer.
I get the following error: local data > 32k. What is wrong?
The IDE issues this error after local-data totals exceed 32 kilobytes in size. The CodeWarrior Error Reference documents this error message.
To fix the problem, use one of the following techniques:
How do I install the Universal Intefaces (version 3.3.2)?
Follow these steps to install Univeral Interfaces into the IDE:
1. Locate the Univeral folder.
This folder resides within the MacOS Support folder of your CodeWarrior installation.
2. Replace the Univeral folder with the UniversalInterfaces3.3.2 folder.
Move the Universal folder inside the UniversalInterfaces3.3.2 folder so that the path structure looks like this:
UniversalInterfaces3.3.2:Universal:
3. Modify the Open Transport folder.
This folder resides within the MacOS Support folder. Modify the folder as follows:
Open Transport folder to (Open Transport).
Open Transport folder entirely.
Rebuild any pre-compiled headers in your project that the IDE
built with older headers. For example, rebuild MacHeaders.mcp, located in the following path:
MacOS Support:MacHeaders:
You might also find conflicts in MSL or custom pre-compiled headers in your own projects. If this situation occurs, rebuild MSL.
I get an error stating that my MPW Shell and my Mac OS are incompatible. What's wrong?
Your MPW version is incompatible with Mac OS 9. A newer, compatible version is available at the following web site:
http://developer.apple.com/tools/mpw-tools/
How can I use the CodeWarrior IDE to generate MPW object files?
Follow these steps to generate MPW object files:
1. Use the MPW compiler to compile (-c) your project.
Compiling the project with MPW automatically creates the object file.
2. Locate the CodeWarrior MPW folder inside your CodeWarrior installation.
3. Inside the CodeWarrior MPW folder, locate the file named MW ReadMe.
This file includes documentation on installing the MPW tools.
5. Enter the MPW shell commands for accessing help information.
Enter the following commands in the shell:
-macppc -help
The resulting screen displays all of your options. You mainly
use -c and -o when working with object files.
How can I look at my references using QuickView?
To use QuickView, follow these steps:
The IDE Preferences window appears.
2. Select the IDE Extras preference panel.
This panel appears in the hierarchical list along the left side of the IDE Preferences window.
The Find Reference using pop-up menu contains an option named QuickView. Select this option to use QuickView to look at your references.
This section discusses problems you may encounter while using the IDE debugger on the Mac OS. Problem topics include:
My code currently calls InstallExceptionHandler() with my exception handler. The handler currently assumes any exception is fatal, and aborts (after some cleanup and an appropriate message) if the exception type is not trapException or traceException; otherwise, it just returns noErr.
When I step through my code and try to step over the InstallExceptionHandler() call, the debugger never regains control, and my application hangs.
The problem is you are returning noErr from your exception handler. You should return noErr only if you completely handled the exception and want to resume
execution. If you do not handle the exception, return a non-zero
value and the next exception handler in the chain (MetroNub or
MacsBug) will get a chance to handle the exception.
Listing 13.9 shows what your exception handler should look like.
OSStatus MyExceptionHandler(ExceptionInformation *theException)
{
if (theException->kind == trapException ||
theException->kind == traceException)
return -1; //let the debugger handle the exception
else
{
... // whatever your handler wants to do
}
}
See also "Debugging C++ Exceptions."
Why do I crash when I try to debug inside a Drag Manager callback routine?
Debugging a Drag Manager callback is hard because the Drag Manager disables process switches. As a result, the debugger nub can't get control reliably. The latest nubs and system help this somewhat.
SysBeep() calls and other tricks to tell yourself how far along you are
and what's going on.
The debugger issues an assertion failure, quits unexpectedly, or stops the computer completely.
The debugger has control over your computer only while execution is taking place in the target program. The debugger has limited control over bugs or conflicts occurring in the Mac OS, system extensions, and interrupt handlers.
main() function, check static constructor functions. Static constructors,
called before the main() function, may be causing the crashes.
.dbg file associated with your project may be corrupted. The .dbg file holds a variety of information used by the debugger, like
breakpoint locations and conditions, window positions, and so
forth. Try throwing away and rebuilding your .dbg file. Note that this is only likely to be the problem if you
are debugging using a SYM file instead of running directly from
the project window.
main(). If these have a bug, it can crash the debugger as your app starts
up. You can insert calls to Debugger()/DebugStr() into your constructors
to drop you into a debugger. You must have MacsBug or another
low-level debugger installed for these calls to work.
It is definitely possible that you can crash your program in a way that takes out the debugger too. For example, if you pass a bad pointer to GetNewWindow(), you could end up corrupting some of the Window Manager's internal data structures. You might end up trashing some low memory global variables that are read by the Mac OS at interrupt time. Remember that your program, the debugger, and the OS all live together in the same address space with no protection of any kind in-between.
Refer to "Advanced Mac OS Debugging" for more information on debugging code resources and static constructors.
Debugger() and DebugStr() The Debugger() and DebugStr() calls are crashing my machine instead of dropping me into the
debugger.
For these calls to work, you must have a low-level debugger installed.
See also "Mac OS Debugger Traps."
When I stop in a routine, the debugger shows pointer variables with a value of "· Bus Error ·."
There are two reasons why a pointer variable may have a "· Bus Error ·" value. The variable may not have been initialized (so it has a random value, which is likely to be an invalid address).
This section briefly discusses various error messages you may encounter while using the CodeWarrior debugger on the Mac OS.
A catch-all message for an error in sending an AppleEvent to another application.
Only text files are valid for the "Open in Editor" command.
Source file not found during "Open in Editor" command.
The target application must be running in order to receive an AppleEvent.
CFM applications used shared libraries. If a necessary library was not found, the application cannot be launched.
The debugger cannot run without a nub, which must be installed in your system Extensions folder and loaded at startup time. For more information on this topic refer to "Configuring the Debugger."
The CodeWarrior debugger ran out of memory while debugging. Try increasing the memory allocation. To do this, click the CodeWarrior IDE application icon in the Finder, then press Command-I. You will be able to increase the memory allocation in the window that appears.
Either the SYM file is out of date, or you have matched up the wrong SYM file and executable file.
The version of MetroNub in your system folder doesn't match this version of the CodeWarrior IDE.
The version of MetroNub in your system folder doesn't match this version of the CodeWarrior debugger.
This section covers problems using the CodeWarrior debugger, in conjunction with other debuggers.
You can find information about the Apple MacsBug debugger on the web at:
http://developer.apple.com/tools/debuggers/MacsBug/