Random lwIP Crashes in _POSIX_Mutex_Lock_support()

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Oct 21 12:24:07 UTC 2015



On 21/10/15 14:13, Isaac Gutekunst wrote:
> Thanks for the reply.
>
> On 10/21/2015 01:50 AM, Sebastian Huber wrote:
>>
>>
>> On 20/10/15 16:02, Isaac Gutekunst wrote: 
[...]
>>
>>>
>>> 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?
>>
>
> The thread dispatch disable level is usually -1 or -2.
> (0xFFFFFFFE or 0xFFFFFFD).

A negative value is very bad, but easy to detect via manual 
instrumentation (only an hand full of spots touch this variable) or 
hardware breakpoints/watchpoints. Looks the rest of _Per_CPU_Information 
all right?

On Cortex-M interrupt disable around operating system calls leads to 
unpredictable system behaviour.

-- 
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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




More information about the devel mailing list