On 20/10/15 16:02, Isaac Gutekunst wrote:
Hi Devel,
I'm pretty sure this is a devel question, not users.
I'm working with a colleague at Vecna to port lwIP to the STM32F7 BSP
we've developed.
We have a basic HTTP server that prints out the current list of tasks.
We refresh the page at a very high rate, and after about 1-30 minutes,
get a crash.
Every time the exception is thrown after
_CORE_mutex_Check_dispatch_for_seize( wait ) on line 254 of
coremuteximpl.h. Every time this is inside a pthread_mutex_lock() call.
Here is the full backtrace:
stm32fxxxx_fatal_error_handler() at hal-fatal-error-handler.c:126
0x800af92
_User_extensions_Fatal_visitor() at userextiterate.c:123 0x803212c
_User_extensions_Iterate() at userextiterate.c:166 0x80321c0
_User_extensions_Fatal() at userextimpl.h:254 0x802a85e
_Terminate() at interr.c:44 0x802a888
_CORE_mutex_Seize_body() at coremuteximpl.h:255 0x8068df0
_POSIX_Mutex_Lock_support() at mutexlocksupp.c:57 0x806907e
pthread_mutex_lock() at mutexlock.c:40 0x8068bee
sys_arch_sem_wait() at sys_arch.c:485 0x808da8a
sys_arch_mbox_fetch() at sys_arch.c:357 0x808d804
sys_timeouts_mbox_fetch() at timers.c:532 0x80883ce
tcpip_thread() at tcpip.c:95 0x808c170
_Thread_Handler() at threadhandler.c:102 0x806bbe8
_User_extensions_Thread_exitted() at userextimpl.h:244 0x806bb60
bsp_section_work_begin() at 0xc016a12c
However, the lwip code calling pthread_mutex_lock varies, but is
consistently from lwIP.
Does this ring any bells?
Normally you get this if you obtain a locked mutex in interrupt context,
but your stack trace says you are not.
As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a "bad" state. I don't believe it is in an
interrupt context, and don't know what other bad states could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state at this
point?
In case the thread dispatch disable level is not zero, then something is
probably broken in the operating system code which is difficult to find.
Could be a general memory corruption problem too. Which RTEMS version do
you use?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
