Chandan U commented on a discussion on cpukit/score/src/threadqflush.c: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1067#note_143690

 >        Scheduler_Node *scheduler_node;
 >  
 >        scheduler_node = _Thread_Scheduler_get_home_node( first );
 > +      _Chain_Initialize_node( 
 > &scheduler_node->Wait.Priority.Node.Node.Chain );

So before adding the node to unblocking queue , it is first extracted from wait 
queue , 

In threadqflush.c

![Screenshot_2026-02-27-10-22-13-43_40deb401b9ffe8e1df2f1cc5ba480b12.jpg](/uploads/c4c8e4e817990db8594d754a1e16648d/Screenshot_2026-02-27-10-22-13-43_40deb401b9ffe8e1df2f1cc5ba480b12.jpg){width=768
 height=600}

This is eventually calling \_Priority_Plain_extract() which calls 
\_RBTree_Extract().

The main reason for node is "dirty" is that the node shares memory with both 
RBtree and chain as node used in the scheduler wait queue is defined as a union 
of Chain_Node and RBTree_Node.

In priority.h

![Screenshot_2026-02-27-10-32-41-13_40deb401b9ffe8e1df2f1cc5ba480b12.jpg](/uploads/23d57e37bfe7f906a008f8fdc0e01985/Screenshot_2026-02-27-10-32-41-13_40deb401b9ffe8e1df2f1cc5ba480b12.jpg){width=900
 height=560}

So while extraction the node is removed from the RBTree structure but since the 
same memory is used by the chain which is not cleared this causes the assertion.

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1067#note_143690
You're receiving this email because of your account on gitlab.rtems.org.


_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to