Raphael Manfredi said: > I tested fuzzy matching through dmalloc and saw the reason for the mem > corruption.
Yeah I tested the patch last night that defered the adding of the defered dmesh entries to the end. Works fine, sorry I missed it. > That said, I will switch dmesh fuzzy matching to FALSE by default on the > next version, because it is an O(m*n) alogorithm, and fuzzy matching is > really INNEFFICIENT (allocates memory to perform its operation, and it's > not an optimal algorithm either). Are you talking about the fuzzy.c algorithm itself or the dmesh code? w.r.t the dmesh code there are a few optimisations that can be made (for example when comparing against existing dmesh entries you can take your descision to add as soon as the threshold is reached, and the threshold can probably be lower). > Also, the algorithm dumps perfectly valid locations. This is a deliberate design descision to be conservative (certianly when no exsiting non-urn altlocs exist). Trouble is you get files with long names that vary only slightly but are however unmatched: e.g. star trek enterprise season 2 the catwalk.mpeg star trek enterprise season 2 the communicator.mpeg They stand a better chance of getting added once there are a few non-urn altlocs already in the dmesh. Also people that return just one non-urn alotloc are probably right. > The only remaining leaks seem to be in the atoms. Those I cannot find > with dmalloc and will need to run valgrind to find them. One of the reasons I got rid of the atom_str_get when adding the defred locations was because of strangeness that ensued (hence the g_strdup). However the strangeness could of been a result of the bug you found. Are you regularly running dmalloc and valgrind on gtkg? Given the amount of dynamic allocation going on in gtkg I wouldn't be supprised to find some other leaks. > - (2003.02.05 - RAM) > * Fixed dmesh fuzzy matching memory corruption. > * Send PUSH messages at max TTL value, not my TTL in case it needs > re-routing. * Added missing memory cleanup to shutdown calls, > preventing leak detection. > > Raphael -- Alex http://www.bennee.com/~alex/ ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
