OSTimeDly crash

[thomastaranowski]

I'm with Larry in suspecting a stack overflow. It could also be a bogus pointer or array overflow. Either one is hard to diagnose. It probably was in the original code, but you just lucked out that it didn't affect anything. I'd do a quick review of all array and pointer usage, or step carefully through the code prior to calling the function to find out when the memory corruption occured.

-Thomas Taranowski
BaringForge.com

[kevingnx]

Thanks, I agree that the behaviour seems to point to that, however; I put an infinite loop before the trap and dumped the stack before entering the loop, basically the second line of main(). the main task is still priority 10 at this point.

uc/OS Stacks
Prio StackPtr Stack Bottom Free Now Minimum Free
63 | 0x2122390 | 0x21203f4 | 8092 | 8092
10 | 0x2142398 | 0x21223fc | 130972 | 128048
40 | 0x2117b10 | 0x2115b74 | 8092 | 8092
39 | 0x20a7410 | 0x20a5474 | 8092 | 8092
38 | 0x211a494 | 0x21184f8 | 8092 | 8092

Doesn't seem to be a shortage of stack space. Maybe the heap is overflowing instead?

I'll keep investigating.

[rnixon]

I can't see how it could possibly be the time delay call. The stack looks like the first thing I would check, but it looks like you rung that out. However, I still thing this is a memory problem. Other factors could be an array out of bounds, or bad pointer value.

This reminds me of a problem when I would comment out a printf, and would get a crash. Put it back in, and things work. The problem was that adding that function moved the location of things around in memory. My guess would be that the original code had the same problem, but the way thing were mapped in memory the fault did not occur because it was unused space. I know this probably sounds weird, but this type of memory corruption in my application has happened to me more than once.

[Ridgeglider]

I'm also weighing in on the side of a null pointer or an array out of bounds, particularly when it sounds like you've got a lot of complicated arrays and indexing in your application. Larry's description of a how a clobbered stack might manifest in the idle task call to OSTimeDly rings too true... And as for how it could have worked before, I've also (rarely) had obscure issues like the previously described now-it-works then it doesn't issues with printf only to find something obvious staring right at me. What would happen in the "working" code if you declared several large arrays at various points in the memory map? You might move the problem into a more critical region of memory that would now cause a crash. Not sure it would help pinpoint where the issue is, but it might be a (poor) trial and error way to see if there is indeed a hidden flaw. A better idea might be to use debugger breakpoints to gradually creep up and zero in on the area where the crash occurs.

[bbracken]

Try turning off optimization:

Project->Properties->Tool Settings->GNU C++ Compiler->Optimization->Opimization Level: None

May need to do it for GNU C Compiler also.

bb

[kevingnx]

Thanks for the various suggestions. Here's where I am right now.

I ruled out a stack problem by adding a semi-recursive call in place of the OSTimeDLy() call and it ran fine. However moving the OSTimeDly() around the code and commenting and uncommenting various other calls in the code had random results. Also turning off optimization had no effect.

Soooo I made a new Netburner managed project with just the following.

void UserMain(void * pd) {
InitializeStack();
OSChangePrio(MAIN_PRIO);
EnableAutoUpdate();
EnableSmartTraps();

iprintf("Application started\n");
while (1) {
OSTimeDly(20);
}
}

It crashes/restarts every few seconds after printing the message. Tried a different 5234, still crashes. Moved the 5234 back to the development card, still crashes.

Tried this instead

void UserMain(void * pd) {
InitializeStack();
OSChangePrio(MAIN_PRIO);
EnableAutoUpdate();
EnableSmartTraps();

iprintf("Application started\n");
while (1) {
;
}
}

Still crashes. Changed all stacks in constants.h back to the default 2048, same thing the test program restarts every few seconds.

It appears that something has gone badly wrong with the system files during my upgrade process. I think I'll try reinstalling and see if anything changes.

[kevingnx]

Further to my last post, I've discovered that a version of the simple test app runs fine under the debug configuration, but compiled under the release configuration it restarts every few seconds.

[bbracken]

Again, I have had issues with an optimized application not functioning, but the debug version (optimization off) works fine. Optimization may not be the sole cause of your issue, but may be contributing to?

bb

[SteveD]

Hi there

Is the watchdog enabled?

Steve

[rnixon]

The s/w upgrade instructions say to never install over an old revision. Could that have happened?