Hi folks, have any of you tried using Insure++ on AOLserver? http://www.parasoft.com/products/insure/
I tried it with an evaluation license recently. Supposedly it is "better" than Purify because it instruments stuff at the "source code level" while Purify only instruments stuff at link time. That's according to the folks who make Insure++ of course - I don't actually know how either tool really works. But I do know I couldn't get Insure++ to work right with AOLserver. Basically, I instrumented all of 3.3+ad13 with Insure++ (on Solaris - SunOS 5.8), started it up, waited - Insure makes AOLserver EXTREMELY slow - and kept waiting. But no matter how many times I'd hit a page, nothing would happen. Basically, it looked like one thread was active and doing stuff, but that the server would NEVER switch to run any other threads! The un-instrumented version worked normally, of course. One of the Insure tech. support people said to try running pstack, so I did and sent that to them, but I dunno what, if anything, they might come up with. I've tried Rational's Purify before, which seemed to work well and give useful results with AOLserver and gcc on Solaris. http://www.rational.com/products/purify_unix/index.jsp Unfortunatley, Purify is down for me right now too, due to some sort of incompatibility with a recent Solaris OS patch - Rational says they should have a fix within a week or so. Naturally, my sudden resurgence of interest in tools like Purify and Insure++ is due to my discovery of yet more stack corruption issues in my own buggy loadable module code. But the symptoms here are a little different than I've seen before. I'm not getting any segfaults. I run a Tcl command which runs C code which gets some data and sticks it into an ns_set, and then some some other Tcl code takes the data out of the ns_set, but at this point the data is corrupt. For a given input the corruption seems to be consistant, and the corrupt data seems to consists of some string of Tcl code from elsewhere in my server's memory. Do these clues suggest to you any clever way by which I could track down this data corruption problem? Oh, and I never did get GNU Checker to compile at all, and Electric Fence didn't work right for me back when I tried it with AOLserver (it would immediately segfault on server startup somewhere within the EF code itself), so at the moment I am completely SOL as far as malloc debugging type tools go. http://www.gnu.org/directory/checker.html http://perens.com/FreeSoftware/ -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com
