On 2/25/07, Caleb Clausen <[EMAIL PROTECTED]> wrote:
> I'm afraid this is one of those really nassty c pointer bugs that is
> difficult to solve because the problem is very far away from the code
> that actually fails. Perhaps this is a situation that calls for
> valgrind, or something like that? Some kind of library or tool for
> debugging memory allocation problems could help prove that the code
> really really does operate the way the programmers think it should. I've
> played with using valgrind to debug ferret before; I think it was in
> connection with another bug. I couldn't get very far in part because
> ruby pre-allocates pools of objects which it manages itself. That
> behavior would have to be disabled to permit valgrind to do its magic.
I use valgrind all the time. It is a godsend. Unfortunately it doesn't
work too well with Ruby as ruby's garbage collector raises so many
errors. I plan to make Ferret 2.0 scriptable so that more people can
get involved with Ferret development and I would have liked to have
used Ruby except for this problem with valgrind. Lua looks like a
better alternative and much lighter weight. Anyway, it is a long way
in the future so probably not worth mentioning.
> Sticking lots of assertions into all the code that gets executed by the
> failing test script is another thing to try, I guess. That really more
> of a shot-gun approach... I'm sorry I can't offer anything but these
> really generic suggestions.
This is the method I end up having to use when debugging Ferret's Ruby
bindings. Anyway, I probably should have posted it here but I did end
up solving the problem;
http://www.ruby-forum.com/topic/98709#210591
So term-vectors will be fine in the next release without introducing
any memory leaks.
Cheers,
Dave
--
Dave Balmain
http://www.davebalmain.com/
_______________________________________________
Ferret-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ferret-talk
