Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Hey, my overloaded New operator keeps returning unaligned addresses. When I try to allocate buffers allocated with New/Malloc using a pointer, it crashes because I'm assuming it wants a 4-byte address.

I want it to return a 4-byte aligned (integer) address, but it keeps giving me bad addresses which crash on the phone (but work in the emulator)

Is there some kind of compiler directive I can use to force Malloc/New to give me integer aligned addresses? I thought it was supposed to do that automatically anyway?

Are you using BREW's MALLOC() macro?

Are you using BREW's MALLOC() macro?

Yep. It's not returning an integer aligned address. I had to ditch MALLOC use a pre-allocated array instead, which I'd rather not do in this case.
Worst case is I guess I'll allocate a little more memory than I need, then use a char* to advance to the next integer-aligned address, and point my structure pointer there.
But how annoying is that? :)

Yep. It's not returning an integer aligned address. I had to ditch MALLOC use a pre-allocated array instead, which I'd rather not do in this case.
Worst case is I guess I'll allocate a little more memory than I need, then use a char* to advance to the next integer-aligned address, and point my structure pointer there.
But how annoying is that? :)

could you post your overloaded operator?
[]'s
Marcel

could you post your overloaded operator?
[]'s
Marcel

It's the exact same one from the BREW docs:
//overloaded new and delete
void *operator new ( size_t size)
{
return MALLOC (size) ;
}
void operator delete(void * ptr)
{
FREE(ptr) ;
}

It's the exact same one from the BREW docs:
//overloaded new and delete
void *operator new ( size_t size)
{
return MALLOC (size) ;
}
void operator delete(void * ptr)
{
FREE(ptr) ;
}

Yo Flarb!
What phone are you talking about here?
I don't use the overloaded stuff...I just MALLOC what I need old-school style.
Have you tried that in the case it's giving you headaches?

Yo Flarb!
What phone are you talking about here?
I don't use the overloaded stuff...I just MALLOC what I need old-school style.
Have you tried that in the case it's giving you headaches?

Yeah I could try that, but since new just calls malloc, what's the difference, really? I figure it would return the same address. I guess Malloc always returns a byte-aligned address or something, because it assumes it's allocating an array of bytes? I dunno. Annoying.
Anyway, I'm running this on a T720 and a 9500. Both of 'em are giving me guff, although the 9500 seems to be less tolerant of this and other errors.
The 9500 is a great phone to debug on because of that--in the past I've found some weird errors that I couldn't detect on other handsets because the 9500 choked on them.

Yeah I could try that, but since new just calls malloc, what's the difference, really? I figure it would return the same address. I guess Malloc always returns a byte-aligned address or something, because it assumes it's allocating an array of bytes? I dunno. Annoying.
Anyway, I'm running this on a T720 and a 9500. Both of 'em are giving me guff, although the 9500 seems to be less tolerant of this and other errors.
The 9500 is a great phone to debug on because of that--in the past I've found some weird errors that I couldn't detect on other handsets because the 9500 choked on them.

Hi Senor Flarb,
If you get an answer to this, I'd love to know it.
I've developed apps in C, compiled them to phones and they work fine.
I haven't been able to get my C++ code compiled and working on any phone though. When I load my .mod to my phone, execute it and verify that AEEClsCreateInstance gets called and AEEApplet_New is okay, but after that.. who knows. The hourglass shows forever (doesnt reset).
I got most of my c++ starting bits from http://www.developer.com/ws/brew/article.php/1548131 (the extern bits, etc).
Things I've tried include: overloading new/delete, getting rid of all my code except the AEEClsCreateInstance and the static systemevent handler, removing all of the class member items, fiddling with the armcpp makefile. I am certain that the AEEApplet_New is okay but calls to my static initapp method from in AEEClsCreateInstance never get entered. I've tried closing the app when my event handler gets a APP_START, but that never occurs - implying the event handler wasnt registered correctly and never gets called.
I am thinking that my makefile is screwy - misaligning some bits here or there. Attached is the file I've been using... any tips?
Otherwise I'm going to port my code to c. UGH UGH UGH!

Hi Senor Flarb,
If you get an answer to this, I'd love to know it.
I've developed apps in C, compiled them to phones and they work fine.
I haven't been able to get my C++ code compiled and working on any phone though. When I load my .mod to my phone, execute it and verify that AEEClsCreateInstance gets called and AEEApplet_New is okay, but after that.. who knows. The hourglass shows forever (doesnt reset).
I got most of my c++ starting bits from http://www.developer.com/ws/brew/article.php/1548131 (the extern bits, etc).
Things I've tried include: overloading new/delete, getting rid of all my code except the AEEClsCreateInstance and the static systemevent handler, removing all of the class member items, fiddling with the armcpp makefile. I am certain that the AEEApplet_New is okay but calls to my static initapp method from in AEEClsCreateInstance never get entered. I've tried closing the app when my event handler gets a APP_START, but that never occurs - implying the event handler wasnt registered correctly and never gets called.
I am thinking that my makefile is screwy - misaligning some bits here or there. Attached is the file I've been using... any tips?
Otherwise I'm going to port my code to c. UGH UGH UGH!

MALLOC() should always return aligned addresses (exept maybe when you're running in the simulator with a skin that uses the Windows heap). Have you checked to see that the address is misaligned when you run the app on the phone? Or have you only seen misaligned addresses on the simulator?
I am thinking that the addresses are aligned properly on the phone, and your app is crashing for another reason.

MALLOC() should always return aligned addresses (exept maybe when you're running in the simulator with a skin that uses the Windows heap). Have you checked to see that the address is misaligned when you run the app on the phone? Or have you only seen misaligned addresses on the simulator?
I am thinking that the addresses are aligned properly on the phone, and your app is crashing for another reason.

No, it's a phone crash. It works fine on the emulator 'coz the alignment rules don't apply on Intel.

No, it's a phone crash. It works fine on the emulator 'coz the alignment rules don't apply on Intel.

Flarb: so did you figure it out by chance or are you still having problems? I was thinking that my mak file was missing a flag or something.. I know that codewarrior configures armcpp correctly, but dont know how to get the compiler to work directly with make.
Maybe if I checked the return value of MALLOC if it's % 4 == 0? And if it's not then keep looping until it returns an "Aligned" address? That sounds incredibly cludgey and totally wrong though. UGH.
Anyone have a cpp makefile that *works* on the phone?
Thanks

Flarb: so did you figure it out by chance or are you still having problems? I was thinking that my mak file was missing a flag or something.. I know that codewarrior configures armcpp correctly, but dont know how to get the compiler to work directly with make.
Maybe if I checked the return value of MALLOC if it's % 4 == 0? And if it's not then keep looping until it returns an "Aligned" address? That sounds incredibly cludgey and totally wrong though. UGH.
Anyone have a cpp makefile that *works* on the phone?
Thanks

Not yet, I'm going to mess around with it some more today. My super hack solution may be to just malloc slightly more memory than I need and then advance the pointer to the next integer aligned address.

Not yet, I'm going to mess around with it some more today. My super hack solution may be to just malloc slightly more memory than I need and then advance the pointer to the next integer aligned address.

Quote:Originally posted by flarb
No, it's a phone crash. It works fine on the emulator 'coz the alignment rules don't apply on Intel.
You didn't really answer my question. Have you verified that the return value of MALLOC is not aligned when you run the app on the phone?
There are lots of other reasons that an app might crash on a phone but not on the simulator, and just because MALLOC is returning a misaligned address on the simulator does not mean that it is returning a misaligned address on the phone.
If MALLOC is truly returning misaligned addresses on the phone, then that would affect everything, not just C++ apps.

Quote:Originally posted by flarb
No, it's a phone crash. It works fine on the emulator 'coz the alignment rules don't apply on Intel.
You didn't really answer my question. Have you verified that the return value of MALLOC is not aligned when you run the app on the phone?
There are lots of other reasons that an app might crash on a phone but not on the simulator, and just because MALLOC is returning a misaligned address on the simulator does not mean that it is returning a misaligned address on the phone.
If MALLOC is truly returning misaligned addresses on the phone, then that would affect everything, not just C++ apps.

Uh yes I did:
"No, it's a phone crash. "
As I said.
And it's 'coz the address is non aligned. (I printed out the address in the logger)
I think there may be some goofiness in how I overloaded new and delete in this instance, so I'm going to play around with it a bit.

Uh yes I did:
"No, it's a phone crash. "
As I said.
And it's 'coz the address is non aligned. (I printed out the address in the logger)
I think there may be some goofiness in how I overloaded new and delete in this instance, so I'm going to play around with it a bit.