Issue 126326

Created attachment 84752 [details]
Has UDF for use in repoducing the issue.

Created attachment 84755 [details]
Writer document with all UDF present.

File "Crash on double change of UDF.odt" has all the UDF's and is stable.  

File "Crash on double change of UDF_01.odt" has some fields deleted, as per the instructions to reproduce the issue.  
File "Crash on double change of UDF_01.odt" is unstable (because it has the issue reproduced) and may ask the user to recovery the document when first opened.

Created attachment 85016 [details]
Document untouched post-crash

I was able to replicate the bug. 

Configuration:
Windows 10 64-bit.
AOO420m1(Build:9800)  -  Rev. 1692551

Seems like attempting to delete a user defined field bearing the same name as a previously deleted user defined field and then saving the document leads to a crash.

Steps taken to reproduce:
1. download "Writer document with all UDF present." ODT file to Desktop
2. right click -> open with -> OpenOffice Writer
3. The file has twelve user-defined fields at the top. Highlight the first one and hit the delete key. Repeat for the next two so that {{Text_field_one}} {{Text_field_two}} and {{Text_field_three}} are all deleted.
4. Insert Menu -> Fields -> Other...
5. Go to the Variables tab
6. In the box named "Selection" click Text_field_one and delete it by pressing the red X button near the bottom of the window.
7. The top user-defined field Text_field_eight should be selected. Clear its name field.
8. name it Text_field_two (one of the ones that should have been deleted)
9. Click the red X button to delete this one as well.
10. Press the Close button to close the window.
11. CTRL+S to save the document leads to a crash.

I've had the program both just stop responding, and also just completely crash to the desktop instantly when following the above steps. A quick search revealed some other fields-related issues but nothing related to deleting the same field twice leading to a crash.

I've attached Paul's original file "Writer document with all UDF present." after I ran through the steps above and it crashed without touching it post-crash in the event there might be some half-saved information present that may assist in troubleshooting.

I could reproduce the crash on a Macbook Pro with 16 MB RAM with the attached document.
I also could reproduce it on the same Macbook in the Virtual Machine Parallel Desktop running Windows 7
The difference of the crashes was, that on the native Mac Version the program crashed without any message to the user, while the crash on Windows 7, the user got informed in a pop up window about the crash.

 The steps to reproduce from Pablo Canseco 2015-10-07 02:52:35 UTC were easier to follow than the original description in the file.

Created attachment 85714 [details]
Screenshot before and after application freezes on field delete

This is a scenario where the application freezes rather than crashes after menu deletion of a user defined field sharing the name of one already deleted from the document

Reproduced Following Pablo's Instructions and narrowed down the issue a bit more.

It doesn't seem to be dependent on the number of fields you delete and you don't need to delete the original field from the menu at all. It seems like the cause of the crash is that renaming acts as a workaround to allow removal of user defined fields from the menu without deleting them in the document first.

Running: Windows 7 64-Bit
Pentium T4500 Dual-Core 2.30Ghz
OpenOffice 4.1.2
AOO412m3(Build:9782)-Rev. 1709699


When a user defined field is deleted in the document it enables the red X for that field in the "Fields" menu so it can also be removed from there as well
It appears however that this option is enabled based on the name of the field, so you can simply change the the name of any existing user defined field to that of a field that has been deleted in the document and see the red X appear.
If you then try to use that red x to delete the renamed field from the menu, despite the fact it hasn't been deleted from the document itself then save it, the application will hang indefinitely with the saving document bar half full.
I did experience a couple crashes as well using the same process, but in most of my trials it hung requiring the application to be killed manually. I didn't see any noticeable pattern for crashes vs freezes and saw both occur using the same combination of deletions. 
While the application was hanging I also saw a large spike in CPU usage (50% in my case) from soffice.bin

To reproduce with minimal changes:
-Open "Writer document with all UDF present"
-Delete the highlighted data for text field one: "{{Text_field_one}}"
-Go To menu>Insert>Fields>Other
_Select "Variables"
-Select "User Field" under Type
-select Text_field_eight
-Change the name in the bottom right corner to "Text_field_one"
-You should see the X at the bottom turn red
-Press the X
-Save the document
-The application should either hang or crash while saving

You can essentially use this renaming process to delete every user defined field from the Fields menu while all but the initial one remain in the document itself. The broken state of these fields which exist in the document but not the menu may be the cause of the hang/crash when saving.

Marking as confirmed. To all that tested this bug, please subscribe to the QA mailing list and request to be added to the QA team on Bugzilla. This will allow you to confirm issues that you test along with other privileges. To subscribe send a blank e-mail to mailto:qa-subscribe@openoffice.apache.org then follow the instructions in the follow-up e-mail. To post to the list after subscribing send mail to mailto:qa@openoffice.apache.org.