Jump to content

Alternating Memusage


Mighty Max

Recommended Posts

Heya, i got a lil' wish SgStair,

 

I got a structure, that excessive calls new & delete in my main program. This works fine. However as soon as I initialize the ARM9 side of the Wifi lib, These calls fail once of about 300 cycles.

 

I have put in a memory monitor and noticed that as soon I activate Wifi, the allocated bytes alternate between two values (x and x+8 ), so i assume that you are freeing and allocating 8Bytes regulary, while the DS isnt receiving/sending anything. (Wifi_EnableWifi() wasn't called)

 

As this isnt much, could you change that behaviour to have these 8 Bytes allocated the whole time, so that there is less chance that the irq'd malloc/new interfere with allocs in the main()?

 

You can test that behaviour yourself. http://mightymax.org/unnamed_strat.html is loosing its units occasionally when this error occures (It cant add the unit back to the sorted tree). Commenting out the call to InitNetwork (see below) fixes this issue.

 

void InitNetwork(void) {
REG_IPC_FIFO_CR = IPC_FIFO_ENABLE | IPC_FIFO_SEND_CLEAR;
u32 Wifi_pass = Wifi_Init(WIFIINIT_OPTION_USELED);
REG_IPC_FIFO_TX=0x12345678;
REG_IPC_FIFO_TX=Wifi_pass;

TIMER0_CR = 0;
irqSet(IRQ_TIMER0, Timer_50ms);
irqEnable(IRQ_TIMER0);
irqSet(IRQ_FIFO_NOT_EMPTY, arm9_fifo);
irqEnable(IRQ_FIFO_NOT_EMPTY);
REG_IPC_FIFO_CR = IPC_FIFO_ENABLE | IPC_FIFO_RECV_IRQ;
Wifi_SetSyncHandler(arm9_synctoarm7);

TIMER0_DATA = -6553; // 6553.1 * 256 cycles = ~50ms;
TIMER0_CR = 0x00C2; // enable, irq, 1/256 clock	
};

Link to comment
Share on other sites

erm... I'm not aware of any behaviour that could cause it to allocate /deallocate 8 bytes periodically, if you do find something of the sort though, please let me know... As far as problems with allocating, this could happen if the allocate functions aren't reentrant safe.... I should probably look at mitigating factors further.

To prevent any possibility of contamination though, wrap the allocation functions with a layer that temporarily disables interrupts while allocating.

-Stephen

Link to comment
Share on other sites

Just wanted to let you know, that i found the problem, and it was not the fault of the lib. It just increased the chance that this error fatals :rofl: due to the timing of the irq's.

 

Turned out that running recursively through the sorted trees would take up more stack then beeing available. That was no problem as long no IRQ happened, but when it did, part of this too big stack was overwritten (IRQ stack is just blow SVC stack) so the parameters passed to new/malloc were not the correct ones, therefor it failed.

 

*trying to look innocent*

 

Mighty Max

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...