I think I found it. My problems occur because of structures which were from
another OS which didn't care about even byte alignment.
The debugger was giving me output to the logfile at the point indicated, I
just didn't notice it.
The location wasn't random. (I don't know where you got that idea). It was
happening during the construction of subclasses. I was able to find it by
clicking on the stack and looking at the addresses of the variables. At one
point they went from odd to even, and at that point I had an array of 5
characters, followed by an integer. Personally I think this is a really
stupid limitation for a cpu, since it can obviously read odd addresses for
characters, why can't it read it for integers.
char *st=MemPtrNew(20);
StrCopy(st,"Test");
you'll get a big problem on some (most?) systems because you didn't
manually zero-out the memory first. Where in memory will it write "Test"?
It will write it to the first NULL character position AFTER st, wherever
that is. It is quite likely more than 20 characters beyond the location
of st, so it will probably be overwriting something else, and
I think you are confusing StrCopy with strcat. StrCopy doesn't need to zero
out the destination byte. (department of redunancy department there).
Thanks for your feed back though. It made me look more closely at the
structures.
Chris Bruner
Compulife Software Inc.
==============================================
----- Original Message -----
From: "Robert Moynihan" <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[email protected]>
Sent: Tuesday, October 11, 2005 4:59 PM
Subject: Re: odd address error
cbruner wrote:
The weird thing is that under the debugger it is able to run, although it
stops at one point. When I try to just run it, it dies with the odd
address error. Any ideas on how to understand where I went wrong?
The thing is that the debugger, simulators, and h/w devices will all react
differently to memory corruption. For example, some of these will
populate new chunks with NULLs, others will just leave whatever memory is
there. And when you tromp on a pointer, your code will say "use whatever
value is over there", and "over there" will be, basically, a random
location. Reading or writing to a random location may cause a crash,.. or
not... depending on where "over there" actually is.
<snip>
err = VFSFileOpen (volRefNum,Path, ro,&Handle);
<<<< Debugger stops on return of this call, as though an error occured
in VFSFileOpen, with gray arrow. I'm guessing this is where the error is.
So, if you comment out that line of code you can run fine without errors?
Crashing upon a simple return from a function almost always, in my
experience, means that you have made some bad memory calls within that
function. Focus on that function and disable parts of it until you find
the culprit. Look for anywhere that you read or write to memory, and
check that you validate the handles/pointers, and don't overrun any memory
allocations. For instance, if you do something like:
char *st=MemPtrNew(20);
StrCopy(st,"Test");
you'll get a big problem on some (most?) systems because you didn't
manually zero-out the memory first. Where in memory will it write "Test"?
It will write it to the first NULL character position AFTER st, wherever
that is. It is quite likely more than 20 characters beyond the location
of st, so it will probably be overwriting something else, and that
something might be important. To avoid this problem you do this BEFORE
writing to the memory pointer:
st[0]=0;
This is going to take a little sleuthing on your part to fix. Take it a
bit at a time, and track it down methodically.
Bob
--
For information on using the PalmSource Developer Forums, or to
unsubscribe, please see http://www.palmos.com/dev/support/forums/
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
