Jay Berkenbilt <[EMAIL PROTECTED]> writes:

> I'm the xerces maintainer for debian.  I haven't looked at the original
> bug yet, but if there's a patch I can apply, I'm willing to do so.  My
> usual approach is to file with upstream and accept it if they do.  Is
> the xerces-c patch posted to the original bug report?  If not, can
> someone post a bug against the appropriate xerces package in debian with
> the patch?

> I have another request to update the xerces27 packages to track more
> closely to upstream development.  I'll check with upstream about it.
> Xerces 3.0 has been right around the corner for ages, and I don't know
> when it's actually going to happen.  Having the debian xerces27 packages
> be more up to date than the most recent official stable distribution is
> probably not such a bad thing at this point.

Hi Jay,

I really didn't think that the Xerces-C patch would have any impact on
stability, and I'm still rather mystified by the results that seem to
indicate that it does, since all it does is reduce the default size of the
memory blocks that Xerces-C allocates.  However, the Shibboleth folks do
strongly recommend patching Xerces-C with that patch since otherwise
Shibboleth consumes quite a bit of memory and application of the patch
shouldn't have any negative effects (it may result in a slight performance
loss for things that really do need large amounts of memory, but most
likely it would make things faster).

I'm sorry to have not told you about it earlier; I haven't had anywhere
near as much time to work on the Shibboleth packaging as I wanted.  (I've
basically uploaded packages that we have been testing internally at
Stanford, but which we haven't been putting a heavy load on, and then I
promptly ran completely out of time due to other projects.)

Anyway, here is the entirety of the modification applied by the Shibboleth
project other than spec file changes and version changes (they released
their version as Xerces-C 2.7.1, which I find really annoying).  I'm happy
to file this as a bug report if you'd prefer.

--- xerces27-2.7.0/xerces-c-src_2_7_0/src/xercesc/dom/impl/DOMDocumentImpl.cpp  
2005-09-07 08:54:57.000000000 -0700
+++ xerces-c-shibboleth/src/xercesc/dom/impl/DOMDocumentImpl.cpp        
2007-06-06 07:51:04.000000000 -0700
@@ -792,10 +792,10 @@
     else return this->fNamePool->getPooledString(src);
 }
 
-static const int kHeapAllocSize = 0x10000;    // The chunk size to allocate 
from the
+static const int kHeapAllocSize = 0x2000;    // The chunk size to allocate 
from the
                                               //   system allocator.
 
-static const size_t kMaxSubAllocationSize = 4096;  // Any request for more 
bytes
+static const size_t kMaxSubAllocationSize = 2048;  // Any request for more 
bytes
                                                    //  than this will be 
handled by
                                                    //  allocating directly 
with system.
 
-- 
Russ Allbery ([EMAIL PROTECTED])               <http://www.eyrie.org/~eagle/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to