You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Nikita Sawant <ni...@netscape.com> on 2000/10/17 05:13:49 UTC
Problem in a Multithread application using Xerces C++ Parser
Hi,
We are using the Xerces C++ parser in our multithreaded application. In
this application we have multiple threads that invoke the Xerces parser
(DOM as well as SAX). At some point during execution we get a signal
SIGSEGV, and our process quits.
Here is a listing of the stack trace:
.
DOMParser::~DOMParser(0xec3044e0, 0x2, 0xee7c0560, 0x5f4974,
0x6e36c0,0xec3044e0)
XMLScanner::~XMLScanner(0x6e45c0, 0x3, 0xee7bb204, 0xee7bb204,
0x6e36c8, 0x43)
ElemStack::~ElemStack(0x10, 0x2, 0x4, 0x6e45d8, 0x2002c, 0x6e4630)
XMLStringPool::~XMLStringPool(this = ???, delete = ???) (optimized)
RefHashTableOf::~RefHashTableOf(this = ???, delete = ???) (optimized)
RefHashTableOf::removeAll(this = ???) (optimized)
XMLStringPool::PoolElem::~PoolElem(this = ???, delete = ???)
(optimized)
.
.
It apparently fails in the destructor.
Our build / run time platform is Solaris Sparc 2.6
While building the Xerces library we ** do not use ** the lpthread
library as we had problems when
integrating with the Mozilla Transformiix XSLT processor.
We do use the "-mt" compiler switch and the -D_REENTRANT flag in the
'compile' options.
We also have the required patch (Patch ID #105591) for multi-threaded
applications
installed..
Is there a fix to this problem ?? We would appreciate any help /
solution for this.
Thanks,
Nikita
Re: Problem in a Multithread application using Xerces C++ Parser
Posted by Arundhati Bhowmick <bh...@jtcsv.com>.
Try using the same multi-threading switches as xerces (i.e., -mt, REENTRANT define). You do not
need the _PTHREAD flag when using REENTRANT.
It'd also be good to check if your machine has all the latest patch installed for the compiler.
And if there is any limitation on your machine for the number of threads that it can create.
Arundhati
Nikita Sawant wrote:
> Hi Andy,
>
> I tried to run ThreadTest in the samples directory:
>
> Using the following command:
>
> ThreadTest -dom -threads 70 -time 10 -dump -verbose
> ../samples/data/personal.xml
>
> I varied the number of threads to create..
> It works fine for 60 threads, but fails when the number of threads is
> increased to 65 +.
>
> I am now using the -D_REENTRANT and the -D_PTHREADS compiler flags and
> am linking to the pthread library. The compiler I use is CC.
>
> Here is a listing of the error message:
>
> Thread #48: starting file ../samples/data/personal.xml
> Thread #35: starting file ../samples/data/personal.xml
> Thread #48: starting file ../samples/data/personal.xml
> Thread #29: starting file ../samples/data/personal.xml
> ***** Fatal error during parsing: ../samples/data/personal.xml
> Exception message is: The primary document entity could not be opened.
> Id=/u/nikita/threadXerces/actrasrc/modules/vendor/apache/xerces-c/samples/data/personal.xml
>
> Thread 29: Parse Check sum error on file "../samples/data/personal.xml".
> Expected 44ba9a06, got 0
> Retry checksum is 0
> Begin DOMPrint ...
> End DOMPrint
>
> My platform is :
> SunOS 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-5_10
>
> Any idea whats going wrong ??
>
> Thanks,
> Nikita
>
> Andy Heninger wrote:
>
> > "Rick Byers" <ri...@quack.com> notes
> >
> > > This may not be relevant, but this looks frighteningly similar to the
> > > bug I described in a message to this list on Sept 29 ...
> >
> > And, just in case you wondered, that problem with the DOMStringHandle
> > pool is still very much on my list of things to take care of.
> >
> > XMLStringPools are a different beast, in that they are not global,
> > but each parser has a unique one that belongs to it.
> >
> > Nikita, to make sure that you are not being bit by the bug that
> > Rick found, if you are using the DOM, create a DOMString somewhere
> > early on, and keep it around for the duration of your run. If
> > this makes a difference, that's it.
> >
> > Also, you might try rebuilding and running the threadtest sample
> > program on your system. If there's some other library or compiler
> > problem, this may show it up. (Solaris is the only platform
> > where we've hit up against multithreading bugs in the system)
> > Threadtest has a bunch of options - number of threads, SAX or DOM,
> > validating or not, reuse parsers or not, choice of list of files
> > to parse. Try a combination that approximately matches what your
> > application is doing.
> >
> > Andy Heninger
> > IBM XML Technology Group, Cupertino, CA
> > heninger@us.ibm.com
> >
> > ----- Original Message -----
> > From: "Rick Byers" <ri...@quack.com>
> > To: <xe...@xml.apache.org>
> > Sent: Wednesday, October 18, 2000 10:18 AM
> > Subject: Re: Problem in a Multithread application using Xerces C++ Parser
> >
> > > This may not be relevant, but this looks frighteningly similar to the
> > > bug I described in a message to this list on Sept 29 titled "Bug in
> > > DOMStringHandle::operator delete() causes crash". Try creating an
> > > XMLString (or maybe a DOMString) that lives for the life of your
> > > program.
> > >
> > > In my case, heavy multi-threaded use would (possibly after many hours)
> > > cause a similar crash because the DOMStringHandle pool was being
> > > reclaimed (which is only supposed to happen at Terminate time) at the
> > > same time as a new DOMStringHandle was being created. I haven't checked
> > > to see if the XMLStringPool uses the same faulty algorithm as the
> > > DOMStringHandle pool, but it wouldn't surprise me. I patched the code
> > > to fix it, but I don't believe anyone has integrated an official fix
> > > yet.
> > >
> > > Rick
> > >
> > > Nikita Sawant wrote:
> > > >
> > > > Hi,
> > > >
> > > > We are using the Xerces C++ parser in our multithreaded application.
> > In
> > > > this application we have multiple threads that invoke the Xerces
> > parser
> > > > (DOM as well as SAX). At some point during execution we get a signal
> > > > SIGSEGV, and our process quits.
> > > >
> > > > Here is a listing of the stack trace:
> > > > .
> > > > DOMParser::~DOMParser(0xec3044e0, 0x2, 0xee7c0560, 0x5f4974,
> > > > 0x6e36c0,0xec3044e0)
> > > > XMLScanner::~XMLScanner(0x6e45c0, 0x3, 0xee7bb204, 0xee7bb204,
> > > > 0x6e36c8, 0x43)
> > > > ElemStack::~ElemStack(0x10, 0x2, 0x4, 0x6e45d8, 0x2002c, 0x6e4630)
> > > > XMLStringPool::~XMLStringPool(this = ???, delete = ???) (optimized)
> > > > RefHashTableOf::~RefHashTableOf(this = ???, delete = ???) (optimized)
> > > > RefHashTableOf::removeAll(this = ???) (optimized)
> > > > XMLStringPool::PoolElem::~PoolElem(this = ???, delete = ???)
> > > > (optimized)
> > > > .
> > > > .
> > > >
> > > > It apparently fails in the destructor.
> > > >
> > > > Our build / run time platform is Solaris Sparc 2.6
> > > > While building the Xerces library we ** do not use ** the lpthread
> > > > library as we had problems when
> > > > integrating with the Mozilla Transformiix XSLT processor.
> > > > We do use the "-mt" compiler switch and the -D_REENTRANT flag in the
> > > > 'compile' options.
> > > > We also have the required patch (Patch ID #105591) for
> > multi-threaded
> > > > applications
> > > > installed..
> > > >
> > > > Is there a fix to this problem ?? We would appreciate any help /
> > > > solution for this.
> > > >
> > > > Thanks,
> > > > Nikita
> > > >
> > >
> > ------------------------------------------------------------------------
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
> ------------------------------------------------------------------------
Re: Problem in a Multithread application using Xerces C++ Parser
Posted by Andy Heninger <an...@jtcsv.com>.
You've probably hit up against the maximum number of
open files allowed by the OS, although the limit
is usually set a bit higher than you're seeing. All the
UNIXes have a hard limit here; Windows doesn't.
Use the -mem option of threadtest to get around this problem.
I added it for exactly this reason. Each input file will
be read into memory exactly once at the start-up of
threadtest, and then each of the worker threads will
parse from that buffer rather than opening the file
themselves.
Most machines will run into the thousands of threads before
things start going bad, and the problem is usually that
the machine gets so sluggish that you can't stand it.
I usually run threadtest with no time option (run forever,
until you manually kill it), no -verbose option, and no
-dump option. -dump was put in to help debug a specific
problem, but is not of much general use. The default non-
verbose output of a single character per second lets you
know that the program is alive and that all threads are
making progress.
Andy Heninger
IBM XML Technology Group, Cupertino, CA
heninger@us.ibm.com
From: "Nikita Sawant" <ni...@netscape.com>
> I tried to run ThreadTest in the samples directory:
>
> Using the following command:
>
> ThreadTest -dom -threads 70 -time 10 -dump -verbose
> ../samples/data/personal.xml
>
> I varied the number of threads to create..
> It works fine for 60 threads, but fails when the number of threads is
> increased to 65 +.
>
> I am now using the -D_REENTRANT and the -D_PTHREADS compiler flags and
> am linking to the pthread library. The compiler I use is CC.
>
> Here is a listing of the error message:
>
> Thread #48: starting file ../samples/data/personal.xml
> Thread #35: starting file ../samples/data/personal.xml
> Thread #48: starting file ../samples/data/personal.xml
> Thread #29: starting file ../samples/data/personal.xml
> ***** Fatal error during parsing: ../samples/data/personal.xml
> Exception message is: The primary document entity could not be opened.
>
Id=/u/nikita/threadXerces/actrasrc/modules/vendor/apache/xerces-c/samples/
data/personal.xml
>
> Thread 29: Parse Check sum error on file
"../samples/data/personal.xml".
> Expected 44ba9a06, got 0
> Retry checksum is 0
> Begin DOMPrint ...
> End DOMPrint
>
> My platform is :
> SunOS 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-5_10
>
> Any idea whats going wrong ??
>
> Thanks,
> Nikita
>
> Andy Heninger wrote:
Re: Problem in a Multithread application using Xerces C++ Parser
Posted by Nikita Sawant <ni...@netscape.com>.
Hi Andy,
I tried to run ThreadTest in the samples directory:
Using the following command:
ThreadTest -dom -threads 70 -time 10 -dump -verbose
../samples/data/personal.xml
I varied the number of threads to create..
It works fine for 60 threads, but fails when the number of threads is
increased to 65 +.
I am now using the -D_REENTRANT and the -D_PTHREADS compiler flags and
am linking to the pthread library. The compiler I use is CC.
Here is a listing of the error message:
Thread #48: starting file ../samples/data/personal.xml
Thread #35: starting file ../samples/data/personal.xml
Thread #48: starting file ../samples/data/personal.xml
Thread #29: starting file ../samples/data/personal.xml
***** Fatal error during parsing: ../samples/data/personal.xml
Exception message is: The primary document entity could not be opened.
Id=/u/nikita/threadXerces/actrasrc/modules/vendor/apache/xerces-c/samples/data/personal.xml
Thread 29: Parse Check sum error on file "../samples/data/personal.xml".
Expected 44ba9a06, got 0
Retry checksum is 0
Begin DOMPrint ...
End DOMPrint
My platform is :
SunOS 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-5_10
Any idea whats going wrong ??
Thanks,
Nikita
Andy Heninger wrote:
> "Rick Byers" <ri...@quack.com> notes
>
> > This may not be relevant, but this looks frighteningly similar to the
> > bug I described in a message to this list on Sept 29 ...
>
> And, just in case you wondered, that problem with the DOMStringHandle
> pool is still very much on my list of things to take care of.
>
> XMLStringPools are a different beast, in that they are not global,
> but each parser has a unique one that belongs to it.
>
> Nikita, to make sure that you are not being bit by the bug that
> Rick found, if you are using the DOM, create a DOMString somewhere
> early on, and keep it around for the duration of your run. If
> this makes a difference, that's it.
>
> Also, you might try rebuilding and running the threadtest sample
> program on your system. If there's some other library or compiler
> problem, this may show it up. (Solaris is the only platform
> where we've hit up against multithreading bugs in the system)
> Threadtest has a bunch of options - number of threads, SAX or DOM,
> validating or not, reuse parsers or not, choice of list of files
> to parse. Try a combination that approximately matches what your
> application is doing.
>
> Andy Heninger
> IBM XML Technology Group, Cupertino, CA
> heninger@us.ibm.com
>
> ----- Original Message -----
> From: "Rick Byers" <ri...@quack.com>
> To: <xe...@xml.apache.org>
> Sent: Wednesday, October 18, 2000 10:18 AM
> Subject: Re: Problem in a Multithread application using Xerces C++ Parser
>
> > This may not be relevant, but this looks frighteningly similar to the
> > bug I described in a message to this list on Sept 29 titled "Bug in
> > DOMStringHandle::operator delete() causes crash". Try creating an
> > XMLString (or maybe a DOMString) that lives for the life of your
> > program.
> >
> > In my case, heavy multi-threaded use would (possibly after many hours)
> > cause a similar crash because the DOMStringHandle pool was being
> > reclaimed (which is only supposed to happen at Terminate time) at the
> > same time as a new DOMStringHandle was being created. I haven't checked
> > to see if the XMLStringPool uses the same faulty algorithm as the
> > DOMStringHandle pool, but it wouldn't surprise me. I patched the code
> > to fix it, but I don't believe anyone has integrated an official fix
> > yet.
> >
> > Rick
> >
> > Nikita Sawant wrote:
> > >
> > > Hi,
> > >
> > > We are using the Xerces C++ parser in our multithreaded application.
> In
> > > this application we have multiple threads that invoke the Xerces
> parser
> > > (DOM as well as SAX). At some point during execution we get a signal
> > > SIGSEGV, and our process quits.
> > >
> > > Here is a listing of the stack trace:
> > > .
> > > DOMParser::~DOMParser(0xec3044e0, 0x2, 0xee7c0560, 0x5f4974,
> > > 0x6e36c0,0xec3044e0)
> > > XMLScanner::~XMLScanner(0x6e45c0, 0x3, 0xee7bb204, 0xee7bb204,
> > > 0x6e36c8, 0x43)
> > > ElemStack::~ElemStack(0x10, 0x2, 0x4, 0x6e45d8, 0x2002c, 0x6e4630)
> > > XMLStringPool::~XMLStringPool(this = ???, delete = ???) (optimized)
> > > RefHashTableOf::~RefHashTableOf(this = ???, delete = ???) (optimized)
> > > RefHashTableOf::removeAll(this = ???) (optimized)
> > > XMLStringPool::PoolElem::~PoolElem(this = ???, delete = ???)
> > > (optimized)
> > > .
> > > .
> > >
> > > It apparently fails in the destructor.
> > >
> > > Our build / run time platform is Solaris Sparc 2.6
> > > While building the Xerces library we ** do not use ** the lpthread
> > > library as we had problems when
> > > integrating with the Mozilla Transformiix XSLT processor.
> > > We do use the "-mt" compiler switch and the -D_REENTRANT flag in the
> > > 'compile' options.
> > > We also have the required patch (Patch ID #105591) for
> multi-threaded
> > > applications
> > > installed..
> > >
> > > Is there a fix to this problem ?? We would appreciate any help /
> > > solution for this.
> > >
> > > Thanks,
> > > Nikita
> > >
> >
> ------------------------------------------------------------------------
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Problem in a Multithread application using Xerces C++ Parser
Posted by Andy Heninger <an...@jtcsv.com>.
"Rick Byers" <ri...@quack.com> notes
> This may not be relevant, but this looks frighteningly similar to the
> bug I described in a message to this list on Sept 29 ...
And, just in case you wondered, that problem with the DOMStringHandle
pool is still very much on my list of things to take care of.
XMLStringPools are a different beast, in that they are not global,
but each parser has a unique one that belongs to it.
Nikita, to make sure that you are not being bit by the bug that
Rick found, if you are using the DOM, create a DOMString somewhere
early on, and keep it around for the duration of your run. If
this makes a difference, that's it.
Also, you might try rebuilding and running the threadtest sample
program on your system. If there's some other library or compiler
problem, this may show it up. (Solaris is the only platform
where we've hit up against multithreading bugs in the system)
Threadtest has a bunch of options - number of threads, SAX or DOM,
validating or not, reuse parsers or not, choice of list of files
to parse. Try a combination that approximately matches what your
application is doing.
Andy Heninger
IBM XML Technology Group, Cupertino, CA
heninger@us.ibm.com
----- Original Message -----
From: "Rick Byers" <ri...@quack.com>
To: <xe...@xml.apache.org>
Sent: Wednesday, October 18, 2000 10:18 AM
Subject: Re: Problem in a Multithread application using Xerces C++ Parser
> This may not be relevant, but this looks frighteningly similar to the
> bug I described in a message to this list on Sept 29 titled "Bug in
> DOMStringHandle::operator delete() causes crash". Try creating an
> XMLString (or maybe a DOMString) that lives for the life of your
> program.
>
> In my case, heavy multi-threaded use would (possibly after many hours)
> cause a similar crash because the DOMStringHandle pool was being
> reclaimed (which is only supposed to happen at Terminate time) at the
> same time as a new DOMStringHandle was being created. I haven't checked
> to see if the XMLStringPool uses the same faulty algorithm as the
> DOMStringHandle pool, but it wouldn't surprise me. I patched the code
> to fix it, but I don't believe anyone has integrated an official fix
> yet.
>
> Rick
>
> Nikita Sawant wrote:
> >
> > Hi,
> >
> > We are using the Xerces C++ parser in our multithreaded application.
In
> > this application we have multiple threads that invoke the Xerces
parser
> > (DOM as well as SAX). At some point during execution we get a signal
> > SIGSEGV, and our process quits.
> >
> > Here is a listing of the stack trace:
> > .
> > DOMParser::~DOMParser(0xec3044e0, 0x2, 0xee7c0560, 0x5f4974,
> > 0x6e36c0,0xec3044e0)
> > XMLScanner::~XMLScanner(0x6e45c0, 0x3, 0xee7bb204, 0xee7bb204,
> > 0x6e36c8, 0x43)
> > ElemStack::~ElemStack(0x10, 0x2, 0x4, 0x6e45d8, 0x2002c, 0x6e4630)
> > XMLStringPool::~XMLStringPool(this = ???, delete = ???) (optimized)
> > RefHashTableOf::~RefHashTableOf(this = ???, delete = ???) (optimized)
> > RefHashTableOf::removeAll(this = ???) (optimized)
> > XMLStringPool::PoolElem::~PoolElem(this = ???, delete = ???)
> > (optimized)
> > .
> > .
> >
> > It apparently fails in the destructor.
> >
> > Our build / run time platform is Solaris Sparc 2.6
> > While building the Xerces library we ** do not use ** the lpthread
> > library as we had problems when
> > integrating with the Mozilla Transformiix XSLT processor.
> > We do use the "-mt" compiler switch and the -D_REENTRANT flag in the
> > 'compile' options.
> > We also have the required patch (Patch ID #105591) for
multi-threaded
> > applications
> > installed..
> >
> > Is there a fix to this problem ?? We would appreciate any help /
> > solution for this.
> >
> > Thanks,
> > Nikita
> >
>
------------------------------------------------------------------------
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
Re: Problem in a Multithread application using Xerces C++ Parser
Posted by Rick Byers <ri...@quack.com>.
This may not be relevant, but this looks frighteningly similar to the
bug I described in a message to this list on Sept 29 titled "Bug in
DOMStringHandle::operator delete() causes crash". Try creating an
XMLString (or maybe a DOMString) that lives for the life of your
program.
In my case, heavy multi-threaded use would (possibly after many hours)
cause a similar crash because the DOMStringHandle pool was being
reclaimed (which is only supposed to happen at Terminate time) at the
same time as a new DOMStringHandle was being created. I haven't checked
to see if the XMLStringPool uses the same faulty algorithm as the
DOMStringHandle pool, but it wouldn't surprise me. I patched the code
to fix it, but I don't believe anyone has integrated an official fix
yet.
Rick
Nikita Sawant wrote:
>
> Hi,
>
> We are using the Xerces C++ parser in our multithreaded application. In
> this application we have multiple threads that invoke the Xerces parser
> (DOM as well as SAX). At some point during execution we get a signal
> SIGSEGV, and our process quits.
>
> Here is a listing of the stack trace:
> .
> DOMParser::~DOMParser(0xec3044e0, 0x2, 0xee7c0560, 0x5f4974,
> 0x6e36c0,0xec3044e0)
> XMLScanner::~XMLScanner(0x6e45c0, 0x3, 0xee7bb204, 0xee7bb204,
> 0x6e36c8, 0x43)
> ElemStack::~ElemStack(0x10, 0x2, 0x4, 0x6e45d8, 0x2002c, 0x6e4630)
> XMLStringPool::~XMLStringPool(this = ???, delete = ???) (optimized)
> RefHashTableOf::~RefHashTableOf(this = ???, delete = ???) (optimized)
> RefHashTableOf::removeAll(this = ???) (optimized)
> XMLStringPool::PoolElem::~PoolElem(this = ???, delete = ???)
> (optimized)
> .
> .
>
> It apparently fails in the destructor.
>
> Our build / run time platform is Solaris Sparc 2.6
> While building the Xerces library we ** do not use ** the lpthread
> library as we had problems when
> integrating with the Mozilla Transformiix XSLT processor.
> We do use the "-mt" compiler switch and the -D_REENTRANT flag in the
> 'compile' options.
> We also have the required patch (Patch ID #105591) for multi-threaded
> applications
> installed..
>
> Is there a fix to this problem ?? We would appreciate any help /
> solution for this.
>
> Thanks,
> Nikita
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Problem in a Multithread application using Xerces C++
Parser
Posted by Paul Duffy <pa...@cisco.com>.
See below....
At 08:13 PM 10/16/00 -0700, you wrote:
>Hi,
>
>We are using the Xerces C++ parser in our multithreaded application. In
>this application we have multiple threads that invoke the Xerces parser
>(DOM as well as SAX). At some point during execution we get a signal
>SIGSEGV, and our process quits.
>
>
> Our build / run time platform is Solaris Sparc 2.6
> While building the Xerces library we ** do not use ** the lpthread
>library as we had problems when
> integrating with the Mozilla Transformiix XSLT processor.
> We do use the "-mt" compiler switch and the -D_REENTRANT flag in the
>'compile' options.
> We also have the required patch (Patch ID #105591) for multi-threaded
>applications
> installed..
I just, finally resolved my Solaris 2.6 build problem this week. You
needed to acquire the 105591 Solaris patch AND late model GCC tools. THis
is what I did...
1. Get the 105591 patches installed on my U5
2. Build and install GCC 2.95.2
3. Build and install Binutils 2.10
These were all required to repair various template and multi threaded
exception support.
I am using the pthread library.
Compiling with -D_REENTRANT and _D_PTHREADS.
It all seems to be working well.
> Is there a fix to this problem ?? We would appreciate any help /
>solution for this.
>
> Thanks,
> Nikita
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
*********************************************************
Paul B Duffy 978-244-4754 Fax 978-244-8917
Cisco Systems, Inc. paduffy@cisco.com
300 Apollo Drive
Chelmsford, MA 01824
*********************************************************