David Huynh wrote:
[snip]
>> I'm pretty sure I've committed all the four sins... I'll go to my room
>> and recite some RFC ten times now.
May I suggest IPv4, IPv6, HTTP 1.1, WebDAV, DeltaV and IMAP4? ;-)
No worries, dude, your work is impressive enough and coming from the
haystack world, I'm not surprised memory usage is not a big concern of
yours ;-)
sorry, I had to say it :-)
>>>> Wish me luck.
>>>>
>
>> Good luck, Stefano! Sorry I can't be there to help you out! :-(
Just a
>> thought, maybe you can use Greasemonkey to automate creating and
>> switching between tabs, which might help with reproducing the leak as
>> you add the PB code back bit by bit?...
I had the exact same idea.
In fact, I just committed to svn a new extension that I called "firefox
tracer" (deerpark ready) that is pretty much the event-handling
mechanism of greasemonkey (but without the rest) along with the simplest
of our XPCOM+JavaScript+Java components (nsInfoUtil).
[find it at
http://simile.mit.edu/repository/tools/firefor-tracer/]
Everything is traced to every little piece of XPCOM detail and dumped on
the console (not the javascript console! the stdout console!, makes it
much easier to interact with command line tools like grep/wc/sed and the
like.
I also found a way to reload both xul *and* xpcom components without
having to restart the browser, my productivity increased 20 times!! :-)
[more on this later]
I gave up on instrumenting firefox natively, because both --enable-leaky
and --enable-trace-malloc trigger errors during compilation, I think
these tools (being something like 6/7 years old!) are not really up to
speed with firefox (and it's a shame, if you ask me, but I don't know
enough malloc internals to submit a patch to them, so I guess I can't
complain than much).
I also gave up because compiling deerpark (even without a bunch of
stuff) takes around 1 hour on my laptop, not pretty to have a 1 hour
try-fail cycle :-/
So I'm off instrumenting the heck out of anything that I can get my
hands on from the javascript/xul/xpconnect layer.... and see if I can
reproduce leaks in such a smaller environment (smaller but still
exhibiting the entire memory management complexity of piggy bank).
But again, after the weekend :-)
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Sat Aug 06 2005 - 02:38:34 EDT