Re: Galeon 1.2.5 to 1.3.19 conveersion a couple of questions

On Sun, 6 Feb 2005, Karsten M. Self wrote:
> on Sun, Feb 06, 2005 at 11:10:05AM +0000, Crispin Flowerday ([email protected]) wrote:
>> On Sat, 2005-02-05 at 21:19 -0800, Karsten M. Self wrote:
> 
>> >   - Better memory performance.  1.2.x seemed to leak faster than 1.3,
>> >     though 1.3.x is still leaking, and pretty badly at 1.3.19-1.
>> 
>> If anyone can track down these memory leaks, then please tell us, I have
>> tried valgrind, but couldn't see anything major.
> 
> Could you point to some tips for how end-users could do this, and what a
> useful format for a report would be?

Compile galeon (and mozilla?) with debugging symbols (i.e. with -g among
CFLAGS, without -s among LDFLAGS).

Run galeon under valgrind like this:

valgrind --log-file=galeon --trace-children=yes --tool=memcheck --leak-check=yes galeon

and zip up the resulting galeon.pid* files.


> What's the performance impact of valgrind?  Presumably you're running
> Galeon from it, right?

Yes. Since it has to dynamically translate the binary into a sort of
semi-SPARC-like assembler, analyze and instrument it, and then execute
that, its performance impact is significant: valground programs will run
about ten times slower than non-valground programs, and will use almost
exactly nine times as much memory (because every bit of RAM the program
accessed has an initialized-flag attached to it, and every byte has a
leaked flag).


What might be more efficient than this, at least under GNU/Linux, is to
use the leak detector built into the GNU libc.

To use it, modify main() in galeon-main.c so that it calls mtrace()
as the first thing it does.

Then run galeon with the environment variable MALLOC_TRACE set to point
to some nonexistent file in a place you can write to, viz

MALLOC_TRACE=/tmp/galeon-trace galeon

Run the mtrace program on that file: its arguments are the name of the
galeon binary, and the trace file, viz

mtrace /usr/local/bin/galeon /tmp/galeon-trace

and you'll get output that says where allocations were made but not
freed.


See the node in the GNU libc manual entitled `Allocation Debugging'.

>> I'm not quite sure what you mean be this, in 1.3.19 you can accept
>> cookies always, always ask, always ask except for session cookies, or
>> force all cookies to be session cookies, what more do you want ?
[...]
> ...with an option being "allow cookie for session only".  It effectively
> converts a persistant cookie to a session cookie.

That's, um, the `Cookies expire at the end of the session' option. :)

> Adding the ability to query DNSBLs for specific actions (cookies, site
> loading, image loading) is another feature I see becoming more prevalent
> over the next year or so.

URIBLs seem more useful things to query: they're *meant* to track
malicious URIs/URLs, after all.

-- 
`anybody who quotes Russ [Allbery] can be forgiven almost anything!'
                                                  -- Stephen J. Turnbull


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl