Off topic, but somewhat related... ;-) I know Tcl can't be used in all cases, and that sometimes you have to write C code to accomplish what's needed, but hopefully everyone can see the advantages of keeping as much code as possible up at the Tcl level.
I think we should continue to really look at the situations where folks are writing C code, and try to identify the reasons:
1. Performance related? The performance benefits of having to write the code in C out way the downsides of having to deal with things like memory allocation/freeing.
2. The Tcl API's don't exist which would allow you to do what you are trying to do.
I think what I'm wondering is whether or not there still might be some more opportunities to expose additional C API's and data structures in Tcl that would allow folks to more easily do what they are trying to accomplish in Tcl, thus hopefully avoiding spending a lot of time with programs such as Purify when working on the AOLserver platform. ;-)
That said, we do need to try make things easier for folks needing to Purify their modules with AOLserver. ;-) Time for my morning coffee! :-)
- n
[EMAIL PROTECTED] wrote:
On Wed, Aug 11, 2004 at 09:26:20AM +0200, Zoran Vasiljevic wrote:
When you launch the AOLserver in foreground, run couple of requests and then ctrl-c it, purify should report all memory that has been allocated and not freed. The list may be long, since AS does not make a very clean shutdown memory-wise, but you may spot your "leaks" among those. Have you tried that?
Aha, now I am definitely getting more useful results from Purify. (Perhaps building Tcl without the '-DUSE_THREAD_ALLOC=1' as Elizabeth suggested made the difference, or maybe I was simply driving Purify incorrectly before.) When AOLserver shuts down, it spits out an ENORMOUS list of "leaked" and "potentially leaked" bytes.
There appears to be a definite problem with false positive leaks here... What sort of changes to AOLserver would it take to make those go away? Would doing so be impractical?
Interestingly, my total number of "potentially leaked" bytes grows with the number of requests, while the "leaked" bytes total does not. Since my memory wastage is nearly perfectly linear with number of requests, clearly if Purify is showing my bug at all, it must be hiding in the "potentially leaked" bin somewhere. (Now to track it down.)
-- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
-- AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
-- AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
