Typo bug in eARPProcessPacket() causes exception

murraylang62 wrote on Wednesday, October 31, 2018:


There is a bug in eARPProcessPacket() in FreeRTOS_ARP.c. In FreeRTOS v10.1.1 it is on line 117:

memcpy( ( void *)&( ulSenderProtocolAddress ), ( void * )pxARPHeader->ucSenderProtocolAddress, sizeof( ulSenderProtocolAddress ) );

…which should be…

memcpy( ( void *)&( ulSenderProtocolAddress ), ( void * )&pxARPHeader->ucSenderProtocolAddress, sizeof( ulSenderProtocolAddress ) );

For a while I thought the resulting exception was due to alignment.
This has been around for the previous two FreeRTOS versions at least, but I’ve only now got around to pointing it out.


heinbali01 wrote on Wednesday, October 31, 2018:

Hi Murray, thanks for reporting, but you haven’t convinced me yet.

The field ucSenderProtocolAddress[ 4 ] is an array of bytes. In earlier versions of +TCP, this field was called uint32_t ulSenderProtocolAddress. The problem was that this field is only 2-byte aligned. On most platforms, access to an uint32_t must be 32-bit aligned.

Note that there are 4 occurrences of ucSenderProtocolAddressin FreeRTOS_ARP.c, and none of them has an ampersand to take the address of the array.

murraylang62 wrote on Thursday, November 01, 2018:

Oops - I beg your pardon.

I discovered that bug in the FreeRTOS Labs some time ago in my journey to get my STM32F4 Discovery board working with all the FreeRTOS Plus goodies. It took me a while to realise that the program was sitting in a tight loop in a fault handler. I’m actually grateful to it for forcing me to learn to make fuller use of GDB.

Since then I’ve been adding those ampersands to the FreeRTOS releases, not noticing the change from pxARPHeader->ulSenderProtocolAddress to pxARPHeader->ucSenderProtocolAddress .

Another lesson for me in the difference between fact and belief!