[En-Nut-Discussion] Race condition and stack overflow in tcpsm.c
Philipp Burch
phip at hb9etc.ch
Fri Nov 14 10:31:45 CET 2014
Hi everyone,
while debugging some mysterious system crashes during FTP transfers, I
found a race condition problem in tcpsm.c. In my application, I start a
few threads right after system initialization, which all open TCP
sockets. This caused the NutTcpInitStateMachine() function to spawn
multiple (two in my case) 'tcpsm' threads. With a mutex guarding this
function, I did no longer see this issue and also the crashes seem not
to happen anymore (as long as there is enough stack space, see below).
The patch is attached and included in SVN r5883 in the devnut_tiva branch.
Another problem is with the stack space of the TCP state machine. If no
other value is set in the configurator, this defaults to 384 bytes for
all ARM variants. When I transfer a rather large file (some Megabytes)
to the board's SD card using FTP, the top usage on this Cortex-M4 seems
to be 388 bytes. This resulted sometimes in a crash and sometimes just
in a stop of the transmission with no error message or anything. After
overriding the option in the configurator to be 512 bytes, it is working
fine so far. Maybe we should include this as default value for ARM or
even for all Cortex devices?
Oh yes, those 388 bytes are on a TM4C1294NCPDT device (internal Ethernet
MAC and PHY) with the arm-none-eabi-gcc version 4.8.2-14ubuntu1+6
compiler (cm3-gcc build target in the configurator, optimized code).
The resulting compiler flags are:
arm-none-eabi-gcc -c -I/home/.../nutbld-fpm_01b/include
-I/home/.../devnut_tiva/nut/include
-I/home/.../devnut_tiva/nut/include/contrib -DFPM_01B -MD -MP
-mcpu=cortex-m4 -mthumb -D__CORTEX__ -mfloat-abi=hard -mfpu=fpv4-sp-d16
-ffunction-sections -fdata-sections -fomit-frame-pointer -Os -Wall
-Wstrict-prototypes -Werror -Wa,-a=tcpsm.lst -o tcpsm.o
/home/phip/phipsfiles/developing/ethernut/devnut_tiva/nut/net/tcpsm.c
I experienced those problems only with the TCP implementation, but maybe
there are other protocols which suffer from the same (especially from
the race condition).
Please comment if those are reasonable solutions for the problems
experienced.
Thanks and best regards,
Philipp
More information about the En-Nut-Discussion
mailing list