Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Impress Crash: when Find&Replace dialogbox show, switch view among "Notes", "Handout" and "Slide Sorter"|
|Status:||CLOSED FIXED||QA Contact:||issues@graphics <issues>|
|Priority:||P2||CC:||amy2008, issues, ooo.redflag, peter.junge|
|Target Milestone:||OOo 3.1|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:||98069|
Description doze_worm 2008-12-29 08:41:55 UTC
[Steps] 1. Create a Impress doc. 2. "Ctrl + F", type some letters in "Search for" text field in "Find & Replace" dialogbox. 3. Switch view to "Slide Sorter", the "Find & Replace" dialogbox disappear. 4. Switch view to "Notes" or "Handout", when "Find & Replace" dialogbox re-emerge, click "Find" button on it. Then click "Yes" and "OK" button respectively on the following pop-up dialogboxes. 5. repeat step 3,4 for 5 times. [Reselt] In step 4, it will crash randomly. As the probability of 20-50%. [Expectation] "Find & Replace" runs stably with view switch. [Additions] This issue is similar to #97477. But I cannot testify wether they are duplicate or not. So I have to leave the work to Dev. Best regards!
Comment 1 amy2008 2008-12-31 01:57:01 UTC
Reproducible with DEV300m37 on WinXP and Fedora Li Meiying
Comment 2 wolframgarten 2009-01-05 12:36:29 UTC
Reproducible (also in 2.4.1 but not in 2.0 final)
Comment 3 groucho266 2009-01-12 15:13:23 UTC
Search and replace is applied to the normal view, notes, and handout view. Therefore sometimes during a search the views have to be switched. Switching from one view to another nowadays an asynchronous process (in 2.0 times it was not). In order to do it in the middle of the (old) search and replace code I had to resort to a trick/hack: request the view switch then call reschedule until the request is processed. The problem with this approach is that calling reschedule in the middle of some function is never a good idea, because, like in this case, it can lead to strange problems and crashes. A proper fix would require the search and replace code to be cleaned up so that it can cope with the asynchronous view switching.
Comment 4 groucho266 2009-01-14 10:49:27 UTC
Instead of making the Outliner able to handle asynchronous view switching I tried to make the view switching, in this one case, synchronous. The results look promising.
Comment 5 groucho266 2009-01-14 12:14:51 UTC
The assertion described in issue 98069 interferes with reproducing and fixing this issue.
Comment 6 groucho266 2009-01-14 13:05:24 UTC
The first part of the fix adds a non-API way to do a synchronous update of the configuration. Handle with care! Modified files are: sd\source\ui\framework\configuration\ConfigurationController.cxx sd\source\ui\framework\configuration\ConfigurationUpdater.hxx sd\source\ui\framework\tools\FrameworkHelper.cxx sd\source\ui\inc\framework\ConfigurationController.hxx sd\source\ui\inc\framework\FrameworkHelper.hxx Revision 266300.
Comment 7 groucho266 2009-01-14 13:09:02 UTC
The second and final part of the fix uses the synchronous update of the configuration in the Outliner. This is better then using reschedule to make the update synchronous. An even better solution would be to handle the asynchronous nature of view changes. That would require restructuring the Outliner code: too much work, too great a chance to break things. Modified files are: sd\inc\Outliner.hxx sd\inc\OutlinerIterator.hxx sd\source\ui\inc\OutlinerIteratorImpl.hxx sd\source\ui\view\Outliner.cxx sd\source\ui\view\OutlinerIterator.cxx Revision 266301.
Comment 8 groucho266 2009-01-21 13:43:54 UTC
@WG: Please verify.
Comment 9 wolframgarten 2009-01-26 14:41:56 UTC
Verified in CWS.
Comment 10 wolframgarten 2009-02-16 16:31:49 UTC
Tested in master OOO310_m1. Closed.