So here's my initial analysis of what happens in the frame tree that leads up to the crash. I've colorized the interesting float continuation chain, and numbered the interesting frames dumps in a grey background color and numbered them. Referring to each of the numbered trees in this log: 1. initially we have a float in the first column 2. we reflow and find that it overflows (but its parent is complete), so we put a NIF for it on the OverflowContainersList 3. when reflowing the next column, we find that it still doesn't fit so we create another NIF and put it on the PushedFloatsList and create a continuation for the parent on ExcessOverflowContainersList **CRASH** Now backtracking a bit in rr to see what happens between 3 and the crash... 4. This is the frame tree we start with when reflowing our float (red). Note that the inner ColumnSet has a NIF at this point. 5. Backtracking to where we create that ColumnSet NIF. I think this is the point where things start to go wrong. We've decided that the float's parent doesn't fit in in this column at all and we push the lines containing it (creating the Overflow-lines list) and create the NIF. 6. At this point the NIF has picked up the Overflow-lines so the float first-in-flow is in the ColumnSet NIF and its continuations in the previous ColumnSet. Likewise for the float's parent block which is also in the wrong order. This seems _questionable_ to me. Technically, we would either be COMPLETE, in which case we'd delete the NIFs, or INCOMPLETE, in case we'd push them, but still... From 6, this is essentially what happens, we decide it's COMPLETE and delete the NIFs. The reason we crash is that one of the float NIFs are registered in the float manager, and we try to use it after it's been deleted (frame-poisoning makes it non-exploitable though). (my apologies for the verbosity of this log)
Bug 1209952 Comment 18 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
So here's my initial analysis of what happens in the frame tree that leads up to the crash. I've colorized the interesting float continuation chain, and numbered the interesting frames dumps in a grey background color and numbered them. Referring to each of the numbered trees in this log: 1. initially we have a float in the first column 2. we reflow and find that it overflows (but its parent is complete), so we put a NIF for it on the OverflowContainersList 3. when reflowing the next column, we find that it still doesn't fit so we create another NIF and put it on the PushedFloatsList and create a continuation for the parent on ExcessOverflowContainersList **CRASH** Now backtracking a bit in rr to see what happens between 3 and the crash... 4. This is the frame tree we start with when reflowing our float (red). Note that the inner ColumnSet has a NIF at this point. 5. Backtracking to where we create that ColumnSet NIF. I think this is the point where things start to go wrong. We've decided that the float's parent doesn't fit in in this column at all and we push the lines containing it (creating the Overflow-lines list) and create the NIF. 6. At this point the NIF has picked up the Overflow-lines so the float first-in-flow is in the ColumnSet NIF and its continuations in the previous ColumnSet. Likewise for the float's parent block which is also in the wrong order. This seems _questionable_ to me. Technically, we would either be COMPLETE, in which case we'd delete the NIFs, or INCOMPLETE, in which case we'd push them, but still... From 6, this is essentially what happens, we decide it's COMPLETE and delete the NIFs. The reason we crash is that one of the float NIFs are registered in the float manager, and we try to use it after it's been deleted (frame-poisoning makes it non-exploitable though). (my apologies for the verbosity of this log)