Re: Memory usage: 4MB per page?

View: New views
18 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/2/09 7:40 PM, Georgios Petasis wrote:
> But I have a large problem: memory usage is increased by each page I load.
> I have used valgrind to debug the memory usage, but nothing that
> originates from code seems to be leaked. All leaked objects seem to have
> been created inside mozilla libraries.

Have you considered creating a refcount log and seeing where the missing
refcounts might be?

> 1) I have no history navigation. I can reload the current page, but I
> cannot go back/forward.

Did you enable session history on your nsIWebBrowser?

> WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file
> /home/backup_disk/petasis/TkGecko/mozilla-central/toolkit/components/places/src/nsNavHistory.cpp,
> line 600
> WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file
> /home/backup_disk/petasis/TkGecko/mozilla-central/toolkit/components/places/src/nsNavHistory.cpp,
> line 472
> WARNING: EnableGlobalHistory() failed: 'NS_SUCCEEDED(rv)', file
> /home/backup_disk/petasis/TkGecko/mozilla-central/embedding/browser/webBrowser/nsWebBrowser.cpp,
> line 1213
>
> How can I fix this?

Actually have a profile.  Those are failures to get the profile directory.

> 2) When the application exits, there is a long list of leaked urls. How
> can I free them, so as not to get leaked?

That's the same as the very first issue you mentioned.  The answer
depends on why they're being leaked.
> 3) During exit, I get an abort:
>
> ABORT: imgCacheEntry release isn't thread-safe!:
> '_mOwningThread.GetThread() == PR_GetCurrentThread()', file
> /home/backup_disk/petasis/TkGecko/mozilla-central/modules/libpr0n/src/imgLoader.h,
> line 81
> UNKNOWN
> [/home/backup_disk/petasis/TkGecko/mozilla-central/obj-xulrunner-d/dist/bin/libxul.so
> +0x004C314D]

That indicates that you're shutting down the image cache from a non-main
thread.  Don't do that.

> I think that I have forgot something (what?) that relates to
> navigation/cache, and the application keeps everything in memory. Is
> this possible?

Unlikely; there are limits on how much is kept in memory...

> http://tkgecko.svn.sourceforge.net/viewvc/tkgecko/tkgecko/src/

Which thread do the GetProxyFor* functions in
http://tkgecko.svn.sourceforge.net/viewvc/tkgecko/tkgecko/src/TkGecko_Browser.cpp?revision=19&view=markup 
run on?

-Boris

_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/2/09 8:31 PM, Boris Zbarsky wrote:
>> http://tkgecko.svn.sourceforge.net/viewvc/tkgecko/tkgecko/src/

It might help to carefully trace through the functions you're executing.
  I can't tell from here which they are, but for example
Browser::GetEncoder leaks |doc|.  Browser::SaveDocument leaks |document|.

I can't find your QueueEvent implementation, but this code in DOM::DOM:

    39     mBrowser->QueueEvent(&p, "get_document");
    40     document = p.document;

looks possibly suspect to me, depending on how your get_document is
impemented.

-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/2/09 8:39 PM, Boris Zbarsky wrote:
> It might help to carefully trace through the functions you're executing.

Unless its callers are very careful, DOM::GetBody leaks the body.

-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Georgios Petasis-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

O/H Boris Zbarsky έγραψε:
> On 11/2/09 7:40 PM, Georgios Petasis wrote:
>> But I have a large problem: memory usage is increased by each page I
>> load.
>> I have used valgrind to debug the memory usage, but nothing that
>> originates from code seems to be leaked. All leaked objects seem to have
>> been created inside mozilla libraries.
>
> Have you considered creating a refcount log and seeing where the
> missing refcounts might be?
Yes, using instructions from
https://developer.mozilla.org/en/Debugging_memory_leaks.
But I reach no conclusions...
>
>> 1) I have no history navigation. I can reload the current page, but I
>> cannot go back/forward.
>
> Did you enable session history on your nsIWebBrowser?
If it is not on by default, I haven't add any code to enable this. How
can I enable this?
https://developer.mozilla.org/en/NsIWebBrowser does not offer that many
methods.
Also, in my code:
http://tkgecko.svn.sourceforge.net/viewvc/tkgecko/tkgecko/src/TkGecko_Browser.cpp?revision=19&view=markup
(functions Browser::Init & Browser::AttachWindow)
I tried to do the following:

/* Create our session history object and tell the navigation object
 * to use it.  We need to do this before we create the web browser
 * window... */
mSessionHistory = do_CreateInstance(NS_SHISTORY_CONTRACTID, &rv);
mNavigation->SetSessionHistory(mSessionHistory);
if (NS_FAILED(rv)) return rv;

But I get the exact same results. mSessionHistory & mNavigation are
members of the class, defined in Browser.h:
nsCOMPtr<nsIWebBrowser> mWebBrowser; // [OWNER]
nsCOMPtr<nsIWebNavigation> mNavigation; // [OWNER]

Is there anything else I should do?

>
>> WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file
>> /home/backup_disk/petasis/TkGecko/mozilla-central/toolkit/components/places/src/nsNavHistory.cpp,
>>
>> line 600
>> WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file
>> /home/backup_disk/petasis/TkGecko/mozilla-central/toolkit/components/places/src/nsNavHistory.cpp,
>>
>> line 472
>> WARNING: EnableGlobalHistory() failed: 'NS_SUCCEEDED(rv)', file
>> /home/backup_disk/petasis/TkGecko/mozilla-central/embedding/browser/webBrowser/nsWebBrowser.cpp,
>>
>> line 1213
>>
>> How can I fix this?
>
> Actually have a profile. Those are failures to get the profile directory.
My initialisation happens in functions:

Browser::InitializeXPCOM()
Browser::InitializeXUL()

at the end of Browser.cpp:
http://tkgecko.svn.sourceforge.net/viewvc/tkgecko/tkgecko/src/TkGecko_Browser.cpp?revision=19&view=markup.
I simply call

XRE_InitEmbedding(mXulDir, mAppDir, 0, 0, 0);

In the way I call XRE_InitEmbedding, mXulDir = mAppDir, and is the
parent directory xpcom.so was found.
Should I use something else?

>
>> 2) When the application exits, there is a long list of leaked urls. How
>> can I free them, so as not to get leaked?
>
> That's the same as the very first issue you mentioned. The answer
> depends on why they're being leaked.
I have the feeling that despite the fact that my AddRef() & Release()
are balanced, each page I load remains alive "somewhere".
I don't know where though :-)

>> 3) During exit, I get an abort:
>>
>> ABORT: imgCacheEntry release isn't thread-safe!:
>> '_mOwningThread.GetThread() == PR_GetCurrentThread()', file
>> /home/backup_disk/petasis/TkGecko/mozilla-central/modules/libpr0n/src/imgLoader.h,
>>
>> line 81
>> UNKNOWN
>> [/home/backup_disk/petasis/TkGecko/mozilla-central/obj-xulrunner-d/dist/bin/libxul.so
>>
>> +0x004C314D]
>
> That indicates that you're shutting down the image cache from a
> non-main thread. Don't do that.
Well, this needs more investigation from my side. I don't think that I
am doing, but perhaps I am wrong.
In fact this happens when I call exit, from a thread different than the
thread mozilla runs. It seems that mozilla
registers some callbacks that trigger on exit, and these are triggered
from a different thread?
>
>> I think that I have forgot something (what?) that relates to
>> navigation/cache, and the application keeps everything in memory. Is
>> this possible?
>
> Unlikely; there are limits on how much is kept in memory...
I tried to reload the same page many times (i.e. 120). The memory used
by the application grew up to 500 MB...
(It is a few MB when started without loading a page, but with mozilla
initialised).
>
>> http://tkgecko.svn.sourceforge.net/viewvc/tkgecko/tkgecko/src/
>
> Which thread do the GetProxyFor* functions in
> http://tkgecko.svn.sourceforge.net/viewvc/tkgecko/tkgecko/src/TkGecko_Browser.cpp?revision=19&view=markup 
> run on?
I have two threads: One provided by the application that wants to embed
mozilla (actually a Tcl thread), and one thread I create using glib
facilities, where gtk is initialised. Mozilla is initialised in the gtk
thread. All GetProxy functions are also called in the gtk/mozilla
thread, and the pointer is passed & used in the Tcl thread.

Isn't this the correct usage of GetProxy?

Thank you very much for your time in looking this,

George
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Parent Message unknown Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/3/09 1:40 PM, Georgios Petasis wrote:
> Yes, using instructions from
> https://developer.mozilla.org/en/Debugging_memory_leaks.
> But I reach no conclusions...

Well, what was the refcount imbalance on your documents, say?

> I tried to do the following:
>
> /* Create our session history object and tell the navigation object
> * to use it. We need to do this before we create the web browser
> * window... */
> mSessionHistory = do_CreateInstance(NS_SHISTORY_CONTRACTID, &rv);
> mNavigation->SetSessionHistory(mSessionHistory);
> if (NS_FAILED(rv)) return rv;

I believe this should make session history work....

> In the way I call XRE_InitEmbedding, mXulDir = mAppDir, and is the
> parent directory xpcom.so was found.
> Should I use something else?

I don't know the right way to set up a profile, sorry.  Maybe someone
else will.

> I have the feeling that despite the fact that my AddRef() & Release()
> are balanced, each page I load remains alive "somewhere".
> I don't know where though :-)

Right.  That's where those refcount balance trees can sometimes help.
And yes, reading them takes some effort...

> In fact this happens when I call exit, from a thread different than the
> thread mozilla runs. It seems that mozilla
> registers some callbacks that trigger on exit, and these are triggered
> from a different thread?

The module destructors, for example?

> Isn't this the correct usage of GetProxy?

Sounds like it, yes.

-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Georgios Petasis-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

O/H Boris Zbarsky έγραψε:
> On 11/2/09 8:31 PM, Boris Zbarsky wrote:
>>> http://tkgecko.svn.sourceforge.net/viewvc/tkgecko/tkgecko/src/
>
> It might help to carefully trace through the functions you're
> executing. I can't tell from here which they are, but for example
> Browser::GetEncoder leaks |doc|. Browser::SaveDocument leaks |document|.
Can you please suggest what is the correct way to call GetEncoder?
What I currently do, is the following:

I am at the Tcl script level. I call DOM::GetEncoder, which uses
QueueEvent to queue the request "get_encoder" in the gtk/mozilla thread,
which in turn will call Browser::GetEncoder.
Browser::GetEncoder will create & reference an encoder object, and also
create & reference a proxy object.
The proxy object is returned to Tcl, where I call AddRef & Release on
the proxy object.

Am I still leaking |doc|?

The Tcl code that uses it is like this:
set encoder [$dom GetEncoder text/plain 0]
$encoder AddRef
$encoder SetNode $body
set content [$encoder EncodeToString]
$encoder SetNode NULL
$encoder Release

Have I forgot to release anything?

I assume that I have to release only the proxy object (which takes care
also the original object). When I release the encoder from the Tcl
script, it remains referenced only by the Browser object, until the next
GetEncoder. Is it so?

>
> I can't find your QueueEvent implementation, but this code in DOM::DOM:
>
> 39 mBrowser->QueueEvent(&p, "get_document");
> 40 document = p.document;
>
> looks possibly suspect to me, depending on how your get_document is
> impemented.
"get_document" simply calls Browser::GetProxyForDocument.
(http://tkgecko.svn.sourceforge.net/viewvc/tkgecko/tkgecko/src/TkGecko_Browser.cpp?revision=19&view=markup)
The idea is that the Browser class does not play with the reference
counts, and these are done manually (with AddRef/Release) from the Tcl
script level.

Thank you,

George
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Georgios Petasis-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

O/H Boris Zbarsky έγραψε:
> On 11/2/09 8:39 PM, Boris Zbarsky wrote:
>> It might help to carefully trace through the functions you're executing.
>
> Unless its callers are very careful, DOM::GetBody leaks the body.
The caller calls AddRef/Release:

set body [$dom GetBody]
set encoder [$dom GetEncoder text/plain 0]
$body AddRef
$encoder AddRef
$encoder SetNode $body
set content [$encoder EncodeToString]
$encoder SetNode NULL
$body Release
$encoder Release

Thank you,

George




_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Georgios Petasis-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

O/H Boris Zbarsky έγραψε:
> On 11/3/09 1:40 PM, Georgios Petasis wrote:
>> Yes, using instructions from
>> https://developer.mozilla.org/en/Debugging_memory_leaks.
>> But I reach no conclusions...
>
> Well, what was the refcount imbalance on your documents, say?
I am not sure. I got some pointers of leaked objects, and I checked 4-5
of them with make-tree.pl, but all of them
originate from inside xpcom.so or xul.so. None of them seem to originate
from a function I have written.
Exactly what valgrind also reported. Thus, I don't know how to proceed
with mozilla debugging tools.

>
>> I tried to do the following:
>>
>> /* Create our session history object and tell the navigation object
>> * to use it. We need to do this before we create the web browser
>> * window... */
>> mSessionHistory = do_CreateInstance(NS_SHISTORY_CONTRACTID, &rv);
>> mNavigation->SetSessionHistory(mSessionHistory);
>> if (NS_FAILED(rv)) return rv;
>
> I believe this should make session history work....
Strange but it does not :-( And I have no reason why...
At least the behaviour is consistent in bot windows & linux :D

>
>> In the way I call XRE_InitEmbedding, mXulDir = mAppDir, and is the
>> parent directory xpcom.so was found.
>> Should I use something else?
>
> I don't know the right way to set up a profile, sorry. Maybe someone
> else will.
>
>> I have the feeling that despite the fact that my AddRef() & Release()
>> are balanced, each page I load remains alive "somewhere".
>> I don't know where though :-)
>
> Right. That's where those refcount balance trees can sometimes help.
> And yes, reading them takes some effort...
>
>> In fact this happens when I call exit, from a thread different than the
>> thread mozilla runs. It seems that mozilla
>> registers some callbacks that trigger on exit, and these are triggered
>> from a different thread?
>
> The module destructors, for example?
Well, I have no idea :-). Are images freed by a module destructor? (Does
my application load modules since no profile is used?)
>
>> Isn't this the correct usage of GetProxy?
>
> Sounds like it, yes.
>
Thank you very much,

George
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Parent Message unknown Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/3/09 1:53 PM, Georgios Petasis wrote:
>> It might help to carefully trace through the functions you're
>> executing. I can't tell from here which they are, but for example
>> Browser::GetEncoder leaks |doc|. Browser::SaveDocument leaks |document|.
> Can you please suggest what is the correct way to call GetEncoder?

It's not how you call it.  It's what the function does:

  1208   nsIDOMDocument *doc;
  1209   mNavigation->GetDocument(&doc);

That call just incremented the refcount by 1.

  1210   if (doc) doc->AddRef();

And now you've incremented it by 2.

  1211   NS_ConvertASCIItoUTF16 newContentType(formatType);
  1212   rv = encoder->Init(doc, newContentType, encodingFlags);
  1213   if (doc) doc->Release();

And now it's back to only being incremented by 1.  But that 1 is never
released anywhere I see.  I have no idea why you aren't using nsCOMPtr
here; it's designed to prevent just such mistakes.

> Am I still leaking |doc|?

Yes, see above.

> Have I forgot to release anything?

Yes, see above.

> "get_document" simply calls Browser::GetProxyForDocument.

OK, that should be fine.

-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Parent Message unknown Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/3/09 1:56 PM, Georgios Petasis wrote:

>> Unless its callers are very careful, DOM::GetBody leaks the body.
> The caller calls AddRef/Release:
>
> set body [$dom GetBody]
> set encoder [$dom GetEncoder text/plain 0]
> $body AddRef
> $encoder AddRef
> $encoder SetNode $body
> set content [$encoder EncodeToString]
> $encoder SetNode NULL
> $body Release
> $encoder Release

 From GetBody:

    81   nsIDOMHTMLElement *ptr = NULL;
    82   if (document) document->GetBody(&ptr);
    83   return ptr;

The GetBody call calls addref on the body.  If the above shows all the
remaining addrefs and releases (that is, if your C++-to-tcl glue doesn't
have an extra release on the return value of GetBody somewhere), then
you just leaked the body.

-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Parent Message unknown Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/3/09 2:04 PM, Georgios Petasis wrote:
>> Well, what was the refcount imbalance on your documents, say?
> I am not sure. I got some pointers of leaked objects, and I checked 4-5
> of them with make-tree.pl, but all of them
> originate from inside xpcom.so or xul.so.

You need to be running against debug versions of the mozilla libraries
to make progress here, of course...

>> The module destructors, for example?
> Well, I have no idea :-). Are images freed by a module destructor? (Does
> my application load modules since no profile is used?)

If it's showing images, it's loading the image module.  ;)

-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Georgios Petasis-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

O/H Boris Zbarsky έγραψε:

> On 11/3/09 1:53 PM, Georgios Petasis wrote:
>>> It might help to carefully trace through the functions you're
>>> executing. I can't tell from here which they are, but for example
>>> Browser::GetEncoder leaks |doc|. Browser::SaveDocument leaks
>>> |document|.
>> Can you please suggest what is the correct way to call GetEncoder?
>
> It's not how you call it. It's what the function does:
>
> 1208 nsIDOMDocument *doc;
> 1209 mNavigation->GetDocument(&doc);
>
> That call just incremented the refcount by 1.
>
> 1210 if (doc) doc->AddRef();
>
> And now you've incremented it by 2.
>
> 1211 NS_ConvertASCIItoUTF16 newContentType(formatType);
> 1212 rv = encoder->Init(doc, newContentType, encodingFlags);
> 1213 if (doc) doc->Release();
>
> And now it's back to only being incremented by 1. But that 1 is never
> released anywhere I see. I have no idea why you aren't using nsCOMPtr
> here; it's designed to prevent just such mistakes.
Dear Boris,

Thank you very much for the tip. I tried to use nsCOMPtr, but I got
compilation errors (GetDocument didn't accept a nsCOMPtr value), so I
simulated what nsCOMPtr would have done. Maybe a getterAddRef is needed
if I use a nsCOMPtr call?
How would you write such a call?
>
>> Am I still leaking |doc|?
>
> Yes, see above.
To say the truth, I didn't know that GetDocument kept a reference to the
provided doc. Is there a list of methods that behave in a similar way?

Thank you,

George
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Georgios Petasis-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

O/H Boris Zbarsky έγραψε:

> On 11/3/09 1:56 PM, Georgios Petasis wrote:
>>> Unless its callers are very careful, DOM::GetBody leaks the body.
>> The caller calls AddRef/Release:
>>
>> set body [$dom GetBody]
>> set encoder [$dom GetEncoder text/plain 0]
>> $body AddRef
>> $encoder AddRef
>> $encoder SetNode $body
>> set content [$encoder EncodeToString]
>> $encoder SetNode NULL
>> $body Release
>> $encoder Release
>
> From GetBody:
>
> 81 nsIDOMHTMLElement *ptr = NULL;
> 82 if (document) document->GetBody(&ptr);
> 83 return ptr;
>
> The GetBody call calls addref on the body. If the above shows all the
> remaining addrefs and releases (that is, if your C++-to-tcl glue
> doesn't have an extra release on the return value of GetBody
> somewhere), then you just leaked the body.
>
Hm, exactly the same case as nsINavigation::GetDocument I suppose...

George
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Georgios Petasis-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

O/H Boris Zbarsky έγραψε:
> On 11/3/09 2:04 PM, Georgios Petasis wrote:
>>> Well, what was the refcount imbalance on your documents, say?
>> I am not sure. I got some pointers of leaked objects, and I checked 4-5
>> of them with make-tree.pl, but all of them
>> originate from inside xpcom.so or xul.so.
>
> You need to be running against debug versions of the mozilla libraries
> to make progress here, of course...
Yes, I have compiled xulrunner myself, using:

ac_add_options --disable-javaxpcom
ac_add_options --enable-debug
ac_add_options --disable-optimize
ac_add_options --enable-logrefcnt

Thank you,

George
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Parent Message unknown Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/3/09 4:05 PM, Georgios Petasis wrote:
> Thank you very much for the tip. I tried to use nsCOMPtr, but I got
> compilation errors (GetDocument didn't accept a nsCOMPtr value), so I
> simulated what nsCOMPtr would have done. Maybe a getterAddRef is needed
> if I use a nsCOMPtr call?

Yes, exactly.

nsCOMPTr<nsIDOMDocument> doc;
mWebNavigation->GetDocument(getter_AddRefs(doc));

> To say the truth, I didn't know that GetDocument kept a reference to the
> provided doc. Is there a list of methods that behave in a similar way?

All XPCOM methods.  If it's declared in IDL and doesn't have the
[notxpcom] annotation, it behaves this way.  This is well-documented, I
thought.

-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Parent Message unknown Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/3/09 4:07 PM, Georgios Petasis wrote:
> Hm, exactly the same case as nsINavigation::GetDocument I suppose...

Yes.

-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Parent Message unknown Re: Memory usage: 4MB per page?

by Boris Zbarsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/3/09 4:09 PM, Georgios Petasis wrote:
> Yes, I have compiled xulrunner myself, using:
>
> ac_add_options --disable-javaxpcom
> ac_add_options --enable-debug
> ac_add_options --disable-optimize
> ac_add_options --enable-logrefcnt

OK.  You should be able to see the stacks to the unbalanced refcounts
and see what code on your end is triggering them, then.

-Boris
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding

Re: Memory usage: 4MB per page?

by Georgios Petasis-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

O/H Boris Zbarsky έγραψε:

> On 11/3/09 4:09 PM, Georgios Petasis wrote:
>> Yes, I have compiled xulrunner myself, using:
>>
>> ac_add_options --disable-javaxpcom
>> ac_add_options --enable-debug
>> ac_add_options --disable-optimize
>> ac_add_options --enable-logrefcnt
>
> OK. You should be able to see the stacks to the unbalanced refcounts
> and see what code on your end is triggering them, then.
>
> -Boris
> _______________________________________________
> dev-embedding mailing list
> dev-embedding@...
> https://lists.mozilla.org/listinfo/dev-embedding
>
Dear Boris,

Thank you very much for your feedback. I think that I have resolved
almost all of my memory leaks :-)

Regards,

George
_______________________________________________
dev-embedding mailing list
dev-embedding@...
https://lists.mozilla.org/listinfo/dev-embedding