|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
|
|
|
|
|
Re: Memory usage: 4MB per page?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?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?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. 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. 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 |
|
|
|
|
|
Re: Memory usage: 4MB per page?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?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?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.... 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? 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 |
|
|
|
|
|
|
|
|
|
|
|
Re: Memory usage: 4MB per page?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. 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?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. > George _______________________________________________ dev-embedding mailing list dev-embedding@... https://lists.mozilla.org/listinfo/dev-embedding |
|
|
Re: Memory usage: 4MB per page?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 |
|
|
|
|
|
|
|
|
|
|
|
Re: Memory usage: 4MB per page?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 > 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 |
| Free embeddable forum powered by Nabble | Forum Help |