1. File in sxw format containing table with some merged cells and SUM cells, also saved as odt format (see attachments).
2. The 2 cells that are important for me to merge are highlighted in red, but in fact the crash happens with any other cells in this file (both the original and the "saved as" version).
3. This is a bug serious enough for me, as the merger IS IMPOSSIBLE, so in effect I have to make the table over again: not something to look forward to, especially that I've got a few of those old format files to work on.
4. Perhaps this bug will help resolve the other (reported) crash-bug, which is trying to merge cells in table pasted from spreadsheet as rtf.
OS: Open SUSE 12.1
Created attachment 60855 [details]
File containing table whose cells cannot be merged under LO 3.5.2
Created attachment 60856 [details]
The same file saved in odt format under LO 3.5.2
Created attachment 60861 [details]
bt with symbols
I reproduced the problem with the swx on master updated today. (pc Debian x86-64).
I attached a bt with symbols.
[Reproducible] with "LibreOffice 126.96.36.199 (RC2) German UI/Locale [Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80] on German WIN7 Home Premium (64bit), additional
[Reproducible] with Server installation of MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: a286353-090bcba-3bf3b94]" Win-x86@6 – 2011-12-02_22:36:35)
Still works fine
with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [(Build ID: d38713d-5d03837-ca7e6f5-c4bb9bd-ce71330)]"
I did some tests with own documents created with OOo 1.1.4. Very most simple table will not crash, but Crash is reproducible with own documents with some merged cells.
I additionally checked with a LibO 3.5 on 32Bit WIN XP (VirtualBox), also crashes. So not limited to 64Bit
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
The awesome power of bibisect suggests...
git log ab63c12395ed3771b1df6822eaa8572c06db0765..f82da782158d8f5b89a6a9057df1a4695425ed75
as the range that causes the problem.
Either 858b5b4f36a357fe7192e7c2ed9cc3cdfc81fd8f, 23d66e25c0ede411d00404dcc7a36e880c22e67f or a0a1c3f4fb730ed3614593c3d8ddb50c23204c29 are my current leading contenders
Created attachment 61009 [details]
The file's archive (crash_cell.odt; no_crash_cell.odt)
An interesting feature.
A. The file "crashfile.sxw" saved as "crash_cell.odt" (LibreOffice-3.5.3_win; ODT_ver.1.0)
1) open the file "crash_cell.odt";
2) merge red cells;
3) save the edited file as "no_crash_cell.odt".
C. LibreWriter-3.5.3 opened file "no_crash_cell.odt". Any table's cells may be merge. LibreOffice is working properly.
Maybe the reason is in the meta-file:
"<?xml version="1.0" encoding="UTF-8"?>
<office:document-meta xmlns:office="http://openoffice.org/2000/office" ... xmlns:grddl="http://www.w3.org/2003/g/data-view#" office:version="1.2"><office:meta><meta:generator>LibreOffice/3.5$Linux_X86_64 LibreOffice_project/281b639-6baa1d3-ef66a77-d866f25-f36d45f</meta:generator> ... </office:document-meta>"
crash is caused by 858b5b4f36a357fe7192e7c2ed9cc3cdfc81fd8f
the conversion to a std::map assume that the StartNodes won't change while the map exists, but a paragraph is added to the document after the boxes are created, so the indexes used by the map are no longer the indexes reported by each elements GetSttIdx
re comment #6: various comments about re-saving, etc. There are two table models floating around, those in old docs (like the .sxw) and those in new docs. The problem shows itself with the old-table-model, persumably saving it in 2010 turned it into a new-model table.
Created attachment 61039 [details]
park fix here for the moment
Under Open Office 3.1.0 there is no problem whatsoever merging cells in both crashfiles (the sxw and the "saved as" odt one). Then again OO 3.1.0 falls short of LO as far as some important bugs and features go.
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":
Resolves: fdo#49342 crash merging cells, revert conversion to std::map
fixed in master, backport post for review for 3-5 to list
(In reply to comment #11)
> fixed in master,
> backport post for review for 3-5 to list
LOdev 3.5.4rc0+ (Win-x86@7-MinGW)
Build ID: 009776a-a73d29c-6845e52-f269e46
Data stamp: 2012-05-07_12.31.58
of course! The fix for is in review, not in the branch (as you can see in target information).
(In reply to comment #14)
> of course! The fix for is in review, not in the branch (as you can see in
> target information).
Well, then why it has the resolution of "fixed" in "[Bug 37361] LibreOffice 3.5 most annoying bugs"?
It's common sense for this kind of bugs to set status to FIXED when the Master-Fix has been committed, although it's a little confusing. Currently we have only few problems with that proceeding, If someone finds out that we have considerable trouble (for example review will not be done, no commit to 3.5 branch) we will have to think about the proceeding. If you believe discussion or even a fix is required please start a discussion on <email@example.com> or submit a bug for that issue, but do not hijack this bug for that discussion.
(In reply to comment #16)
> It's common sense for this kind of bugs to set status to FIXED when the
> Master-Fix has been committed, although it's a little confusing. Currently we
> have only few problems with that proceeding, If someone finds out that we have
> considerable trouble (for example review will not be done, no commit to 3.5
> branch) we will have to think about the proceeding. If you believe discussion
> or even a fix is required please start a discussion on
> <firstname.lastname@example.org> or submit a bug for that issue, but do
> not hijack this bug for that discussion.
The Bug is fixed: LOdev 3.5.4rc0+
Build ID: 4112bb4-a73d29c-6845e52-f269e46
Data stamp: 2012-05-09_08.32.11
target:3.5.4 due to Comment 17