 where we are going to look at some video that I've recorded a very long time ago. This is a regression bug reported to me by QA, so it crashes in release 6.4 but worked in previous releases. So we are trying to reproduce this bug that I've shown on the title and the first thing we are doing here is we are using the rrd bugger to record the bug and in order to reproduce it we are going to have to load this document and then perform some copy and paste operations. So first the whole document is selected and it is copied to the clipboard and then we create a new document and paste the clipboard into that and so far things are working fine. Now it is pasted and we click the handle button and things crash now as expected from the bug description. So now that we have recorded the crash we try to get the office out of the way and start debugging by using the rrreplay command this starts a gdb session and now we can start by first turning on the login to a text file in gdb which is a very useful feature and then we first set a breakpoint on the constructor of the undo object operator because the crash is an undo and we set a breakpoint command to print a short backtrace and just automatically continue when the breakpoint is hit which should give us a quick overview as to which undo objects are being created here and now we open the log file that is written by gdb in a text editor for more convenient history and now we just wait for the replay until it gets to some interesting place and the place where it will stop basically is when the crash happens because we have set the only breakpoint to automatically continue and this takes a while so i've cut the video a bit here and now can see that and this takes a while so i've cut the video a bit here and now can see that our breakpoint is being hit and these stack traces are being printed while execution continues we take a quick peek at these stack traces but first we need to find the start of them you can see that the undo object that's being created is an sw undo page desk create there's also sw undo char format create so some styles are being created apparently okay now we have stopped where the crash happens and it has crashed while doing an invalid access to an element of the nodes array so this nodes array is a central data structure in writer it contains all of the paragraphs which are sw text nodes as elements and it also contains structural nodes like start and end nodes and these encode a tree structure into the array so now we look where the crash is happening in the undo code and we set a breakpoint there and not for any particular reason we just reverse continue to the start of this statement when we set the breakpoint and as it happens the first time we reverse continue we stop at the same place where we were before because we switched directions we have to do it twice so now this is the sw undo inserts class which is responsible for um inserted or pasted content such as from the clipboard and now we take a look at the documents nodes array since this is a very large document we see that the nodes array is actually truncated after this last element here and in order to see the complete nodes array we first tell gdb that we want to print 10 000 elements and now it is able to print all of them and of course it's not very convenient to look at all of this this debug output in the terminal so that's what the log file and the text editor is for but what we can see is that the last valid node has the index two three five three and this is the end node of the body content of the document and invalid index in undo usually indicates that something has gone wrong previously for example there could be multiple undo actions and the previous undo actions did not restore the document model to the same situation that the undo action that crash is expects as we can see in the source code the crash happens right at the start of the undo impulse function where the position that is stored in the undo object is restored into a swpam that is basically a cursor it has a start and an end position in the document model now we look for the sw undo inserts in the debugger log and we can see that it has been created right at the start it is the very first undo object that is being created we can see on the stack that is basically the paste operation from the clip out calling the document models copy function so now we look at the undo action and see that there is this base class sw undo range which has stored the position started and position where the content has been inserted each position consists of a node index that is an index into the nodes array and a content index that is the index inside of a text node so now we are going to set a watch point on the end index that is stored in the undo action and this is going to stop whenever this the value of this variable changes and setting a watch point use the minus l flag and check that gdb prints hardware watch point because if it prints software watch point you will be very unhappy now we reverse continue again and we stop at sw inserts set insert range which has changed the value of the end index as we can see it is called from the copyimpleimple function that has also created the sw undo inserts object so this function takes an sw pump parameter and copies its values into the undo action so now we look at what the calling function copyimpleimple is doing it looks like we are basically at the end of this function or close to it there is a lot of code being run before we get to this point now we have reached the start of the function now we look at the source code of the sw undo inserts class in the text editor we see that the constructor also takes an sw pump but the positions passed there are ignored says the comment and here in the set insert range function the positions are copied from the sw pump that is passed and stored in the member variables and that's the first half of the function and the second half is that it looks for flies that is to say floating objects that are anchored on particular paragraphs and creates undo actions for those flies presumably because they have been inserted so when one of these flies is being inserted it may insert additional nodes into the nodes array so it could be interesting to know if we actually have created some of these corresponding undo objects and it turns out we do find one in the debugger log although if we look closely the corner of this new object is not the set insert range function that we are interested in but copy layout format now we take a closer look at the copy implement function we can see that it takes parameters such as a pump for the source range that is being copied and a position which is the insert position in the target now if we search for the set insert range function we see that it is being called very close to the end of the function at the bottom of the window you see the function ends here the undo action is created and this is sw undo copy document that is a subclass of sw undo inserts this is very close to the start of the function now we take a look at the nodes array as it is when the set insert range function is called now we go and look at the debugger output and check what is the index of the last node in the document here in the middle we have the situation where it crashed and at the bottom is the current situation and we see that the indexes indeed differ by 15 so somehow 15 nodes that used to be there are no longer there at the time when it crashes so now since the nodes are no longer there they must have been deleted somehow so we set a breakpoint in the sw node destructor and continue forward again so we stopped in the destructor where are we so apparently we are in the undo of a sw undo inplay format that is a fly that has been inserted and the undo of course deletes it again we already know that we have constructed undo actions of this kind so here is this code in the set insert range function that would create such undo actions and it first checks that the anchor position is in a certain range the range that has been inserted by the sw inserts action now we look at the undo in slay format object and this undo action also stores positions in particular it stores here the node and content index where the anchor of the fly is we want to use the debugger log to check these positions we find that the start node of the sw undo inserts is 397 whereas the anchor of this fly in the undo action is 333 so it is outside of the range of the sw undo inserts and it's therefore not in the body content because the entire body was basically inserted there and it's also then not created by this set insert range function that we looked at before so now the question is of course where does this sw undo in slay format object get created we see there are also copy functions here on the stack and here the interesting one is this copy page desk header footer input so apparently what is going on there is that a page style which is called page descriptor in writer internally is being copied and inside of that inside of the footer of that page style there is some fly anchored and yeah that's why it's being inserted here why we have this undo action so now we set a break point where this sw undo in slay format is constructed and then reverse continue okay now we stopped in set insert range that means that the undo for the fly was created before we got to that point so now we stop at our first break point but we are not interested in any undo action so disable that and stop again at the specific fly undo action so what we can see now in the back trace is that the reason why the footer and therefore the page descriptors being copied is that sw text node make copy is called and so apparently what happens is that in the body text there is a paragraph that has an attribute that sets a specific page style so the page style has to exist in the target document and that's why it's copied so now we look at the range that's being passed there it is exactly the same as in our sw undo inserts object so we're copying all of the nodes in that range which isn't ultimately that surprising so as we said there's a text node in the body that refers to a page style the page style is being copied and because there is a fly anchored in the footer of the page style this sw in slay format object is created then during undo the sw in slay format is invoked before the sw undo inserts now the question is when do the positions that are stored in the sw undo inserts object get recorded and i should mention inserting a fly inserts nodes into the notary before the body text and we can just continue and we arrive in the set insert range function that records these positions so these positions are recorded after the sw in slay format object is created and therefore after the additional flies are inserted in the document which has inserted additional nodes in the notary before the body text and the positions for the sw inserts range are recorded after these additional flies have been inserted so they are shifted by the number of fly nodes that have been inserted so in other words the problem is that the order in which the positions have been stored into the undo actions is the same when the actions were originally performed as when the undo actions are invoked and this doesn't work the order has to be the inverse when the undo is invoked as it was originally that is the reason why in the end the node index was off by 15 that is presumably the number of fly nodes that have been inserted okay it's time to ponder the source code of copy impulse more so we can see this is the place where the function call happens that ends up copying the page style and if we scroll down a bit we eventually get to the point where the insert range is called and really the situation is that at the start of the function the sw undo inserts object is created then in the middle of it the nested function is called that copies all of the nodes and also copies the page style and at the end of the copy impulse function the positions are stored inside of the sw undo inserts object so since qa claimed that this bug is a regression how did this ever work before but to answer this question we take a look at the get history of the functions that we have been looking at so far so in this oldest version in the history we find that the situation is pretty much the same so first the undo object is created and at the end of the function the insert range is called but now we notice that the source file is actually relatively new and was the result of moving a lot of code out of other files so we are not actually looking at the complete history of this code yet so now we try to find the original source file and then we look at the history of that file now we see that in the very oldest version from the year 2000 the situation is already quite similar the function was called a different name but what it does is quite similar first it creates the undo object and then at the end it calls this set insert range function so this code has been unchanged so we still don't have an answer for why this would be a regression now it would be interesting to know what introduced this bug because then fix might be more obvious one idea to fix it might be to change the order in which the undo objects are appended to the undo stack by inserting the w undo inserts objects later than the call when the styles are being copied of course it's not obvious whether this would actually work so possibly there was a more subtle change between the previous version where this didn't crash and now such as maybe there were flies not being copied there are copying now or actually we have so far concentrated on the flies but it could also be possible that the page style wasn't copied previously because the footer itself contains nodes that are inserted before the body content in the nodes array so the footer itself could create the same problem and we have seen that an undo object for the page style has also been created at some point in time have a look at the implementation of this sw undo page desk create and what it will do in undo is simply call the tail page desk function of the document what does this function do not a whole lot mainly it calls this other function there is really nothing interesting going on here we saw the undo page desk create invoke the assignment operator of the page desk so the members of the page style the relevant here are this and master and left and first master and first left those are all item sets and they contain uh they they own basically the headers and footers in the nodes array so probably what's happening there is that the sw undo page desk create um contains a copy of the um page desk object and that will keep the header and footer alive for the time being so these nodes maybe aren't actually deleted so a quick recap we have found the course of the crash in a single gdb session and we have seen that setting a watch point on a variable and then using our reverse continue command will stop at the place where the variable got its current value which is very useful now we are going to reproduce the problem with an older version so that we can check what is going on differently there and as we can see it does not crash on undo once the recording is finished we start replay again in a second terminal so we can compare side by side and again we start by setting a breakpoint on the sw undo constructor and soon we had an annoying problem which is that we forgot to disable the uh java virtual machine in the configuration and so we get a spurious sec fold on startup which doesn't really matter does not indicate a problem so we just continue now we stop at the first undo action and it is the sw undo inserts that we are already familiar with and the second one is a paragraph style being created and the third one is the page style being copied so now we know that this also happens in this older version and the next one is also a paragraph style and we have another paragraph style and another one and that's yet another one now it got a bit repetitive so i cut a bunch of these out of the video here we can see a numbering rule that is list style being created but here it gets interesting now we have an sw undo delay format but this is actually if you look close out at the stack this undo object is created during undo of another undo object particularly the sw undo inserts and this is something that can happen in writer that one undo action during undo creates another undo action but this one will not go on the undo stack it is handled eternally by the outer under action but we get to the point where the undo is being invoked and so we now know that no sw undo inslay format was created in this older version which is a difference from the version that crashes so now we are going back to the crashing version and we are going to look why there are flies being inserted here that create these undo actions and it's possible that there was some change between these two versions in how flies are being selected for insertion for copying in fact we know that there was a change between these two versions so the question is whether this could be the cause of this crash so here we see some code that checks calls a function to check whether flies are being selected and we see that in the source document there were 69 flies and the aset contains the flies that have been selected for copying in this function call and this is one of them and this is the anchor of the fly that has been selected we can see here that the type of the anchor is at paragraph fly at para so now we try to check why the fly has been selected so this is the place where it gets inserted into the set it gets inserted because here this function returned true so we reverse continue to that point and step into this function now we can see just from looking at the arguments of the function that the node index of the anchor position is larger than the node index of the start position and smaller than the node index of the end position so our experience tells us that even in the older version if this fly had been checked it would have been copied as well in this situation so now we are going to check in the source code of the older version that this is actually the case we find the place in the code where it inserts the fly that has been selected for copying here we see that the code that checks whether to copy or not actually looks quite different here so there is no function call so we go back to our gdb session for the old version and set a breakpoint and this copy fly in fly import function and see where it's being called and we see that in the new version it was called here in this copy page desk function and in the old version the caller is a different function there's nothing related to page desks on the stack here and here it's the same no page desk on the stack no page desk so it says copy page desk head of water input function actually called in the old version and we finally set a breakpoint to check that question now we just set a breakpoint in the constructor of the sw dock just so that we don't reverse continue too far otherwise we might go back to the start of the main function which would just waste our time now we do stop in this copy page desk function but we just printed the back trace of the copy fly and fly import function and it was not called by this copy page desk function and now we notice an unfortunate problem we have not built this old version with debug info so we cannot look at the source code in the debugger and this makes it a bit hard to find out why this function does not call copy fly and fly import so what we are going to do about this is we are going to record the bug another time with an even older version for which we do have debug info and as expected the 6.1 version does not crash on undo either now we replay the execution with the 6.1 version and we set a breakpoint on the function that interests us the copy page desk head of photoample and we set another breakpoint on the constructor of sw undo inserts hit the copy page desk breakpoint but it turns out that this is not interesting because we are still importing the original file so we just disable the breakpoint for now and we'll enable it later once we get to the other breakpoint and thanks to the magic video editing we are already there and we'll enable the breakpoint now and set some additional breakpoints on the constructor of the sw in slay format class where the files are being copied and also on the function that is invoked during undo for sw undo inserts which is beyond the point where interesting things would have happened so we see that this copy page desk function is being called but right now we are just interested in whether the flies are being copied at all and we do not hit that breakpoint now we have reached undo so no flies were being copied because no undo objects for these have been created so now reverse continue and then we just look what the calls look like in the new version how are these sw in slay formats being created and the page desk head of photoample function calls this copy fly in flyample function so when we reach this function in gdb we step into it and where did we return on this line so the function returns because this attribute isn't set which means that the page does not have a header or photo and if we reverse continue to the other invocation remember there were two invocations of this function we see that this one also returns here so this is for one page style first it tries to copy the header and try then it tries to copy the photo and for this page style both the header and the photo are not set so now we are getting a new idea about why this is supposedly a regression in the 6.4 version we know that the code and writer didn't actually change but it's possible that the import filter for docx files has changed in some way so that previously it did not import this photo and now it does import the photo so now we want to check this theory by just trying it out in the 6.3 version what the document looks like after it's been imported and first we want to check the page styles that contain the photos and unfortunately it turns out there is a abundance of imported page styles so this would take a while to check so if we scroll through the document as a poor man's check we don't see photos in the navigator we can see the text frames there are several of these and the ones with the gray text are somehow not visible if they were visible they would have solid black text so not sure where those frames would be so while scrolling there are no photos visible anywhere so much for the 6.3 version now we try with the current version so we can see that there are lots of frames in this document and they have black text so they actually exist and whenever we click on the ones that have names we end up seeing a photo with a page number in it so we have found the explanation why it crashes now when it didn't crash before the docking import filter was improved so it can import this photo now and then it crashes in undo and with one final look in gdb we can see that in the 6.1 version we had only 64 flies in the source document while the current version has five more and that was all for today thanks for your attention and video is still finished no yes video should be finished now looks like the last 10 seconds or so were cut off but nothing interesting there so i haven't seen any questions so far i guess if there are no questions then we can just um and here i don't know so i will check checking the chart maybe nothing please so if you have questions so please typing or chat or uh chichi now comment one comment on the chat that's a lot to uh digress uh yes i guess you can't understand everything at the first time yes yeah and so it's the original video available for download somewhere not yet but i hope that it will be uploaded to utop by organizers maybe so i i think organize jim so upload to the youtube or other site