Apache OpenOffice (AOO) Bugzilla – Issue 14255
Resaving template to same name causes error
Last modified: 2013-08-07 14:42:08 UTC
Steps: 1) Create a new text document. 2) File | Templates | Save and assign it a name. 3) Close it. 4) File | Templates | Edit and choose the newly created template. 5) File | Templates | Save and choose the same name. 6) When the overwrite dialog appears, choose Yes Observed: Error writing <filename> as template. General Error. General input/output error. Expected: No error. Notes: It appears that I don't need to use this technique to save a changed template, but can simply use File | Save, but I can't find that documented anywhere. However, if I can do it, it shouldn't crash.
Still a problem in 1.1Beta2
Was able to reproduce on Linux thanks to Valgrind. Stack dump to follow. The stack dump says osl_destroyMutex is being called when the mutex is still in use. Tamar, thanks for the excellent report!
Created attachment 7434 [details] Stack dump reproduced thanks to Valgrind on RH8
HI->MBA: Could not reproduce, but the stack seems to belong to you.
Michael, please hava a look
Can not reproduce neither in latest 1.1RC build no in 1.1Beta2. The scenario works pretty well for me, the template is overwritten successfully. Unfortunatelly the function call stack does not provide enough information to detect the occured problem. The debug information for libucb1.so and libucbhier1.so libraries would help.
Further investigations shows that there is a possible place in UCB core code where a mutex can be locked forever.
.
The problem in UCB is fixed. Not really sure that the problem is related to this bug, since I can not reproduce it. But in case for any reason a 'RuntimeException' was thrown in 'PersistentPropertySet' methods 'setPropertyValue()' or 'getPropertyValue()' the mutex of the class could stay locked forever. So destruction of the class could cause stack similar to the provided one.
The original descryption of the bug mentiones not only crash but also an error that should not take place. The error is reproducible on systems with file locking. The cause of the error is that document is not set to HandsOff state before saving. This is something that should be implemented for OOo2.0. A new issue i16712 is created.
Just to finalize, the fix for this bug fixes only possibility of forever locked mutex in UCB. Verified in fwk2rc31 workspace.
Mikhail, you said you can't reproduce this bug. Have you tried Valgrind (assuming you have an x86 Linux box)? That should let you reproduce the problem easily... see http://kegel.com/openoffice/#valgrind
Yes, I have tried Valgrind. Unfortunatelly it didn't help to reproduce the problem. However it provided a valuable information about uninitialized variables.
Added keyword 'valgrind' since it helped resolve this issue.
The UCB bugfix is successfully integrated to master workspace => closed.
KSO: Michail's changes in the UCB code definitely fix the problem. The mutex got not only locked forever in case of exceptions, even worse, it got locked whenever PersistentPropertySet::setPropertyValues() was called and at least one property actually was changed and no propertychange listeners were registered. And exactly this happened in the bug scenario.
*** Issue 17725 has been marked as a duplicate of this issue. ***