Re: oafd Leak fixes

[Pavel Cisler <pavel eazel com>]

> >
> > You could use the leakchecker in eaze-tools. You could try doing:
> > export LD_PRELOAD=/gnome/lib/libleakcheck.so
> > That way every binary your run with the same env should get leakchecked,
> > including the one you explicitly start and the one that gets launched
> > later.
> >
> > You could also try to link oafd directly with the library, that would
> > take a little bit of hackery though.
> >
> > If you are using memprof or libleakchecker.so, it is best that you build
> > the leakchecked binary with -gdwarf-2 instead of -g. There is a bug in
> > the way gcc generates stabs debugging info that causes the bfd lookup of
> > some symbols to fail. When that happens you see the wrong routines in a
> > stack crawl in the leak output.
> 
> The problem with this approach though is that I would get the leak
> profile for nautilus or whatever else starts up when I start nautilus
> (i.e. all the components) - It'd take quite a while to sift through
> this.

That's why I suggested static linking.

Alternately, you could hack libleakcheck to only turn itself on if you
are running it with a specific executable, oafd in your case. A dirty
but easy way to do this would be to add:

 char app_path[1024];
 int length = readlink("/proc/self/exe", app_path, 1024);
 if (length > 0) {
	app_path[length] = '\0';
	if strstr(app_path, "oafd") == NULL)
		return; 
 }

at the begining of eaze_link_print_leaks.

This would still leakcheck everything but only dump leakcheck output for
oafd. There are more creative/clean ways to do this but this is probably
the easiest.

Pavel