You are viewing a plain text version of this content. The canonical link for it is here.
Posted to qa@openoffice.apache.org by Linyi Li <li...@gmail.com> on 2012/07/23 05:11:54 UTC
[QA REPORT] After long-running GUI testing, memory leak is much less
than before.
Hi all,
Last week I did some long-running GUI testing on AOO 3.4, build r1359641,
using Java on my ubuntu10.04.
- Here is my scenario:
1. Create new Text Document/Spreadsheet/Presentation/Drawing.
2. Input some simple text in it.
3. Save and then reopen it.
4. Repeat the above steps.
- Here is the long-running report.
471 iterations, 61 hours, memory changed from 121168 KB to 809644 KB，+1462KB
per iteration.
Comparing with the long-running test report on June 8[1], memory leak is
half of that time.
Thanks to those who contributed to this. Hope memory leak will be less and
less.
[1]
On Mon, Jun 11, 2012 at 9:17 AM, Zhe Liu <al...@gmail.com> wrote:
> Unfortunately，I lost Mac data and forget the iteration count.
> Fortunately, I also did the same test on Ubuntu:
> 361 iterations, 48hours, memory changed from 122644KB to 1133668KB，
> +2800KB per iteration.
>
--
--
Best wishes.
Linyi Li
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by Zhe Liu <al...@gmail.com>.
Well done!
2012/7/23 Linyi Li <li...@gmail.com>:
> Hi all,
>
> Last week I did some long-running GUI testing on AOO 3.4, build r1359641,
> using Java on my ubuntu10.04.
>
>
> - Here is my scenario:
>
> 1. Create new Text Document/Spreadsheet/Presentation/Drawing.
> 2. Input some simple text in it.
> 3. Save and then reopen it.
> 4. Repeat the above steps.
>
>
> - Here is the long-running report.
>
> 471 iterations, 61 hours, memory changed from 121168 KB to 809644 KB，+1462KB
> per iteration.
>
> Comparing with the long-running test report on June 8[1], memory leak is
> half of that time.
>
> Thanks to those who contributed to this. Hope memory leak will be less and
> less.
>
> [1]
> On Mon, Jun 11, 2012 at 9:17 AM, Zhe Liu <al...@gmail.com> wrote:
>
>> Unfortunately，I lost Mac data and forget the iteration count.
>> Fortunately, I also did the same test on Ubuntu:
>> 361 iterations, 48hours, memory changed from 122644KB to 1133668KB，
>> +2800KB per iteration.
>>
> --
>
> --
> Best wishes.
> Linyi Li
--
Best Regards
>From aliuzhe@gmail.com
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by Chao Huang <ch...@gmail.com>.
Thanks for your verification !
2012/7/23 Linyi Li <li...@gmail.com>
> Hi all,
>
> Last week I did some long-running GUI testing on AOO 3.4, build r1359641,
> using Java on my ubuntu10.04.
>
>
> - Here is my scenario:
>
> 1. Create new Text Document/Spreadsheet/Presentation/Drawing.
> 2. Input some simple text in it.
> 3. Save and then reopen it.
> 4. Repeat the above steps.
>
>
> - Here is the long-running report.
>
> 471 iterations, 61 hours, memory changed from 121168 KB to 809644
> KB，+1462KB
> per iteration.
>
> Comparing with the long-running test report on June 8[1], memory leak is
> half of that time.
>
> Thanks to those who contributed to this. Hope memory leak will be less and
> less.
>
> [1]
> On Mon, Jun 11, 2012 at 9:17 AM, Zhe Liu <al...@gmail.com> wrote:
>
> > Unfortunately，I lost Mac data and forget the iteration count.
> > Fortunately, I also did the same test on Ubuntu:
> > 361 iterations, 48hours, memory changed from 122644KB to 1133668KB，
> > +2800KB per iteration.
> >
> --
>
> --
> Best wishes.
> Linyi Li
>
--
Best regards,
Chao Huang
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by Herbert Duerr <hd...@apache.org>.
On 24.07.2012 17:59, Rob Weir wrote:
> On Mon, Jul 23, 2012 at 10:55 PM, Linyi Li <li...@gmail.com> wrote:
>> It is a good suggestion to test memory leak. Maybe we can write some test
>> cases based on memory leak defect.
Yes, that is a good idea. The valgrind tool could be very helpful for
such an automated test.
> It is tricky. For example, a dialog box might have a memory leak when
> you click "cancel" but not when you click "OK" to exit it. The leak
> can depend on the exact steps taken by the user and the exact path
> through the code. We can never test all paths.
Yes. It gets even more tricky when caches come into play. E.g. a
spellchecker may cache some parts of the dictionary depending on the
documents it already parsed.
Adding support for a memleak-checker friendly mode to such caches can
help here though. If this mode is enabled they will discard unused
entries as soon as possible.
> Maybe one of the long-time OpenOffice developers know an answer to
> this: Have we ever considered having a custom memory allocator with a
> separate pool of memory for each loaded document?
IIRC they are already here and were called "rtl_arena" or "rtl_cache".
Please see main/sal/inc/rtl/alloc.h for details.
Also there were specialized memory allocators based on them but using
different ones (e.g. by using the "--with-alloc" configure option) AFAIK
didn't hurt the performance too much.
> That way, when we
> close a document we can just free the entire block and avoid any
> memory leaks? We did this with SmartSuite years ago, and it was a big
> help.
This looks like an interesting idea.
Herbert
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jul 23, 2012 at 10:55 PM, Linyi Li <li...@gmail.com> wrote:
>> Exactly, it is the way it is working. And I believe this test only
>> shows a part of leaks. It still needs other use cases to show
>> different kinds of memory leaks. Perhaps checking existing memory leak
>> bugs which has specific steps is a good direction.
>>
>
> +1
> It is a good suggestion to test memory leak. Maybe we can write some test
> cases based on memory leak defect.
>
It is tricky. For example, a dialog box might have a memory leak when
you click "cancel" but not when you click "OK" to exit it. The leak
can depend on the exact steps taken by the user and the exact path
through the code. We can never test all paths.
Maybe one of the long-time OpenOffice developers know an answer to
this: Have we ever considered having a custom memory allocator with a
separate pool of memory for each loaded document? That way, when we
close a document we can just free the entire block and avoid any
memory leaks? We did this with SmartSuite years ago, and it was a big
help.
-Rob
> --
> Best wishes.
> Linyi Li
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by Linyi Li <li...@gmail.com>.
> Exactly, it is the way it is working. And I believe this test only
> shows a part of leaks. It still needs other use cases to show
> different kinds of memory leaks. Perhaps checking existing memory leak
> bugs which has specific steps is a good direction.
>
+1
It is a good suggestion to test memory leak. Maybe we can write some test
cases based on memory leak defect.
--
Best wishes.
Linyi Li
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by zhangjf <zh...@apache.org>.
On Tue, Jul 24, 2012 at 12:08 AM, Kay Schenk <ka...@gmail.com> wrote:
> On Mon, Jul 23, 2012 at 8:30 AM, Jürgen Schmidt
> <jo...@googlemail.com>wrote:
>
>> On 7/23/12 4:59 PM, Kay Schenk wrote:
>> >
>> >
>> > On 07/23/2012 12:20 AM, Jürgen Schmidt wrote:
>> >> On 7/23/12 5:11 AM, Linyi Li wrote:
>> >>> Hi all,
>> >>>
>> >>> Last week I did some long-running GUI testing on AOO 3.4, build
>> >>> r1359641,
>> >>> using Java on my ubuntu10.04.
>> >>>
>> >>>
>> >>> - Here is my scenario:
>> >>>
>> >>> 1. Create new Text Document/Spreadsheet/Presentation/Drawing.
>> >>> 2. Input some simple text in it.
>> >>> 3. Save and then reopen it.
>> >>> 4. Repeat the above steps.
>> >>>
>> >>>
>> >>> - Here is the long-running report.
>> >>>
>> >>> 471 iterations, 61 hours, memory changed from 121168 KB to 809644
>> >>> KB，+1462KB
>> >>> per iteration.
>> >>>
>> >>> Comparing with the long-running test report on June 8[1], memory leak
>> is
>> >>> half of that time.
>> >>>
>> >>> Thanks to those who contributed to this. Hope memory leak will be
>> >>> less and
>> >>> less.
>> >>
>> >> thanks for the report and the good news, it's promising for the future
>> >>
>> >> Juergen
>> >
>> > Hi Linyi --
>> >
>> > Yes, thanks indeed for this good news. I marked this issue as "critical"
>> > yesterday.
>> >
>> > OK, maybe you can enlighten us. How would a "memory leak" get better
>> > exactly? Does this mean that AOO is doing something differently *now*,
>> > that is in the last few weeks, than it was when this was initially
>> > re-reported at the beginning of June?
>>
>> it is not one memory leak, we have have many leaks in different places
>> in the code.
>> And with fixing one of these issues the meta issue "memory leak" becomes
>> better if you want ;-)
>>
>> >
>> > And, according to Dennis's notes on issue 11934:
>> >
>> > https://issues.apache.org/ooo/show_bug.cgi?id=119341
>> >
>> > these kinds of problems have been around as early as version 1.1.
>> >
>> > I didn't see any changes in the commit logs in the last few weeks that
>> > would have directly addressed this.
>> >
>>
>> fixes in other areas, I think this special one is not yet addressed
>>
>> Juergen
>>
>
> OK, thanks...little by little I guess.
>
Exactly, it is the way it is working. And I believe this test only
shows a part of leaks. It still needs other use cases to show
different kinds of memory leaks. Perhaps checking existing memory leak
bugs which has specific steps is a good direction.
zhangjf
>
>
>>
>> > Your thoughts?
>> >
>> >
>> >>
>> >>>
>> >>> [1]
>> >>> On Mon, Jun 11, 2012 at 9:17 AM, Zhe Liu <al...@gmail.com> wrote:
>> >>>
>> >>>> Unfortunately，I lost Mac data and forget the iteration count.
>> >>>> Fortunately, I also did the same test on Ubuntu:
>> >>>> 361 iterations, 48hours, memory changed from 122644KB to 1133668KB，
>> >>>> +2800KB per iteration.
>> >>>>
>> >>
>> >
>>
>>
>
>
> --
> ----------------------------------------------------------------------------------------
> MzK
>
> "I'm just a normal jerk who happens to make music.
> As long as my brain and fingers work, I'm cool."
> -- Eddie Van Halen
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Jul 23, 2012 at 8:30 AM, Jürgen Schmidt
<jo...@googlemail.com>wrote:
> On 7/23/12 4:59 PM, Kay Schenk wrote:
> >
> >
> > On 07/23/2012 12:20 AM, Jürgen Schmidt wrote:
> >> On 7/23/12 5:11 AM, Linyi Li wrote:
> >>> Hi all,
> >>>
> >>> Last week I did some long-running GUI testing on AOO 3.4, build
> >>> r1359641,
> >>> using Java on my ubuntu10.04.
> >>>
> >>>
> >>> - Here is my scenario:
> >>>
> >>> 1. Create new Text Document/Spreadsheet/Presentation/Drawing.
> >>> 2. Input some simple text in it.
> >>> 3. Save and then reopen it.
> >>> 4. Repeat the above steps.
> >>>
> >>>
> >>> - Here is the long-running report.
> >>>
> >>> 471 iterations, 61 hours, memory changed from 121168 KB to 809644
> >>> KB，+1462KB
> >>> per iteration.
> >>>
> >>> Comparing with the long-running test report on June 8[1], memory leak
> is
> >>> half of that time.
> >>>
> >>> Thanks to those who contributed to this. Hope memory leak will be
> >>> less and
> >>> less.
> >>
> >> thanks for the report and the good news, it's promising for the future
> >>
> >> Juergen
> >
> > Hi Linyi --
> >
> > Yes, thanks indeed for this good news. I marked this issue as "critical"
> > yesterday.
> >
> > OK, maybe you can enlighten us. How would a "memory leak" get better
> > exactly? Does this mean that AOO is doing something differently *now*,
> > that is in the last few weeks, than it was when this was initially
> > re-reported at the beginning of June?
>
> it is not one memory leak, we have have many leaks in different places
> in the code.
> And with fixing one of these issues the meta issue "memory leak" becomes
> better if you want ;-)
>
> >
> > And, according to Dennis's notes on issue 11934:
> >
> > https://issues.apache.org/ooo/show_bug.cgi?id=119341
> >
> > these kinds of problems have been around as early as version 1.1.
> >
> > I didn't see any changes in the commit logs in the last few weeks that
> > would have directly addressed this.
> >
>
> fixes in other areas, I think this special one is not yet addressed
>
> Juergen
>
OK, thanks...little by little I guess.
>
> > Your thoughts?
> >
> >
> >>
> >>>
> >>> [1]
> >>> On Mon, Jun 11, 2012 at 9:17 AM, Zhe Liu <al...@gmail.com> wrote:
> >>>
> >>>> Unfortunately，I lost Mac data and forget the iteration count.
> >>>> Fortunately, I also did the same test on Ubuntu:
> >>>> 361 iterations, 48hours, memory changed from 122644KB to 1133668KB，
> >>>> +2800KB per iteration.
> >>>>
> >>
> >
>
>
--
----------------------------------------------------------------------------------------
MzK
"I'm just a normal jerk who happens to make music.
As long as my brain and fingers work, I'm cool."
-- Eddie Van Halen
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 7/23/12 4:59 PM, Kay Schenk wrote:
>
>
> On 07/23/2012 12:20 AM, Jürgen Schmidt wrote:
>> On 7/23/12 5:11 AM, Linyi Li wrote:
>>> Hi all,
>>>
>>> Last week I did some long-running GUI testing on AOO 3.4, build
>>> r1359641,
>>> using Java on my ubuntu10.04.
>>>
>>>
>>> - Here is my scenario:
>>>
>>> 1. Create new Text Document/Spreadsheet/Presentation/Drawing.
>>> 2. Input some simple text in it.
>>> 3. Save and then reopen it.
>>> 4. Repeat the above steps.
>>>
>>>
>>> - Here is the long-running report.
>>>
>>> 471 iterations, 61 hours, memory changed from 121168 KB to 809644
>>> KB，+1462KB
>>> per iteration.
>>>
>>> Comparing with the long-running test report on June 8[1], memory leak is
>>> half of that time.
>>>
>>> Thanks to those who contributed to this. Hope memory leak will be
>>> less and
>>> less.
>>
>> thanks for the report and the good news, it's promising for the future
>>
>> Juergen
>
> Hi Linyi --
>
> Yes, thanks indeed for this good news. I marked this issue as "critical"
> yesterday.
>
> OK, maybe you can enlighten us. How would a "memory leak" get better
> exactly? Does this mean that AOO is doing something differently *now*,
> that is in the last few weeks, than it was when this was initially
> re-reported at the beginning of June?
it is not one memory leak, we have have many leaks in different places
in the code.
And with fixing one of these issues the meta issue "memory leak" becomes
better if you want ;-)
>
> And, according to Dennis's notes on issue 11934:
>
> https://issues.apache.org/ooo/show_bug.cgi?id=119341
>
> these kinds of problems have been around as early as version 1.1.
>
> I didn't see any changes in the commit logs in the last few weeks that
> would have directly addressed this.
>
fixes in other areas, I think this special one is not yet addressed
Juergen
> Your thoughts?
>
>
>>
>>>
>>> [1]
>>> On Mon, Jun 11, 2012 at 9:17 AM, Zhe Liu <al...@gmail.com> wrote:
>>>
>>>> Unfortunately，I lost Mac data and forget the iteration count.
>>>> Fortunately, I also did the same test on Ubuntu:
>>>> 361 iterations, 48hours, memory changed from 122644KB to 1133668KB，
>>>> +2800KB per iteration.
>>>>
>>
>
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by Kay Schenk <ka...@gmail.com>.
On 07/23/2012 12:20 AM, Jürgen Schmidt wrote:
> On 7/23/12 5:11 AM, Linyi Li wrote:
>> Hi all,
>>
>> Last week I did some long-running GUI testing on AOO 3.4, build r1359641,
>> using Java on my ubuntu10.04.
>>
>>
>> - Here is my scenario:
>>
>> 1. Create new Text Document/Spreadsheet/Presentation/Drawing.
>> 2. Input some simple text in it.
>> 3. Save and then reopen it.
>> 4. Repeat the above steps.
>>
>>
>> - Here is the long-running report.
>>
>> 471 iterations, 61 hours, memory changed from 121168 KB to 809644 KB，+1462KB
>> per iteration.
>>
>> Comparing with the long-running test report on June 8[1], memory leak is
>> half of that time.
>>
>> Thanks to those who contributed to this. Hope memory leak will be less and
>> less.
>
> thanks for the report and the good news, it's promising for the future
>
> Juergen
Hi Linyi --
Yes, thanks indeed for this good news. I marked this issue as "critical"
yesterday.
OK, maybe you can enlighten us. How would a "memory leak" get better
exactly? Does this mean that AOO is doing something differently *now*,
that is in the last few weeks, than it was when this was initially
re-reported at the beginning of June?
And, according to Dennis's notes on issue 11934:
https://issues.apache.org/ooo/show_bug.cgi?id=119341
these kinds of problems have been around as early as version 1.1.
I didn't see any changes in the commit logs in the last few weeks that
would have directly addressed this.
Your thoughts?
>
>>
>> [1]
>> On Mon, Jun 11, 2012 at 9:17 AM, Zhe Liu <al...@gmail.com> wrote:
>>
>>> Unfortunately，I lost Mac data and forget the iteration count.
>>> Fortunately, I also did the same test on Ubuntu:
>>> 361 iterations, 48hours, memory changed from 122644KB to 1133668KB，
>>> +2800KB per iteration.
>>>
>
--
------------------------------------------------------------------------
MzK
"I'm just a normal jerk who happens to make music.
As long as my brain and fingers work, I'm cool."
-- Eddie Van Halen
Re: [QA REPORT] After long-running GUI testing, memory leak is much
less than before.
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 7/23/12 5:11 AM, Linyi Li wrote:
> Hi all,
>
> Last week I did some long-running GUI testing on AOO 3.4, build r1359641,
> using Java on my ubuntu10.04.
>
>
> - Here is my scenario:
>
> 1. Create new Text Document/Spreadsheet/Presentation/Drawing.
> 2. Input some simple text in it.
> 3. Save and then reopen it.
> 4. Repeat the above steps.
>
>
> - Here is the long-running report.
>
> 471 iterations, 61 hours, memory changed from 121168 KB to 809644 KB，+1462KB
> per iteration.
>
> Comparing with the long-running test report on June 8[1], memory leak is
> half of that time.
>
> Thanks to those who contributed to this. Hope memory leak will be less and
> less.
thanks for the report and the good news, it's promising for the future
Juergen
>
> [1]
> On Mon, Jun 11, 2012 at 9:17 AM, Zhe Liu <al...@gmail.com> wrote:
>
>> Unfortunately，I lost Mac data and forget the iteration count.
>> Fortunately, I also did the same test on Ubuntu:
>> 361 iterations, 48hours, memory changed from 122644KB to 1133668KB，
>> +2800KB per iteration.
>>