CC myself

would you please provide the sample file which mentioned in your steps? thank you for your help.

Created attachment 80067 [details]
Sample XML Document

Attached is the sample file. 

Please note that some of the bindings will not work for this as the original file that I created contains several more instances in model 1. I have to remove these instances due to sensitive nature of the data.

Created attachment 80068 [details]
Screenshot for bug 121474

I downloaded the attached document on my windows 7 laptop and kept typing in the "Captain's name text box". The process soffice.bin *32 on the task manager showed increase in memory usage as I typed in. However, finally after a certain level, there was a pop up that said that the inserted text exceeded maximum length for this text field. The text length was truncated. I am attaching the screenshot of the same.

Just to add another observation, for the same form, the listbox works in OO v2.3.1/v2.4 but does not work in v3.3/v3.4.

The listbox involves a binding to a Instance

You can find examples in the same document I attached earlier

Just wondering whether there would be a follow up on this.

I opened the attached file in my local env, and insert strings follow the description, finally got nothing but a warning dialog about "exceeding maximum length".

I was checking that but I don't find the bug reported. The mistake that you indicated in the screenshot attached isn't find. The document is successful.
This was checked in the platform W7 32 BITS version AOO 4.

The problem will arise even if the maximum length for this text field is not exceeded. 

I have tried to type something into the textfield, delete and type something again. The memory usage of soofice.bin *32 keeps going up. 

Please do check again. Appreciate the effort. Can anyone try on a Windows 64bit OS?

Let's see if there is a simple, reproducible way to generate a crash. The fact that the memory increases even if text is deleted is not a particularly significant indicator (strings are kept in memory for undo information, for example; and there are other factors; while a crash is far easier to agree upon).

Following indications from the original poster, I tried typing random stuff into "Captain's name". I reached 2500 characters without crashing or slowing down OpenOffice (tested on 64 bit, but on Linux and with OpenOffice 4.0.0m2).

cmgoh1979: Can you provide precise, step by step instructions to reproduce the crash with the latest 4.0 snapshot? You can find it here: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshotfullsets ; if you manage to crash OpenOffice, please give instructions on how to reproduce it (go to the field X, type Y characters...)

Thanks for the reply Andrea.

Would start from the environment. Seems that most of you are running Linux... maybe the problem occurs on Windows?

OS: Windows 7 Pro SP1 64bit
JRE: 7 u 15 (32bit)

Open the document I attached earlier, sample.odt. Please note that this is an XML Form Document. The memory issue here applies to XML Form Document. The problem does not occur for "small" forms. Unable to quantify the "small". I tried with just 2-3 text fields and the problem does not occur. 

Goto the textfield with "Captain's Name". 

Open up Task Manager and goto soffice.bin*32 under Processes. (normally i put the document and task manager side-by-side so that I can monitor. 

Start typing in that field (like just press "T"). Approximately, for every 20-30 characters entered continuously, the memory of soffice.bin would increase by about 1200Kb. 

Delete these 20-30 characters and repeat again. Repeat this as many times as possible. The memory of soffice.bin keeps on increasing.

Depending on your PC memory settings, at some point, OpenOffice will crash/hang. If you reopen the doc after crash, it will prompt for recovery. 

My initial hunch is the Data Navigator that is causing the memory to increase. But I have no tools to verify that.


Best regards
Chong Minsk



(In reply to Andrea Pescetti from comment #10)
> Let's see if there is a simple, reproducible way to generate a crash. The
> fact that the memory increases even if text is deleted is not a particularly
> significant indicator (strings are kept in memory for undo information, for
> example; and there are other factors; while a crash is far easier to agree
> upon).
> 
> Following indications from the original poster, I tried typing random stuff
> into "Captain's name". I reached 2500 characters without crashing or slowing
> down OpenOffice (tested on 64 bit, but on Linux and with OpenOffice 4.0.0m2).
> 
> cmgoh1979: Can you provide precise, step by step instructions to reproduce
> the crash with the latest 4.0 snapshot? You can find it here:
> https://cwiki.apache.org/confluence/display/OOOUSERS/
> Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshotfullsets ;
> if you manage to crash OpenOffice, please give instructions on how to
> reproduce it (go to the field X, type Y characters...)

I was not able to replicate this bug on a Windows XP Pro Version 2002 SP3 machine. I followed the replication process step by step and tested on both OpenOffice 4 AOO400m2(Build:9701) - Rev. 1489073 and OpenOffice 3.4.1 AOO341m1(Build:9593) - Rev. 1372282. 

When I had the task manager open side-by-side I could see that the soffice.bin did indeed keep increasing from the letters being inputted and deleted, but my memory only jumped 80 to 100Kb's at a time. I conducted this part of the test for around 10 minutes with no freezing or slowing noticeable. I also tried maxing out the text box with letters to see if I could make the memory jump higher but to no avail.

Lastly I tried multiple text boxes with the same technique mention in the replication process in the document and still saw the same results mentioned above.

Any idea what is the cause of the increasing memory?


(In reply to surfxz from comment #12)
> I was not able to replicate this bug on a Windows XP Pro Version 2002 SP3
> machine. I followed the replication process step by step and tested on both
> OpenOffice 4 AOO400m2(Build:9701) - Rev. 1489073 and OpenOffice 3.4.1
> AOO341m1(Build:9593) - Rev. 1372282. 
> 
> When I had the task manager open side-by-side I could see that the
> soffice.bin did indeed keep increasing from the letters being inputted and
> deleted, but my memory only jumped 80 to 100Kb's at a time. I conducted this
> part of the test for around 10 minutes with no freezing or slowing
> noticeable. I also tried maxing out the text box with letters to see if I
> could make the memory jump higher but to no avail.
> 
> Lastly I tried multiple text boxes with the same technique mention in the
> replication process in the document and still saw the same results mentioned
> above.

I was able to reproduce this bug in OO Writer v3.4.1 on a Windows 7 x64 machine. I did this using the sample document provided by the original poster.

How to Replicate:
1. Open or create XML form document with fields.
2. Type text into field at a normal pace so that the “undo” feature only deletes a character or a single word at a time. (If a user copies and pastes text in massive amounts it will not have a greater effect.)
3. Continue until the memory in use by the soffice.bin process is between 79,000 kilobytes and 85,000K kilobytes. At this point, Write should slow down or crash.

Following the method above I was able to crash the program twice. I gave careful attention to the change in memory while trying to crash the program. In both instances, I noticed that it didn’t matter if I typed in single characters at a time or pasted massive amounts of text; that both methods increased memory by the same amount. I accomplished both crashes by typing in two different fields on two separate pages. I tried deleting the text I entered in both occurrences, but the memory did not reduce. The rate of increase in memory was about 100 kilobytes for each handful of characters I typed.

When I first opened the XML form, the memory was about 39,000 kilobytes. The first crash occurred at approximately 79,500 kilobytes, and the second crash occurred at approximately 81,000 kilobytes. On the second crash the characters I entered into the field became invisible, even as I continued to type. I could not get them to reappear again. Writer also came to a crawl in terms of response time. I continued to type after this for a few seconds and the program finally crashed.

My Thoughts:
The nature of this seems that it may be a stack overflow for the undo/redo feature. It did not matter if I slowly typed a single character at a time, or repeatedly pasted in a page’s worth of text at a time for the result was the same. Typically every time a change is made in a text editor, all the data associated with that change is thrown onto a stack so that a user may undo it. Overflowing this stack may cause the program to crash. This issue also seems to be pretty important due to the fact that this bug can affect many users and it is relatively easy to trigger.

No problem with attachment 80067 [details]
AOO410m16(Build:9762)  -  Rev. 1585426
2014-04-07 10:29:13 (Mo, 07 Apr 2014)
Win 7