On Thursday 26 of January 2012, Radek Doulik wrote:
> Hi Stephan,
>
> I am unable to reproduce it here. Do you have some other way to
> reproduce it other then make check?
>
> I am attaching updated patch with fixed loop. Please could you try it?
I can't say about Stephan's problem, but your chan
On 01/26/2012 09:55 AM, Radek Doulik wrote:
I am unable to reproduce it here. Do you have some other way to
reproduce it other then make check?
No, only way I'm aware of is to run forms_unoapi check and watch
system's memory consumption grow obsessively (first slowly but steadily,
then aggres
Hi Stephan,
I am unable to reproduce it here. Do you have some other way to
reproduce it other then make check?
I am attaching updated patch with fixed loop. Please could you try it?
Cheers
Radek
On Wed, 2012-01-25 at 10:42 +0100, Stephan Bergmann wrote:
> One thing I did notice with the first
One thing I did notice with the first hunk of your patch is that it
moved "pAction = NextAction();" outside the for loop -- but that looks
irrelevant to the problem at hand, as ImplPlayWithRenderer appears to
always return true in the newly introduced if here.
Also, forms_unoapi now triggers l
On 01/25/2012 09:53 AM, Stephan Bergmann wrote:
On 01/25/2012 09:33 AM, Radek Doulik wrote:
I have reverted the patch and will try to replicate the problem and fix
it. Thanks for info and sorry for the trouble.
Looks like it is a memory leak in ImplPlayWithRenderer, just having a
look there my
On 01/25/2012 09:33 AM, Radek Doulik wrote:
I have reverted the patch and will try to replicate the problem and fix
it. Thanks for info and sorry for the trouble.
Looks like it is a memory leak in ImplPlayWithRenderer, just having a
look there myself right now.
Stephan
__
Hi Stefan,
I have reverted the patch and will try to replicate the problem and fix
it. Thanks for info and sorry for the trouble.
Cheers
Radek
On Tue, 2012-01-24 at 22:11 +0100, Stephan Bergmann wrote:
> Radek,
>
> bisecting showed me that it is this commit that causes my machine to
> become u
Radek,
bisecting showed me that it is this commit that causes my machine to
become unresponsive (as the involved soffice.bin process keeps growing
in size, apparently without limit) when executing the forms_unoapi test
(during "make check") -- and it is also most likely this commit that
cause
At 11:15am -0500 Tue, 25 Jan 2011, David Tardon wrote:
Hrm, the commit you made 20 minutes earlier made sense. Why would
you revert the removal of unused variables?
Because Caolan already silenced the warning in a different way. I
still prefer to isolate such code in #ifdef, but it clutters the
On Tue, Jan 25, 2011 at 10:10:05AM -0500, Kevin Hunter wrote:
> At 9:42am -0500 Tue, 25 Jan 2011, David Tardon wrote:
> > vcl/source/fontsubset/cff.cxx |4
> > 1 file changed, 4 deletions(-)
> >
> >New commits:
> >commit a1f7b2515a6bd09a5569735a1269a9a4029d2d5c
> >Author: David Tardon
> >
At 9:42am -0500 Tue, 25 Jan 2011, David Tardon wrote:
vcl/source/fontsubset/cff.cxx |4
1 file changed, 4 deletions(-)
New commits:
commit a1f7b2515a6bd09a5569735a1269a9a4029d2d5c
Author: David Tardon
Date: Tue Jan 25 15:41:35 2011 +0100
Revert "WaE: unused variables"
Hrm,
11 matches
Mail list logo
