[ECOS] Map and queue disagree

sandeep shimple0@yahoo.com
Tue Nov 30 10:17:00 GMT 2004

>>try replacing
>>CYG_ASSERT( ((queue_map & (1<<pri))!=0) == ((!run_queue[pri].empty())!=0), 
>>"Map and queue disagree");
>>in rem_thread (mlqueue.cxx), by (please check out the bracketing)
>>if (! ( ((queue_map & (1<<pri))!=0) == ((!run_queue[pri].empty())!=0) ) ) {
>>  CYG_ASSERT(0,"Map and queue disagree");
>>put a breakpoint INSIDE if, at CYG_ASSERT, whenever execution reaches that 
>>figure out the value/state of queue_map, pri and run_queue[pri] .
> You don't actually need to do this. Just put a breakpoint as
> cyg_assert_fail(). You can then go back up the call stack to where the
> assert macro was used and check out both the queue_map and the run
> queue.

i didn't suggest cyg_assert_fail because it would be reached in any other assert 
failure also, but here we are interested in a particular case of assert failure.
on second thoughts, it could be useful to have breakpoint in cyg_assert_fail for 
catching other cases as well.

my suggestion was influenced by the fact that the GUI debugger that i have often 
used (for a particular board and toolchain combination), doesn't have stack 
trace support, so all of it has to be done manually and carefully via analysing 
the memory dump of relevant stacks, tracing with assembly (obj)dump of code.

breakpoint in cyg_assert_fail is just fine with a good debugger.

i wonder, if you have a good debugger and test execution stops via 
CYGHWR_TEST_PROGRAM_EXIT in case of assert failures, why would you need even to 
put a breakpoint?

since for the assert failures coming via scheduler data structure manipulation 
functions, scheduler is supposed to be locked, keeping scheduling and dsr 
processing at bay.

am i missing something??


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around

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

More information about the Ecos-discuss mailing list