Trying to open sample document for "Bug 44292 - FILEOPEN particular docx shows wrong number of columns" worked several times for me with Parallel Dev-Installation of "LibreOffice 3.5.0 Beta2- WIN7 Home Premium (64bit) German UI [Build-ID : 8589e48-760cc4d-f39cf3d-1b2857e-60db978], but Now I allways get a crash wehen I try with 'File -> Open' (LibO dialog) or 'File -> Recent Documents' No problem with 3.4.5 and 3.3.3
No crash here but 4 instead of 2 columns. LibreOffice 3.5.0rc1 Build-ID: b6c8ba5-8c0b455-0b5e650-d7f0dd3-b100c87 Linux
Created attachment 55947 [details] doc showing 4 columns instead of 2 - or crashing libo Attached doc shows 4 columns i.s.o. 2 in Libo RC1 or crashes libo in 3.3.4
are below bugs duplicates?? 42450 43573 43663 44257 44381
Crash (Win7 x64 de-de)
Created attachment 55994 [details] document with 2-koloms, in .odt format
On Win7, 64-bit, I cannot open the .docx document. Libo reports it is locked. If I either select "Open read-only" or "Open copy" Libo crashes. Previously I reported I could open the same document in Debian Wheezy 64-bit, the behaviour of Libo is therefore OS dependent.
# bad: [4c30602f43475389f81b1d981ce8ee9a3410b9d9] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3 git bisect good 2faf4bc12ab490370d2196dedbc8091f9b09d0a5 # good: [b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4] source-hash-ce60138d339a5eb2a174a5d27063249acf2cac42 git bisect good b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4 # bad: [216e447cb0a457985f20d4db481fa9c73b0bb775] source-hash-55c5ea43a59e505297fb6fa20b77aaa28f7c67bc git bisect bad 216e447cb0a457985f20d4db481fa9c73b0bb775 # good: [0f42e78ebe43d08d8e4cf96abfd58e9413846fbc] source-hash-f82da782158d8f5b89a6a9057df1a4695425ed75 git bisect good 0f42e78ebe43d08d8e4cf96abfd58e9413846fbc # bad: [7d5758460160db0be8a20e9f41da5639f6011ffc] source-hash-ab407ad86610a0aba882b03075319e0b62b2c8d3 git bisect bad 7d5758460160db0be8a20e9f41da5639f6011ffc # bad: [a3f2fbf9ca00d5bd8b82cc3bad62a7f1854a7f76] source-hash-919abbfe9b1461e4accbdebe4a2475379d2d5731 git bisect bad a3f2fbf9ca00d5bd8b82cc3bad62a7f1854a7f76 So it must be one of the commits in: git log 919abbfe9b1461e4accbdebe4a2475379d2d5731 ^f82da782158d8f5b89a6a9057df1a4695425ed75 limiting to writer results in: git log 919abbfe9b1461e4accbdebe4a2475379d2d5731 ^f82da782158d8f5b89a6a9057df1a4695425ed75 --pretty="%s" sw/ as Remove unnecessary tools/string includes pw Translate German comments and translate some english comments spelling error bm make gbuild makefiles run independant of pwd again ll gsl_getSystemTextEncoding -> osl_getThreadTextEncoding rename and move mathml oox support classes in oox to better places ooxml mathml import - first very basic implementation initial (very hacky) work on mathml ooxml import remove executable bit on a .cxx file it remove private copy ctor, base class SwClient is noncopyable cmc check glossary path for sanity dn Fix logic inversion jh better tranlation for "a al WW" :-) pw Fix non-DBG_UTIL build. mv more German transaltions in docdesc.cxx mst RtfAttributeOutput: remove unnecessary includes SwIndex, SwIndexReg::~SwIndexReg: deploy assert() SwIndex: remove global EmptyIndexArray SwIndex: cleanup: add Init method SwIndex: clean up Remove duplication SwIndex: style cleanup sw: remove debug instance counting sw: remove some debugging cruft sw: enable more debug code: SwShell{,Table}Crsr: remove pointless overrides of IsSelOvr SwLinePortion::Check is useless sw: replace abuses of OSL_DEBUG_LEVEL with DBG_UTIL cmc fix some stray typos remove various EraseLeadingAndTrailingChars fix for pesky pre-language-defect-fix gcc 4.0.1 CC'ing Michael Stahl for twiddling with SwIndex.
Bjoern: the attached docx does not crash for me on current master and -3-5. valgrind doesn't show anything problematic for either (and i even printed on master). can you still reproduce this crash? if yes, can you attach a stack trace?
With sample document for "Bug 44292" still [Reproducible] with "LibreOffice 3.5.1.1 German UI/Locale [Build-ID: 45a2874-aa8c38d-dff3b9c-def3dbd-62463c8] on German WIN7 Home Premium (64bit). and parallel Server installation of "LOdev 3.5.1rc0+ [Build ID: e80d2ea-73cb0b8-f269e46] Win-x86@6-fast pull time 2012-02-24 11:11:48 – WIN7 Home Premium (64bit), separate User Porfile, and Master LOdev 3.6.0alpha0+ Build ID: 475d0c5-829fc92-39746e8-206648e-fefd87
@Michael Stahl: Ok, disregard the bibisect. This fun thing is a Mandelbug. It crashes sometimes with both the oldest and the latest version in bibisect, so the root cause is older than the oldest version in bibisect35. In seems to crash less in the latest version in bibisect (which is libreoffice-3-5 branchoff). Indeed I could _not_ reproduce a crasher with a fcba36f1093935b9bbf0735661bb8e5b4f5a8671 build on master. So if anyone you reproduce it on a recent master or -3-5 build, a stacktrace would be most welcome. http://www.catb.org/jargon/html/M/mandelbug.html
Oh, also there are some funny things going on with the layout. If you let it load without touching you get 14 pages -- if you scroll down while loading you can get more (15-17).
I can not reproduce the crash neither with LibreOffice 3.5.2.2 nor with LOdev 3.6.0alpha0+, Build ID: 503c8fd (installation file: master~2012-04-20_00.38.41_LibO-Dev_3.6.0alpha0_MacOS_x86_install_en-US.dmg), both on MacOS X 10.6.8. But this is no surprise if it is a Mandelbug. Or the crash is Windows-specific (cf. comment 1, comment 6). I will try again ... In any case, I see the same strange funny things going on with the layout as Björn (comment #11).
Well, we shouldn't have four columns, we should have only two in the first place. So rather than have a lingering open bug which we can't reliably reproduce which is happening in a set of circumstances which should never have some to pass lets fix the four-columns-should-be-two and presume that the Heisenbug wouldn't come to pass in the correct two-column scenario. Especially as the reason its a four-column .docx is fairly straightforward problem, though maybe not-trivial to fix without loosing some other fix. *** This bug has been marked as a duplicate of bug 44292 ***