Issue 124109

NOT reproducible with "AOO 4.0.0 Final – German UI / German locale [AOO400m3(Build:9702) - Rev. 1503704 2013-07-16 14:54:56 (Di, 16 Jul 2013)]" on German German WIN7 Home Premium (64bit)", Common 4.0-dev User Profile

@Sam Jennings
Please attach a sample document and give a more detailed step by step instruction (containing every mouse click and every key press) how to provoke the crash. You never know, may be the crash only happens if you select A3:A2, not not if you select A2:A3, or whatever ...

.

My subsequent efforts to get this to crash the whole program have not worked, and the original file was modified and saved over, so i do not have the original anymore.  I have made a replacement file, which is not causing the problem in its original form, but it is still DEFINITELY causing a problem.  

There are many permutations of the problem.  To underscore that, I have included 3 tables in the file.  In each case, when you delete the column by selecting column cells and using the tool pallet, the table is either fully deleted, or it is modified in an undesired way.

In each case, you merge some or all cells in the top row, and then delete a column beneath the merged cells.  It might happen in more cases than this, but this much is, itself, consistent.

To get specific (so your database has some searchable text on this topic) if you make a table and merge all cells of the top row (select them all and click "merge cells" on the tool pallet) it will unify the top row of the table.  Now select two cells from a column beneath the top row, and, in the tool pallet, click "delete column".  That will cause the entire TABLE to be deleted.  If you don't merge the entire top row, it will merely "deface" the table beyond recognition, deleting all but one column.

The file I'm attaching has more examples.  You should play with it to get an idea.

I believe this column deletion bug was somehow a trigger for the larger problem I observed yesterday, because it was the very last thing I had done when it crashed, and I did get it to crash twice with the same file, and on the same column deletion.  The originally reported "crashing" part of this bug is definitely still under the surface, but how to "tease it out" is unclear to me.

By the way, (and I know... maybe this should be a separate bug report, but it could be material to this crash incident), I have also seen tables go into a state where table attributes can no longer be modified.  Specifically, the pallet of table tools becomes "inactive" when table cells are selected.  I had seen that before the crashes started happening.  For unknown reasons the table had gone from "editable" to "uneditable"... and then somehow I got it back to editable again, but there was something flaky going on underneath that, and loading the file and reediting that table the same way crashed the program consistently , even after closing and reopening openoffice.

Created attachment 82404 [details]
sample file, ready to break

Correction to my last post:  To be more specific, where I said the table went from "editable" to "uneditable", I meant it went from "attribute modifiable" to "not attribute modifiable" (using the tool pallet).  The text inside the table was able to be changed the entire time.

Crash still NOT reproducible with reporter's sample document and server installation of "AOO 4.1.0-Dev – English UI / German locale - [AOO410m1(Build:9750) - Rev. 1559824 - 2014-01-22]" on German WIN7 Home Premium (64bit)", own separate user profile.

Same with 4.0.0!

Are you getting the table bug to happen at all?  Column deletion deleting a table, or mangling its column arrangements?

Some more specific info about my build
Apache OpenOffice 4.0.0
AOO400m3(Bould:9702)-Rev.1503704
2013-07-16 14:54:56 (Di, 16 Jul 2013)

I keep getting mails and messages focused on the crash, which I believe is already established to be intermittent (dependent on a file which no longer exists).  However, other characteristics of table behavior are consistent, and also buggy, and if you can trace them down I believe you will find the origins of the crash itself.  The specified table column deletion is showing a bug, either way.  Has anyone else confirmed (or failed to confirm) the "other" table bugs?  I ask because I feel it is getting overlooked.  I feel pretty confident that they have a direct relationship to the intermittent crash.

To keep all information one place I am repeating some stuff from the corresponding thread on the mailing list:
- I could not reproduce the crash.

- The current behavior regarding the deletion of table columns is more or less the current intended one. This behavior at least exist since OOo 2.2.0 (released in March 2007). When the user triggers action "delete column" the corresponding column is selected (as it would be by the user in the UI) and the selected cells are removed. The corresponding code - as far as I know - does not contain a known defect.

Summarizing:
- crash is not reproducible
- it is not known that the current 'delete column' behavior is defective and might cause the crash observed by the reporter.

--> proposal:
- close this issue as not reproducible
- open new issue for the change in the 'delete column' behavior, if this change is really wanted.

What does the current involved people think regarding my proposal

I believe we should wait on that.  There -is- a crash/data loss bug under the surface somewhere, and I think it would be hasty to sweep it from the records.

Granted, the file I submitted was made from scratch, and it only demonstrates the column deletion bug, but no associated crash.  Clearly something is lacking in the file which was present in the original.  I *made* that file to replicate the circumstances of the original crash, but it was not the original crash file, and as it turns out, that file only caused the column deletion bug.

However, I might still be able to get that crash to happen using a descendant of the original file, which still has a descendant of the table that used to cause the crash, before I modified it (from a user perspective, trying to work around the crash) and then unthinkingly saved it over its predecessor.

If this bug report were to be closed and merged, or refiled, it should carry all elements of description of the column deletion bug, which is definitely not the desired behavior -- multi column tables are deleted on single column deletion, and in other cases multi column tables get badly mangled... this is NOT desired behavior, and it is an open bug...expected as known, perhaps, but definitely not good behavior.

It should also carry mention of the crash (there has been at least one report, etc).

I will get working on trying to modify the descendent file to see if I can get it to crash again.

Meanwhile, can you share the bug report number for the other bug ...you say it's the same bug.  I'd like to see it and read it.  Thanks!

Okay, as a followup on that last comment, I just opened the original file, and modified the table to replicated its "exact" (as close as I could get it without total recall) former design.  I was NOT able to get the table to crash openoffice the same way it did before.  Too bad.  It was 100% reproducible before I saved over the original file.  I will be more conscientious next time, to preserve the "bug resource".

Even so, there is definitely still a bug in table behavior for that file...the same column deletion bug, with at least 2 reproducible manifestations:

1 Deletion of a column beneath a row of merged cells causes the entire table to be deleted, and consistently.

2 Deletion of a column beneath a row of merged cells causes all but one column to be deleted.

Not to pester, but again, I would like to verify that the original bug is actually identical to this, so I would definitely like to see the "original" bug report (assuming it really is the same bug).

Closing due to comment above

For table edit inconsistencies observed during research I submitted "Bug 124153  Merged cells in column cause unexpected additional deletion of adjacent  columns", some more will follow

@Sam Jennings:
Please feel free to submit a NEW Bug if you find out that the problem still exists in the latest public release of AOO and if you can provide requested additional information how to make your problem reproducible for other users. This Bug report has become too long, contains too many wrong red herrings; nobody can fin through if he comes to here.
May I ask you to (simply) submit additional Bugs for problems you observe during research instead of mentioning them again and again?

@Rainer Bielefeld:
I would not have deemed it necessary to repeat myself if you hadn't said table column deletion beneath merged rows works, when it clearly doesn't.

Rainer Bielefeld Said:
"The current behavior regarding the deletion of table columns is more or less the current intended one." 

and

"When the user triggers action "delete column" the corresponding column is selected (as it would be by the user in the UI) and the selected cells are removed. The corresponding code - as far as I know - does not contain a known defect."

The other report does not mention whole table deletion (or the non-reproducible crash), but it does appear to be the same basic bug.

I have to add a new note to this bug, now.  I'm now also getting LOTS of intermittent crashes with ROW deletion.  This is a heavily edited table, and I'm starting to get the impression it's either timing related or perhaps it emerges from successively deleting rows/columns.  I suggest using an automated test tool to track this down.