Created attachment 105974 [details] Picture of the Error Message Builds from the Win-x86@39 tinderbox are unstable. They will give the following error: Assertion failed! Program:swlo.dll Filedflyobj.cxx line 472 Expression: !rViewInformation.getViewpot().isEmpty() Steps to reproduce: 1. Download and install a build from dev-builds.libreoffice.org/daily/master/Win-x86@39/current/master~2014-09-09_05.00.16_LibreOfficeDev_4.4.0.0.alpha0_Win_x86.msi 2. Open a document like attachment 81686 [details] (seems like most anything will do) 3. File->Page Preview 4. Close Note: others tinderboxes like 42 are stable and don't have this issue.
Added Jan who was listed as the contact for #39
Comment on attachment 105974 [details] Picture of the Error Message adjusted mime type
On Windows 7 sp1, 64-bit en-US with Version: 4.4.0.0.alpha0+ Build ID: 3c24537465a90e59a714c88e3f672f0786ecd573 TinderBox: Win-x86@39, Branch:master, Time: 2014-09-06_06:02:17 OOXML document attachment 81686 [details] opens without issue, will check against the 20140909 TB39 build in a moment.
Created attachment 105993 [details] No issue with TB39 builds @Luke, *, Seeing no issue with today's TB39 build Version: 4.4.0.0.alpha0+ Build ID: 9195fd3819197c14f6fc018483075c4be5bf85fd TinderBox: Win-x86@39, Branch:master, Time: 2014-09-09_05:00:16 Perhaps download again and reinstall?
I have a 32-bit Win 7 laptop and 64-bit Win 7 desktop. Both of them give errors with 39 but work perfectly with 42. I've tried clearing the profile, but doesn't make a difference. What else should I do?
@Luke, *, Well guess you could check the hash values -- for today's TB39 build of master~2014-09-09_05.00.16_LibreOfficeDev_4.4.0.0.alpha0_Win_x86.msi MD5 3259A489AAC7C2C82E7F41D3BE2D6435 SHA-256 72C5FA937C30650A2E6805975DCA6FCC759EEF6A1E11A2FBC55750C0CC626C64 And, have a go tomorrow, when the next TB39 build rolls. If you have a good download of today's (if verified against the hash), and then again have problems with tomorrow's then little doubt there is an issue with the builds at that point.
3259a489aac7c2c82e7f41d3be2d6435 *master~2014-09-09_05.00.16_LibreOfficeDev_4.4.0.0.alpha0_Win_x86.msi Tested on a different 64-bit Win 7 laptop at work. Same result, crashing when closing the Page Preview. Also tried the 9/10 build which also gave the same Assertion failed error.
@Luke, How were you launching and then closing out of the Page Preview? I am working again with the attachement 81686 OOXML .docx file: 1) Launch always works for me correctly with File -> Page Preview; or Main Toolbar Page Preview button, or if using <Ctrl><Shift>+O 2) But if closing the Preview with <Esc>, or the Close Preview button it is throwing the same error you show. I had no problem with the Page Preview for other complex LO ODF .odt, .ods, .odp documents. Any other documents you are getting the error with? Setting NEW, and will see about getting a stack trace of the error... C++ Assertion failed! error from swlo.dll and dflyobj.cxx Expression:!rViewInformation.getViewport().isEmpty()
@V Stuart I was launching with File->"Page Preview", never the shortcut keys. This step never caused an issue. The problem showed up when I closed the preview by pressing the "Close Preview" button. I noticed that attachment 80960 [details] was also crashing writer with from the @39 tinderbox. Were you having trouble following my steps or what did you change so that you can now reproduce this issue?
@Luke, I'd been closing the .docx document File -> Close rather than the Page Preview's "Close Preview" button, or <ESC> key. Got the crash with the sample .docx when I used the button, seeing it on the 20140908 and 20140909 build of TB39. @Michael, Miklos, Andrez, Thoughts? You've all been working on dflyobj recently... http://opengrok.libreoffice.org/xref/core/sw/source/core/draw/dflyobj.cxx
Created attachment 106090 [details] stack trace of TB39 build as in fdo 83664
And, for what it is worth, depending on where in the document the cursor focus lays as Page Preview is started--on closing the Page Preview, repeatedly clicking the Ignore button on the Error dialog will eventually pass program control back to Writer. Not much of a work around, but these assert errors do not result in a hard crash.
The reason why the error cannot be seen with TB @42 is that it does not have the debugging turned on. So the assertion is real; the question is whether it is that the condition we are asserting is incorrect (should not be asserting that), or whether there is a bug.
Created attachment 106148 [details] backtrace on linux I have made the same assertion in master commit f74a638, fetched 2014-08-23, configured: --enable-option-checking=fatal --enable-dbgutil --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src --enable-online-update built on debian-wheezy 64-bit and running in a chroot sid environment. My STR, which differ from Luke's in that I have to go into Page Preview twice: (1) Download database_label_bug.zip attached to bug 83727 and extract Namensschilder.odt. (2) Open the file from the command line. (3) On the toolbar, click the icon <page preview>. (4) In the preview window, click <Close Preview>. (5) In the document window, on the toolbar, click the icon <page preview>. (6) In the preview window, click <Close Preview>. Program raise the assertion. I see the assertion in the daily dbgutil bibisect repository verseion oldest (2014-05-21) but not in bibisect-43all repository version latest. I am not sure how this can be, but I am setting Whiteboard NotBibisectable.
setting platform = (all,all), whiteboard NotBibisectable, and replacing summary.
@Terry, no NEEDINFO to respond to, so back to NEW. OK?
@Stuart, Yes, NEW is absolutely okay. I hesitated, thinking that I might well have missed an outstanding question in one of the earlier comments.
fixed on master, with commit 1df0656c4bb139606081625fb19e39fbef9f8890
I observe that there is no assertion raised by either daily dbgutil bibisect version 2014-10-25 or Version: 4.4.0.0.alpha1+ Build ID: 04ea7b24ec1b5a027efa0b850f2bc3ac7116c52e TinderBox: Win-x86@39, Branch:master, Time: 2014-10-25_08:36:56 Thank you, Michael.
Yes, likewise for me with today's TB39 build. Thanks Michael S. @Luke, would you verify things.
Migrating Whiteboard tags to Keywords: (NotBibisectable) [NinjaEdit]