One explanation i can see is if some code is calling setbits from ISR
context. This is illegal. Most of the time it would work, but there is
a race condition. If the interrupt happens after the !(queue.empty())
and before the queue.dequeue() this behavour might happen. It would
also require that dereferencing a null pointer does not throw an
exception, and that (p->allmask == 0) != (p->anymask == 0) happens to
be true for the random junk returned by get_wait_info. You could
check for this by putting in a new assert after the queue.dequeue()
and make sure thread != NULL.
Thanks for the suggestion. Is there any way of telling if the current
context is an ISR rather than thread or DSR?
Apart from that the only other idea would be to put a break point in
cyg_assert_fail() and find out the call path and which flags is
causing the problem.
Andrew
--
------------------------------------------------------------------------
Will Wagner [EMAIL PROTECTED]
Senior Project Engineer Office Tel: 0207 371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
