Comment 15 for bug 1767826

On 05/04/2018 11:30 AM, Maciej Suminski wrote:
> I am trying to understand how to bring the track DLIST to this
> particular corrupted state (list head == nullptr, count > 0). I suppose
> this would be a hint informative enough to let us search for particular
> patterns in the code.

This is a bit scary. It would seem to agree with the stack trace and
assertion outputs that where provided in this bug report. It does
appear that this condition occurs somewhere in the undo/redo list code.
Whether or not it is the undo/redo code itself or somewhere the
undo/redo buffers are being set to state that causes the issue. I do
know that I've only had this happen with the p&s router. Given that
I've routed far more boards with the legacy router and have never seen
this issue, this may be a useful data point.

>
>
> One simple way would be to prepend a nullptr (e.g. board->m_Track.PushFront( nullptr )), but this instantly crashes when DHEAD::insert() tries to set next and previous elements, so no bonus.
>
>
> Another way would be to add tracks to another DLIST instance and clear it:
>
> board->m_Track.PushFront( nullptr );
> DLIST<TRACK> tracks;
>
> for( TRACK* t = board->m_Track; t; t = t->Next() )
> tracks.PushBack( t );
>
> while( tracks.PopFront() );
>
> The snippet above results in similar symptoms as DLIST::PopFront()
> resets next/previous pointers for each element, effectively
> disconnecting them on both list, but the counter value is only
> maintained for the local 'tracks' variable (IMHO this is bad enough to
> replace DLIST with an STL container). The only difference is that the
> original list head still points to a track, which is saved in the file,
> so it is not exactly the problem we are trying to reproduce.

At some point, we should move everything over to stl or boost pointer
containers but I am reluctant this late in the v5 development cycle. I
don't know what new issues this will potentially introduce although I
will not completely rule it out.

>
> Any other ideas?
>

I can't think of any and without a more detailed stack trace or some
known way of duplicating the bug, it's going to difficult to fix this.
I do not want to release rc2 given the severity of this bug. I will try
my best tomorrow to see if I can trigger this bug and get a better back
trace.