SNMP Crash

[SeeCwriter]

Using a Nano with v2.8.1 of the tools.

I have an SNMP MIB file that I have used on other products, but when used on a new product I'm working on, the cpu crashes
when it responds to a SNMP packet. That is, the SNMP packet is received, the callback function is called and it
processes the requested data. But when the callback returns, the cpu crashes.

The system callbacks all seem to work, though I have a question about sysObjectID, which is for another post.

This acts like a stackover flow or string overrun, but I don't see it. I'm not sure where to look for the problem.
Does the crash report below provide a clue of what is wrong?

The code is this:

Code: Select all

snmp_typeString    ReadFuncampIDVersion();

SNMPREADFUNC( ampIDVersion,
              "1.3.6.1.4.1.30679.2.2.2.3.1.0",
              ASN_typeString,
              ReadFuncampIDVersion,
              READ_COMMUNITY_MASK );

snmp_typeString ReadFuncampIDVersion()
{
  static char snmp_data[50];
  char buf1[10]; 
  
	siprintf(snmp_data, "Xicom SSPA-%c: v%s, ser#:%s, SYS:%X", 	SS->device_pos, 
																															FormatFWVersion( buf1, true),
																															SS->serial_no,
																															SS->system_id );
	iprintf( "ID: %s\r\n", snmp_data );

  return (snmp_typeString)snmp_data;
}

This is the MTTTY output and crash report:

Waiting 2sec to start 'A' to abort
Sizeof UnitState: 1148

MyApp: SSPA vA.AF ser#00000

Configured IP = 0.0.0.0
Configured Mask = 0.0.0.0
MAC Address= 00:03:f4:0a:1d:0b
Starting SNMP Task
My IP: 10.250.5.61
DHCP: Enabled
Starting UDP Read Task


*** Application started ***



ID: Xicom SSPA-A: vA.AF, ser#:00000, SYS:0

----------------------
Exception Frame/A7 =2E4145FC
Trap Vector =???? (Hex):0x90
Format =02
Status register SR =2E41
Fault Status =0D
Faulted PC =2E412E41

-------------------Register information-------------------------
A0=8000E47F A1=40084731 A2=2E412E41 A3=2E412E41
A4=2E412E41 A5=4004A690 A6=2E412E41 A7=2E4145FC
D0=00000000 D1=3FF00039 D2=2E412E41 D3=40101A41
D4=40047EA4 D5=401019D4 D6=401019D3 D7=00000000
SR=412E PC=2E412E41
-------------------RTOS information-----------------------------
SR indicates trap from within ISR or CRITICAL RTOS section
The OSTCBCur current task control block = 80000AB8
This looks like a valid TCB
The current running task is: User,#30
-------------------Task information-----------------------------
Task | State |Wait| Call Stack
Idle#3F|Ready | |400306CA,400303E8,0
Main#32|Ready | |40031032,40017106,4001FF98,4001FEDE,4001E244,
TCPD#28|Semaphore |0392|40031032,4003AC16,400303E8,0
IP#27|Fifo |0004|4003135C,4003359E,400303E8,0
Enet#26|Fifo |0028|4003135C,4002748C,400303E8,0
HTTP#2D|Semaphore |000E|40031032,4003DD06,4003C4F0,400303E8,0
User,#30|Running | |2E412E41,412E412E,0
User,#31|Ready | |4003135C,40035CD2,40014688,400303E8,0

-------------------End of Trap Diagnostics----------------------

[Forrest]

Hello,

Try enabling the stack overflow checking feature.

In predef.h, comment:

Code: Select all

/* #define UCOS_STACKOVERFLOW (1) */

and then add EnableOSStackProtector() to your usermain().

Rebuild all system files and rebuild your application. If you are getting a stack overflow, you will get a trap message and the program counter should be pointing at the culprit.

Forrest Stanley
NetBurner, Inc

[SeeCwriter]

As I suspected, it was buffer overflow. I seem to have a gift for overflowing buffers.

To try to save some face, I had done a printf() on the buffer and it looked correct. Even a strlen() returned a reasonable length. But it wasn't terminated correctly.

Thanks.