2011/10/2 Lluís Batlle i Rossell <virik...@gmail.com> > As for leaks, the memory leak about annotate was at every checkin > traversed, > though. Does the change in that branch look fine for a merge?
Just to be clear - that's not the only leak in fossil. There many, many places where resources are left to be cleaned up by exit(). Every time you call cgi_set_content_type() or cgi_set_parameter() (e.g. to initialize the state for a new request), it's leaking (twice in cgi_set_parameter()). Fixing these requires not only calls to free(), but the infrastructure for tracking the memory which eventually needs to be freed. Maybe this sounds sacrilegious, but i currently think the easiest/best way to "fix" that type of thing (which would be needed for any library form of fossil) would be to re-implement it as libfossil2, building it as a library from the ground up and porting over the existing functionality one step at a time. It would _not_ be a 1-to-1 copy because all of the fossil features are currently monolithic, using shared static state and whatnot to communicate between internal routines (some of which would need to be made into lib-level routines). -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
