This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

CPU Stack Overflow In BSD Network Stack


I have been seeing what looks like CPU stack overflows with the BSD network
stack.  The code is running on the Samsung S3C4510B ARM7TDMI processor, with
the assertions and stack checking enabled
(CYGFUN_KERNEL_THREADS_STACK_CHECKING), and IPv6 enabled (CYGPKG_NET_INET6).

A call backtrace of the assertion follows:

Call return addresses (most recent first)
0006da84 {write_thread_id}
000209d4 {cyg_assert_fail + $10}
000ac3b4 {_ZN18Cyg_HardwareThread11check_stackEv + $124}
0002d418 {_ZN13Cyg_Scheduler12unlock_innerEj + $54}
0002ecb4 {_ZN9Cyg_Mutex4lockEv + $138}
00020c4c {ks32c5000_eth_buffer_send + $88}
00021cdc {ks32c5000_eth_send + $8C}
00067634 {eth_drv_send + $12C}
00085898 {cyg_ether_output_frame + $A0}
0008566c {cyg_ether_output + $2D0}
0005e9c8 {cyg_nd6_output + $160}
00058098 {cyg_ip6_output + $A24}
00060654 {cyg_nd6_na_output + $328}
0005f2c4 {cyg_nd6_ns_input + $510}
00097aec {cyg_icmp6_input + $E38}
00052e5c {cyg_ip6_input + $8F4}
00052548 {cyg_ip6intr + $3C}
00035bcc {cyg_netint + $44}
0002abd4 {_ZN18Cyg_HardwareThread12thread_entryEP10Cyg_Thread + $7C}
0002ab40 {_GLOBAL__I_cyg_scheduler_start}

In the file, "packages/net/bsd_tcpip/current/src/ecos/support.c", it defines
the network stack (netint_stack[]) to be CYGNUM_HAL_STACK_SIZE_TYPICAL bytes
in size.  For the ARM architecture, CYGNUM_HAL_STACK_SIZE_TYPICAL is 2400
bytes.

I increased the stack and the stack overflow assertions have gone away.

  #ifdef CYGPKG_NET_INET6
  #define STACK_SIZE (2*CYGNUM_HAL_STACK_SIZE_TYPICAL)
  #else
  #define STACK_SIZE CYGNUM_HAL_STACK_SIZE_TYPICAL
  #endif
  static char netint_stack[STACK_SIZE];

Before the IPv6 (CYGPKG_NET_INET6) was enabled, there were no stack 
overflows observed.  It looks like the IPv6 enabled network stack
code requires more processor stack than the IPv4 network stack.  Has 
anyone else encountered this situation?

Should the stack size be conditionally configured based on whether
CYGPKG_NET_INET6 is configured?  Whether
CYGFUN_KERNEL_THREADS_STACK_CHECKING
is configured?  Both?

According to the comments in file
"packages/hal/arm/arch/current/include/hal_arch.h",
CYGNUM_HAL_STACK_SIZE_TYPICAL is defined with this disclaimer:

// Minimal and sensible stack sizes: the intention is that applications
// will use these to provide a stack size in the first instance prior to
// proper analysis.  Idle thread stack should be this big.

//    THESE ARE NOT INTENDED TO BE MICROMETRICALLY ACCURATE FIGURES.
//           THEY ARE HOWEVER ENOUGH TO START PROGRAMMING.
// YOU MUST MAKE YOUR STACKS LARGER IF YOU HAVE LARGE "AUTO" VARIABLES!

So, the question is, should the BSD network CPU stack be made larger
all around, regardless of the IPv6 configurations, etc.?  Something
like:

  #define STACK_SIZE (CYGNUM_HAL_STACK_SIZE_TYPICAL+BSD_STACK_REQ)

A value of BSD_STACK_REQ=1024 might be sufficient, but is it OK to
increase the stack unconditionally for all BSD network stack users,
or should it be based conditionally on what other options have been
configured?

  #ifdef CYGPKG_NET_INET6
  #define BSD_STACK_REQ 1024
  #else
  #define BSD_STACK_REQ 0
  #endif
  #define STACK_SIZE (CYGNUM_HAL_STACK_SIZE_TYPICAL+BSD_STACK_REQ)
  static char netint_stack[STACK_SIZE];


Jay Foster


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]