I think I found it. It's a scary thing, a problem in the
MacOSPlatformUtils.cpp
file. I had to go back to my backup to make sure it wasn't my fault.
On the Mac, there's no native preemptive multitasking (at least not yet, there
will be with Carbon, which I guess is in testing). You can do cooperative
threading with the "thread manager", and you can do SMP and true
preemptive multitasking with the MP API library, which was originally
developed I think by DayStar for use with their multiprocessor CPU upgrade
cards.
There's severe limitations to what you can do with the MP library (you can't
call any OS or toolbox functions at all from a preemptive task), and there are
also some limitations to the thread manager, which is more commonly used.
The fellow who originally did the mac port of the Xerces library required the
use of the MP library, so I link against it and had to give it to my client for
her
demo - but it's not something that I'll require in the final code I provide
back to
the Apache XML project, most likely I'll surround it all with #ifdefs.
But interestingly, in atomicIncrement and atomicDecrement I guess he
couldn't get it working right because all the MP library stuff marking a
critical
section and so on was commented off, and this is what I found:
XMLPlatformUtils::atomicDecrement( int &location ) // or whatever
{
int result = location--;
return result;
}
so this returns what (in the case of our DOMString) the reference count was
to start with, so the DOMStringHandle object never gets reffed down to zero -
because the containing object is deleted; I suppose if you accidentally
deleted it an extra time you'd get rid of the extra reference.
So I changed this to:
int result = --location;
return result;
interestingly, Spotlight used to take a fairly long time and create a 700k log
file full of stack traces of the places where the leaked memory was allocated.
But after making this change, it's taking like 15 minutes to do its log and I
had
to increase its memory allocation (one of the little gremlins of mac
architecture - fixed memory partitions) to get it to run without crapping out.
It's still thinking but the log is only at 300k so far.
I know there are other leaks that have nothing to do with Xerces in my code,
so that would explain the 300k. What is interesting is that Spotlight seems to
be having a very laborious time following the chain of events of memory
allocation!
During Spotlight's development, I beta tested it on a large image editing
product (Live Picture) that used a lot of custom memory allocators, and
managed to crash spotlight doing some kind of custom allocation that the
authors of spotlight were not aware that you could even do in C++. The next
build fixed the bug though and I was able to profitably use Spotlight to debug
live picture.
Even if you use some other platform, it would be worth getting a Mac and
Codewarrior just to be able to use Spotlight on your code. It's pretty amazing
to run it on some mature commercial product that the publisher thinks is
reasonably bug-free... but, on the other hand, if you use it every couple days
during development from the start, you can ship a product that you can be
pretty confident has no pointer errors or memory leaks at all.
http://www.onyx-tech.com
For windows there is boundschecker; I haven't tried it but was irritated it was
compiler-specific and didn't support codewarrior. It does support visual c++
and borland c++ I think.
Mike Crawford
GoingWare - Expert Software Development and Consulting
http://www.goingware.com
[EMAIL PROTECTED]
Michael D. Crawford
GoingWare - Expert Software Development and Consulting
http://www.goingware.com
[EMAIL PROTECTED]
Tilting at Windmills for a Better Tomorrow
